Reduce / remove jQuery dependency to support Backbone#3003

[akre54]

I opened a pull at jashkenas/backbone#3003 which attempts to remove the hard jQuery dependency from within Backbone.View, and it seems Stickit would be a good place to start answering some of the tougher issues of integrating features of that pull in View plugins.

3003 removes the guarantee of a view.$el property, instead suggesting that plugins use view.el. It introduces an exposed delegate method on View that allows View to do some bookkeeping for delegated events (so we can avoid this.$el.on calls) and later remove those events with undelegateEvents. Lastly, it changes the contract on view.$ (i.e. view.$('.selector')) element lookup method to return an array-like object that has Elements in each of the numbered slots. view.$ may return an array, a NodeList or a jQuery object and they should all work correctly. This means that we have to iterate over the return value from view.$ with _.each.

For the most part, implementing a DOM library-agnostic set of features in Stickit shouldn't be too tough. We already use _.each to iterate over many of the element collections returned from view.$ and event delegation could be changed from this.$el.on(...) to this.delegate(...), but there are a number of places we use $el.find with pseudo-selectors and addClass/removeClass that could make using native methods difficult without adding shims for old libraries (i.e. requiring querySelectorAll and classList shims might be necessary.)

Then there is the question of adding an undelegate method to View to allow undelegating specific namespaces or selectors without blowing away all events from the View or relying on this.$el.off. Stickit uses namespaces to handle bookkeeping and removal at the end, and it relies on the jQuery-specific feature of passing a selector or map of selectors to off, which could be difficult to force all implementations to add. One of the main goals of 3003 is to determine what features all View subclasses should support as a baseline, and some insight there could prove useful.

@delambo, mind chiming in here or in 3003 to offer some insight into what you think it would take to get Backbone and Stickit jQuery-free?

[andriijas]

Love the effort. Currently using exoskeleton (backbone fork without jquery) in a new project and I went with rivets model bindings rather than stickit this time just to get the taste of something different. Would love to see jquery free stickit.

[akre54]

Glad you like. Exoskeleton is the other side of the jQuery-free coin. Any ideas on what's needed to get the rest of the jQuery bindings out of Stickit? Maybe we should push as stickit version 2?

[andriijas]

I like the way you do it in chaplin @akre54 but perhaps it will generate to many "if jquery do this, else do this" in stickit. shims are no no. i dont like them. and i think the browsermarket, seeing the latest versions at least, have a pretty nice baseline of modern support. if one needs older support, just use jquery - which is still a great framework.

I dont think there is a lot of dom manipulation i do frequently with backbone, thats one of the reasons i challanged my self to not use jquery in a new project. It turned out its mostly classList stuff, finding elements and get values/attributes or set innerHTML

[akre54]

In general I'm not a fan of the logic branching you describe, mostly because its ugly and can be better handled in View, or with native methods in the simple case.

I think Chaplin goes a little overboard in that regard, and if it's possible to keep it simple and only within View, I'd like to figure out how to make that work.

[delambo]

What's up @akre54, @andriijas -

@akre54 - I'm trying to catch up on your backbone pull and look through stickit to see what it would take to go native. I'm not concerned about shimming or working with native attributes and classes. The lack of find could prove difficult, especially for the pseudo-selectors. What do the shims for that look like?

I would also like to know what the shim for namespace support looks like. As an alternative to namespacing/shimming, we could manage our own bookkeeping of view events, similar to the _modelBindings bookkeeping.

Overall, the backbone pull looks nice. It's minimal, as it should be in backbone, and I think we can deal with the issues it brings to stickit.

@andriijas - sup on rivets? ...have any feedback?

[akre54]

There are no pseudo-selectors, just selectors that can be found with qsa. Find (a.k.a. view.$) still exists and functions 90% the same, but is no longer guaranteed to be a jQuery object. It will be array-like, so both should be easy to iterate through with _.each.

The new goal with 3003 is to avoid namespaces altogether and instead keep track of the references ourselves, just like we do in Stickit with model bindings. I'm a little busy the next few days, but I'm hoping to get a few minutes to whip up a compatible Stickit that has most of the major concepts in place.

Let me know if there's anything that immediately stands out to you.

[andriijas]

I think its good to try to not use psuedo selectors anyway, and if you do, there is jquery :)

Regarding rivets, well I started a new backbone project with as few dependencies as possible to widen my knowledge about javascript but in the end there was a couple of forms that just made everything simple and elegant with bindings so I opted to try rivets. Ive been anti with putting the logic in the html before so I wanted to challange my self. I think its nice for the simple things ive been doing this far. Im sure its possible to extend for more advanced stuff too but the way stickit works with handlers is straight forward (for me at least) and allows for easy flexibility, if you need small alterations its easy because your binding is already in your view logic. with rivets, if you need small difference from what you put in your html, you need logic elsewhere AND in html. That said Ive been enjoying stickit for 1 year and 3 months. Ive only been using rivets for 2 months :)