The Dangers of JavaScript Frameworks, Libraries and Plugins

PluginsThe recent explosion of JavaScript frameworks and libraries in web development has been undeniable. I can think of 10 libraries right off the top of my head and I have seen a site that lists 34 libraries just for visualizations. I am happy to see such a diverse ecosystem of easy to use tools sprouting up in the web development community. Certainly some of them make development a heck of a lot easier. But I am beginning to see a dangerous practice growing along with this that I think we all have to stop and think about a little.

Ease of use also increases lack of thinking

You are tasked with creating a website for a client. That client is, of course, asking for a whole slew of cool things that they want the site to do. No problem for you, they are not asking for anything you haven’t seen already. They want the typical fade effects, collapsing menus, animations, some sound effects and more. Damn it if it isn’t going to be the coolest looking version of a Blizzard Entertainment website even if it is for the accounting department of an insurance company.

Time to get to work. Great! We will throw on jQuery (it is a must), jQuery UI for enhanced user interface effects, howler.js for the sound, D3.js for some charts, go with knockout or angular for MVC and maybe validate.js for form validation. You use the libraries to create the dream website and pad your portfolio with some legendary work.

But now there might be a few problems:

  • You just added 150KB+ of JS code to your page. Each time someone visits, they are downloading this extra traffic (unless they have a copy cached).
  • Now each visitor is making 6+ additional file fetches.
  • You have increased your attack footprint by leaps and bounds.
  • There may now be some conflicts you don’t know about.
  • There is most likely some overlap and repetition going on.
  • Sometimes if there is a bug, good luck sifting through everything including minimized obfuscated code.

Because developers are being spoiled with some library love they haven’t stopped to think about what they are actually adding and what it could mean in the long run. It could mean degraded performance, it could mean exploitable code, it could mean unintended side effects or it could simply mean increased complexity leading to poor maintainability.

Choosing libraries/frameworks wisely

My suggestion would be to think in broad site-wide terms and think about exactly what you need. If I am going to create a simple contact form with a name, email and a comment box do I really need to use validate.js for it? Could I not write a simple JavaScript function that checks the validity of three fields? Ask yourself how much of the library functionality you are going to actually use because if you aren’t using it, it is going to be bloat. It also means that function for validating a textarea, that you don’t even use in your form, may contain code that someone could some how exploit. It is also dead weight you are carrying along for each visitor who visits. Sure each component may be “lightweight” but together they become a heavyweight setup.

Also look for overlapping features. I know people who are including libraries that do fade effects that they could have simply done in jQuery which they have already installed. If I am not doing something specialized, perhaps jQuery is all you need. Even then, how much of jQuery do you even use? Don’t include jQuery if you are just going to write a simple function to print someone’s name.

In addition to all this, we have to get into the habit of thinking “If I include it, I should support it.” If one of our components is sick and throwing up some kind of errors, we may have to dig into it a little to find the problem. Running off to some support forum may or may not work and what if no one knows the answer to your question? You want to be able to know enough about what you have included to diagnose the problems yourself.

More than just on the web

I have seen this phenomenon happy in other development circles as well. Huge stacks of technologies where one function is being used from each component in the stack, leaving 99% of the component’s functionality sitting there doing nothing. We should be looking at technologies that are robust, well used and offers a language that we can grow with rather than providing a simple solution on a silver platter to meet the immediate need. This is why I have a soft spot for jQuery. It provides a foundation to write your own stuff if needed.

All I am asking is that before we dismiss something with the off hand comment “Oh why think about that when D3.js can do it?” we should think about old vanilla JS from time to time. Sure it may seem less elegant but often times it is faster and can create that glue you need to bring that special feature to life. It doesn’t have to be complicated. It just requires some thought on our part. Thanks for reading!

About The Author

Martyr2 is the founder of the Coders Lexicon and author of the new ebooks "The Programmers Idea Book" and "Diagnosing the Problem" . He has been a programmer for over 25 years. He works for a hot application development company in Vancouver Canada which service some of the biggest tech companies in the world. He has won numerous awards for his mentoring in software development and contributes regularly to several communities around the web. He is an expert in numerous languages including .NET, PHP, C/C++, Java and more.