What's wrong with JavaScript?
I'd like to think I'm not alone in my feeling that the front-end ecosystem is chaotic. When I learned table-layout HTML pages in high school, JavaScript was barely mentioned, but when it was we used basic event handlers in HTML such as onClick for buttons. As I continued to pursue web development as an interest in college & eventually a career, I learned more JavaScript to handle DOM events and manipulations. Here I was introduced to querySelectorAll and addEventListener which gives developers much more control over the DOM, without having to use HTML to add functionality.
At some point, developers decided that JavaScript can be used in lieu of any HTML to create dynamic and robust applications, subbing in JSX, JavaScript powered elements, and similar component based frameworks. There's nothing wrong with this, but it was surely a strange step away from my initial table-focused knowledge I started from. I've cycled through React and Vue and consistently found that they address a lot of use cases, and in many are the right tool for the job, but even so I felt a sense that they add complication to front-end development. I believe that the root of that is the removal of HTML and relying instead of reusable components in JavaScript to manipulate and populate the DOM.
Eventually I found Svelte and immediately fell in love. Unfortunately I haven't found the case to use Svelte in a production app, but I have had the opportunity to use it in side-projects and making toy examples of things. The reason I love Svelte so much is that it brings HTML back to the forefront and instead of replacing or fighting vanilla JavaScript, it enhances it in extraordinary ways and augments front-end development with useful additions. The Vue-like component syntax is also extremely easy to pick up, as it follows similar semantics and separations as standard HTML (although I'm not a fan of the .svelte extension). It's important to note that since Svelte is compiled, it's not technically JavaScript, as discussed in this blog post. But the speed improvements, and ease of use is a huge benefit that I see propelling Svelte usage forward.
So what is Imbue?
This post isn't intended as a rant against Javascript nor a promotion of the library I'm trying to build (Imbue). It's more of a reflection of my thoughts on the front-end development experience, and my desire for something to address what I see as issues.
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 $() with document.getElementById and document.querySelectorAll, the replacement wasn't hard and I did anecdotally feel like everything ran faster after the replacement, but I immediately hated looking at the source code of our pages. I made the discovery that the main reason I used jQuery was because the vanilla JS methods for the DOM are poorly named, sometimes confusing, and lacking in features. Additionally, the developers I worked with were just as ingrained in the jQuery mindset as I was, and we all had to dust off JavaScript books and take a look at the DOM related methods again.
So this is where Imbue comes in. Imbue is a small (~5kb currently) library (not framework), that provides semantic and simple prototype extensions to vanilla JavaScript, to speed up development and make source code easier to understand. The lengthy "document ready" code that jQuery made $(document).ready() is supplied in Imbue as document.whenReady(), the selector methods in jQuery are replaced by document.getElement() and document.getElements(), which simply use querySelector calls underneath. HTMLElements are extended to have whenVisible(), onClick(), getData(), setData(), 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?
Hi Paul! I definitely considered mimicking the implementation of jQuery in terms of naming, but ultimately decided that I wanted to emulate vanilla JavaScript calls instead (such as
getElement()instead ofgetElementById). In Imbue thegetElement()andgetElements()calls take the same standard selectors as jQuery, as they both usequerySelector(), so you can still use things likeselect .mySelector#examplefor selectors.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, asquerySelector()is also fairly robust. An added benefit is that you can specify calling one element vs. a list by using the plural formgetElements().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.