You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I guess this is more to start a discussion than raise an actual issue, but in my opinion having a hard requirement on Backbone is undesirable. While having to include the Backbone library in say, an Angular or Ember project won't break anything per-se, it seems quite messy to include the entire library when you have no intention of using any of the integration.
I had a quick skim through the code and it looked like you could categorize the usage of Backbone into two 'buckets' (please clarify is this is incorrect):
Usage of Backbone native capabilities like event listeners and utilities.
Actual integration of Backbone namespaced classes like Collection, although these all appear to be secondary to the internal library-agnostic implementations.
Based on a little experimentation, you can replace the vast majority of cases that come under 1) by just switching to use the jQuery equivalents instead, which is a much more 'universal' library and is an existing dependency anyway. The actual integration with core Backbone components like Collection under category 2) should be guardable by using stricter checking for the existence of the Backbone namespace, although I haven't done a great deal of testing around this.
If its done correctly, you could feasibly end up with a library that works with simple utility libraries alone (jQuery & Underscore), but also had an optional integration with Backbone (and others, over time).
As for the others, Underscore in itself isn't really an issue, although I would question whether the core library really needs it at all if you don't intend to use Backbone? Not sure...
I would imagine its probably a longer term progressive change anyway (if its even deemed to be worthwhile), but I figured I'd start the discussion anyway.
The text was updated successfully, but these errors were encountered:
You are correct. We do not have any desire for Backbone to be a hard dependency, but for the sake of getting this project underway faster - it was the best choice at the time. Moving forward we certainly want to work on removing that link.
I guess this is more to start a discussion than raise an actual issue, but in my opinion having a hard requirement on Backbone is undesirable. While having to include the Backbone library in say, an Angular or Ember project won't break anything per-se, it seems quite messy to include the entire library when you have no intention of using any of the integration.
I had a quick skim through the code and it looked like you could categorize the usage of Backbone into two 'buckets' (please clarify is this is incorrect):
Based on a little experimentation, you can replace the vast majority of cases that come under 1) by just switching to use the jQuery equivalents instead, which is a much more 'universal' library and is an existing dependency anyway. The actual integration with core Backbone components like Collection under category 2) should be guardable by using stricter checking for the existence of the Backbone namespace, although I haven't done a great deal of testing around this.
If its done correctly, you could feasibly end up with a library that works with simple utility libraries alone (jQuery & Underscore), but also had an optional integration with Backbone (and others, over time).
As for the others, Underscore in itself isn't really an issue, although I would question whether the core library really needs it at all if you don't intend to use Backbone? Not sure...
I would imagine its probably a longer term progressive change anyway (if its even deemed to be worthwhile), but I figured I'd start the discussion anyway.
The text was updated successfully, but these errors were encountered: