Why I Dislike Working With Frameworks – Even Though They Make Sense in Some Situations

Frameworks, like jQuery, are some of the most popular, and most widespread assistants used on websites. The framework allows you to access and manipulate HTML elements fast and easily, as well as style them via CSS. Personally, I'm not a fan of these frameworks, and try to avoid them whenever possible. This doesn't always work, but it can be done without any issues quite often.

jQuery and Co. and its Large Footstamp

Especially jQuery has become some all-round tool for JavaScript over the last couple years. The framework provides a vast array of methods, elements, and events, most of which won't be used by the majority of users. Although the current compressed version of jQuery only weighs about 85 kilobytes, a majority of the framework would remain unused in my projects. You might call me picky for worrying this much about 85 kilobyte. But as a web developer, a slim code that only contains what I actually need is important to me. jQuery has become some standard in web development. Thus, a lot of other frameworks were developed as plugins for jQuery. So, if I would want to use them, I'd have to use jQuery as well. Here, the disadvantages of these frameworks become evident. After all, I would only need jQuery to use that plugin. To me, 85 kilobytes are too much to justify that.

Redundant: Often, JavaScript Can do Just What jQuery Does

With the introduction of HTML5, JavaScript took a huge leap ahead as well. Many functions that were previously exclusive to jQuery are available as native JavaScript methods as well. For example, this applies to adding and removing JavaScript classes. The "classList"-API enables you to realize this in a way that's very similar to jQuery. One of the most important functions in jQuery is the option to access any desired element via "$()" - following CSS selectors. By now, even this unique feature has been implemented in JavaScript via the method "querySelector()".

document.querySelector("ol li").classList.add("new");

In the example, the class "new" is assigned to all "<li>" elements that are children of an "<ol>" element. In jQuery, an according invocation is barely shorter - but not less complicated.

$("ol li").addClass("new");

So, in a lot of cases, I don't even need jQuery, as I can work in a similarly simple way using JavaScript.

Performance vs. Simplicity

jQuery and its less popular colleagues definitely simplify working with JavaScript in many cases. However, the easiest way is not always the best one - especially when it comes to performance. Both the jQuery method "$()", and the JavaScript method "querySelector()" come off worse than the methods "getElementsByTagName()" or "getElementsByID()" when it comes to performance. With "$()", and "querySelector()", the entire DOM tree of a document is searched for respectively fitting elements first. The two methods "getElementsByTagName()" or "getElementsByID()" accomplish the goal significantly faster. Of course, the latter methods are connected to more effort for developers. Even here, the slight performance difference may be negligible. But you should definitely be aware of it.

Advantage: Coherent Browser Compatibility

Of course, I don't want to act like jQuery was entirely redundant. After all, there's a reason why it's still very successful and popular. Obviously, one advantage is its simple application. Moreover, these frameworks have the distinct advantage of a broad browser compatibility. While native methods always require me to check which browser supports which version, jQuery makes things quite a bit easier. I know which browsers and versions are supporting each jQuery version. Especially those developing for older versions of Internet Explorer will know for sure that jQuery supports it from version 9 and up. Those that want to support older browsers can simply go back to older versions of jQuery. This eases the development of websites, as you'll know which browsers are aboard in advance.

Frameworks for Particular Things

So, I'm someone that foregoes frameworks whenever it's possible and makes sense. Actually, it's pretty much always possible. Generally, everything can be programmed in JavaScript. But of course, it doesn't always make sense to do so. Obviously, there are situations where the effort of developing a complex JavaScript coding yourself bears no relation to the result. If for instance, you want to create 3D animations with JavaScript, you can build an own 3D framework. Here, however, it makes a lot more sense to rely on a stable, light framework. In these cases, I ensure that the framework is not based on other frameworks such as jQuery, making it freely and independently usable.

Conclusion

The question whether you use frameworks or not is an ideological one. In many cases, the speed gain is marginal. But, as a developer, we should not rely on jQuery and Co. for the sake of convenience. Often, a native JavaScript can cover everything that jQuery can do. Especially when developing for contemporary browsers with a limited backward compatibility as it is, you'll do just fine without this framework.