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:
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.
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.
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!