Why I hate using JavaScript plugins, and You Should Too

What’s your first instinct when it comes to a solution you need, or a problem you have with JavaScript? Is your go-to a JavaScript plugin? There are most definitely a myriad of JavaScript plugins that exist, but should you be constantly going to them to serve your needs? If you think to yourself that a JavaScript library is your saviour in every situation, I hate to tell you – it’s not. In all honesty I have never quite understood why developers are so quick to use a JavaScript library for simple problems that they can easily solve themselves. Going for a pre-made library may seem like it saves time, but in the long run it may do the opposite. Think strategically about what you’re spending your time on, and how you’re implementing the resources available to you. I know hate is a strong word, but here are some of my thoughts I’d like for you to consider going forward!

Consider the Following

JSplugins
Let us consider a feature that is quite common among sites: Sticky content. For those that may not know what I am referring to, sticky content is content that becomes fixed at a specific point. Typically when a user a scrolling down a page and the top of the browser reaches your element, your element becomes fixed to prevent it from disappearing as you scroll.

Consider this library, which can be used to achieve sticky functionality for your element. The library has over 150 lines of code for something that can be achieved in less than 20…I am making an assumption that the library can be easily implemented into your application without any problems. That itself can be its own world of headaches.

Related: Write Better Code: Tips to Keep Your Templates Clean

To Create or Extend?

JSplugins

It is not uncommon that at some point features may be requested which are not available out of the box with that module. What do you do now? Do you now write your own library or do you attempt to extend the one you are using? That may not be an easy call to make depending on the situation. One thing that is for certain, which is if you go the route of extending the existing module, it will be a nightmare. Not only will you have to spend time looking into how it works, but you will have to make sure your extended functionality does not break what is already there.

I mentioned that sticky functionality can be achieved with less than 20 lines of code, so here is an example of a sticky effect that I whipped up with 14 lines.

With that code, should there ever be a need for extended functionality, it would be a breeze extending it not only for the person who wrote the initial logic, but also for any other developer that might possibly work on the project. The code was short enough that it does exactly what it needs to, without all the extra unnecessary bells and whistles making it more complicated and bloated than it has to be.

Related: Extending Core Magento Javascript Files – Don’t overwrite

Rely on your own skills

javascript skills
I see this trend among developers more and more. They prefer to save themselves time by going with someone else’s library (even for the simplest of tasks). At the end of the day, if you are a developer you should be relying on your own skills to do what needs to be done and when possible, avoid the bloat and headaches of pre-made libraries.

Of course there are certain libraries that are at the core of almost every website. They are used so much, and have been refined quite a bit that at this point it’s not worth it for anyone to re-create them every time. In those situations, I would consider a pre-made library to be perfectly acceptable. Let me know in the comments below how you feel about JavaScript plugins!

Related: [Mini Tutorial] Changing the order of layout XML blocks in local.xml