addEventListener which gives developers much more control over the DOM, without having to use HTML to add functionality.
So what is Imbue?
I've worked with jQuery for several years, and for most of my projects, jQuery is the first thing I plopped in to the
lib directory, or installed in Bower, or NPM, or linked with a CDN. It honestly got to the point where jQuery was a required drop-in for a project, and from the look of a lot of recent articles, I was not alone in this experience. Over time jQuery's popularity surged and at some point I, like many others, began to see it as an unnecessary, slow, bulky, and strange requirement. Sites like You might not need jQuery popped up to help people take a step back and remove the dependency from their systems. In a production application I'm working on, I also took a step back and made the decision to slowly rip jQuery away from our app.
I began by replacing
$(document).ready() is supplied in Imbue as
document.whenReady(), the selector methods in jQuery are replaced by
document.getElements(), which simply use
querySelector calls underneath. HTMLElements are extended to have
toggleClass(), and many more.
I'm exploring just how much functionality Imbue should provide, keeping in mind that it's not a jQuery replacement, but a substitute for projects that just need the DOM related functionality. The main reason I decided to write this post, was that I was curious to see if any other developers would find benefit in a mini-library like Imbue, and whether or not your projects could eschew jQuery for something like lighter and more focused?
Would love to have a discussion on the usefulness, how to move forward, and the current state of front-end development overall.
Top comments (3)
Why don't you use jQuery as a blueprint from an interface perspective? For example, instead having getStyles and setStyles you provide css() for reading and writing. I know that it should not be a replacement but that only means that you do not have to provide all functionality like animations. A second thought: Is prototyping on native element like document and html element really a good idea? Maybe offering a function based ES 6 library where you pass in the element would be a better option? Third and last one: In my opion the most comfortable feature of jQuery is its flexibility in its selector engine. Means, one selector function for all. Any plans on this?
getElementById). In Imbue the
getElements()calls take the same standard selectors as jQuery, as they both use
querySelector(), so you can still use things like
In regards to prototyping native elements, I haven't found major reasoning against doing so, especially when given Imbue won't override any calls/properties already present in the prototype. By extending upon the native elements it makes using Imbue feel more natural & reflects the fact that the calls Imbue makes are just simple native calls. In essence, my push is just making shorthand calls & useful helper methods that utilize the poorly named or longer implementations native JS has under the hood.
I think the last point is addressed a bit earlier, but the
getElement()call is fairly robust, as
querySelector()is also fairly robust. An added benefit is that you can specify calling one element vs. a list by using the plural form
I am admittedly not extremely knowledgeable on the pros/cons of extending things like HTMLElement & HTMLDocument, but from my usage in production (alongside jQuery at the same time) Imbue hasn't resulted in unexpected behavior, but if you have more insight I'd be really excited to hear it!
Thank you for your comments
A post-post comment - Imbue is definitely not production ready (although I'm using it that way) and I'd very much like it to be community-driven.