Pros and Cons of JavaScript Frameworks

A solute of recognition

Before I state my case I would like to recognise the invaluable contribution Jon Resig (the inventor of jQuery) and now Dave Methvin and his team (maintainers of jQuery) have made to improving the quality and raised the capability of Client-side code. There are numerous others who have contributed in this regard with their own JavaScript framework and they all have my thanks. I think JavaScript frameworks (like their counterparts in Java and C#/.Net) play a positive role in the software engineering process and produce superior products but I still have misgivings.

“Have you seen the new @@@ JavaScript Framework?”

The web development world is a fast moving beastie with new techniques, standards and technologies released almost daily. Keeping abreast of every new big thing is almost impossible, especially if web development is not your entire 9-to-5. The same thing applies to the growing selection of CSS frameworks and third-party development tools.

The most important pulses to keep a finger on are the web standards (W3 & ECMA recommendations) and the browser implementations there of, as everything hinges on them. May be I am just getting too old for this game; or may be I have a life!

“What? I am not allowed to use jQuery!”

I was recently on a projejQuery Logoct for a large (global) automobile manufacture, designing a web application that
will be used world-wide. The monolithic German company mandated the products that could and could not be used – as is their right. One of the User Interfaces (UI) of the application was targeted at the general public (customers and prospective customers) and had to deliver a superior User Experience (UX) to that of the previous product. As part of the application design and number of web technologies were selected to support the improved-UX requirement including jQuery. One of the Java developers had been experimenting in his own time and found it a convenient product to enrich the UI for his back-end code using AJAX. The design went in for approval and failed because, amongst other things, jQuery was not on the corporate’s list of approved components. The Java developer was unconsolable, asking “How am I supposed to interact with the User Interface without jQuery.” The answer came back – use JavaScript!

I have employed a little figurative licence in the above text but it is based on an actual incident. The crux of the abstract is that jQuery (and other frameworks) has become so much part of the web development landscape that some developer’s cannot recall a time before it existed. After all, it has been around since 2006 and is every growing in popularity and consequently in dependency. Some developer’s are so dependent on their favourite framework, they cannot develop client-side script without it.

Browser Standardisation

There are many sources of rationale behind the development of JavaScript frameworks:

  • Better support of functionality between browsers
  • Simplification of:
    • AJAX functionality
    • DOM (Document Object Model) manipulation
    • Page loading sequence control
    • Theme Styling
    • Custom Widgets
  • Animation and other “helper” functions
  • Implementing the Class-based (C++, Java style) form of Object Orientation using the Prototype-based approach.
  • Support for Application design patterns such as (for more info on MVC please read my article):
    • MVC: Model-View-Controller
    • MVVM: Model-View-ViewModel
    • MVP: Model-View-Presenter

All the above are noble aims but suffer from 1 or both of the following:

  1. As techniques become standardised and simplified the need for “helper functions” is removed.
  2. As browsers become more compliant with the standards the need for cross-browser support is also reduced.

As the need for frameworks to supply such functionality reduces they leave in their wake a mass of obsolete code in web sites across the globe. An amount of back-ward compatibility will continue to be required for legacy browsers; the last two editions in the case of Google Chrome and Mozilla FireFox. Since the retirement on 8th April 2014 of MS Windows XP, which served us so well for 12 years, the worse offender (Microsoft Internet Explorer 6) is in effect dead; as should be IE 7. This still leaves the last 4 editions (8, 9 10 & 11) of IE to support but they are far less reliant on frameworks.


The rise oHTML5 & CSS3f HTML5 and CSS3, and their support in the latest web browsers also dilutes the role of frameworks in modern web sites; but I fear the dye is cast. Too many developers include the script tag to jQuery (et al) as a matter of course. I wonder if they know how to call on the functionality (which is in the browser not the framework) without them.

I also wonder if they ever consider the performance overhead. Agreed the hosting of frameworks in Content Delivery Network (CDN) facilities greatly reduces the network latency and caching helps limit the number of refreshes but that is not the biggest hit on performance – that is within the web engine.GWT Logo

JavaScript frameworks are usually compressed and benefit for optimisation performed by some very cleaver people. But the fact cannot be ignored that they are all write in JavaScript, even those derived from 3-rd party code bases such as CoffeeScript and GWT. The code delivered over HTTP to the browser is still ECMA-262.
Vanilla JS Logo
Thus it is the JavaScript parser that performs the magic but with a level of abstraction and indirection that slows the functionality down. Vanilla-JS This is illustrated all too well by the framework and the performance figures it is able to achieve through absolute optimisation.


Have you ever tried to obtain the latest book on jQuery or DOJO – don’t bother. I would not hold much stock in the on-line documentation either. The velocity of change in the code-base is far higher than the printing press and many of the coders are not gifted when it comes to documenting (within and without) their code. This has been the source of considerable frustration for me and many of my colleges; I can still hear the snigger of laughter from the Java developers.


Another issue is, what could be described as the “shoulder-pad effect” when the build up of shoulder-pads result in the distortion of outer garments. The proliferation of frameworks like jQuery makes for a dependency by later frameworks. Considering the case described earlier when jQuery was excluded from an Enterprise Strategy, which would effectively disqualify other components with a dependency on jQuery. It is one thing to “stand on the shoulder of giants” but shoulder-pads on shoulder-pad become most unsightly and potentially limiting.

Further Reading

Don’t take my word for it.

  • Here is an article by James Jackson and Addy Osmani, with comments from Chris CoyierChris Ferdinandi
  • Another by Chris Ferdinandi on “Ditching jQuery for vanilla JS”
  • And another by Todd Motto that asks, “Is it time to drop jQuery? Essentials to learning JavaScript from a jQuery background”

Return to Articles


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s