Jason Howmans

think before you plugin

Front end developers are spoiled.

You’ll be hard pressed to find a path that hasn’t already been trodden nowadays; a problem that hasn’t already been solved. We have ever growing Stack Overflow threads, GitHub repos, and CodePen sketches to follow when we’re stuck for ideas. We have npm and bower to make using plugins in projects as simple as writing npm install. It makes you wonder where the developer belongs in it all.

In a world where plugins are abundant, you see programmers going a few different ways:

The Purist goes against the grain to an extent that is just ridiculous – wanting to solve problems with no outside help at all, and write custom code as much as is possible.

The Cut’n’Paster is the opposite of The Purist, and will use as many outside code sources as possible – aiming only to get the thing functioning and ignorant of anything else.

Finally there’s the Fence Sitter, whom uses plugin code on a whim. If they don’t feel like writing code that day, they use plugins, otherwise they might make the thing themselves.

Unfortunately, like most things in life, the reality of when to use plugins is not clear cut. We should be thinking about what is best for the project and the people working on it in the future, and not whats best for you in the immediate future. Below are some questions to consider before using a plugin:

how disposable is the piece of work?

If you’re working on a project that is intended to have a short lifespan, or is just a rough prototype, then time is likely more important than anything else. In this case using plugins is okay because the aim is to explore an idea and not to create a manageable piece of code.

is it solving a problem that’s fundamentally hard?

Some things are just really hard to do well. Think about dates, dependency management and promises. These are libraries or utilities that are fundamental to most projects and are mind numbingly difficult to maintain yourself. Imagine if you had to write a library like Lodash, test it, and keep it up to date with language changes and the like. If it’s that hard, use a plugin for it.

would the project benefit from a custom implementation?

I’ve seen plugins used unnecessarily in almost every large front end project I’ve worked on. Plugins used for stuff like basic UI elements, form submission, convoluted CSS frameworks. There’s a time and a place for these types of plugins, and they don’t belong in large long-lasting projects. It might seem like using a plugin can save time in the short term, but there’s no such thing as a free lunch. Time is usually wasted later, supporting or adding to a piece of code isolated from the main codebase.

We regularly talk about the subject of front end plugins in depth at MetaTowers. Before a plugin is taken in, we will argue its usefulness. If we all come to an agreement then the plugin / library / utility will become a part of our toolkit, if not we move on with our lives.

In a world becoming saturated with open source code, and pre-built functionality, we need to cultivate the art of saying no to things, instead of yes.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus