Removing jQuery (upcoming PR)
Closed this issue · 7 comments
Hey! Love that you did this. That said, I do already have a plan for how to remove the jQuery dependency.
It will be similar to Backbone.$. By default, Boba will try and use window.$. If it can't find that, you'll have to provide a shim object with functions compatible with jQuery's API, like this:
Boba.$ = {
extend: function(target, object) { ... },
on: function(element, event, selector, handler) { ... },
proxy: function(func, context) { ... }
}If you're using Underscore.js, you could use something like this:
Boba.$ = {
extend: _.extend,
proxy: _.bind,
// Underscore doesn't have anything for this, we'd have to write it ourselves
on: function(element, event, selector, handler) { ... }
}The on function will be different, since it's called on a jQuery object. I'm thinking Boba will include something like this:
Boba.$.on = function(el) {
Boba.$.fn.on.apply($(el), Array.prototype.splice.call(arguments, 1))
}The point is, I don't want Boba to include ancillary functions. I'd rather have a shims/ folder, and probably have different builds using each of the shims.
I'd love to hear other people's thoughts!
My first thought as a developer is, "Yeah, shims would be cool!", but my first thought as a user is, "Why can't it just work OOTB?"
The level of complexity necessary to hide a loop and a closure is crazy. And you still don't get a good listener for on.
Boba tries to make working with GA easier, right? IMO, supplanting the user's problem (tracking) with writing extra methods just to get it to work seems dubious.
Oh, it would work out of the box with jQuery, and there would be other versions (in a dist/ folder or something) that would work with things like Underscore.js or just vanilla JS.
Sorry, I probably didn't explain very well before. Boba at it's core would use jQuery if present, and require a shim otherwise. The shims would live in a shims/ folder, so that anyone could contribute one. I'd add a gulp task to build each shim into the dist/ folder, so you could grab, say, a jQuery-free version from there.
It's up to you ultimately how you want to do it. I think it's a bit silly to shim a for loop and a closure. There's nothing wrong with these patterns or having them in the core code. The complexity created by offloading to dependency x creates far more friction for maintenance/contributors and end users.
Suddenly it becomes not an easy drop in replacement-- you need to know something about it, you need to pick the right shim and be aware of potential conflicts. For a 100-line abstraction, that kind of peripheral knowledge shouldn't be a prerequisite.
An idea could be to stick mainly to ES5 methods, such as Array.prototype.forEach and suggest the ES5-shim for users needing to support IE8 or other non-compliant browsers. I think writing it lean and adding an ES5 or jQuery adapter is a good pattern. It would support those who require wide-range browser support, and those of us who do not have that concern.
I think I'm just going to merge this (when you submit the PR). Eventually I'll get around to implementing things the way I'd like them, but this is good for now.