The development world can move at such a fast pace that people are already talking about Web 5.0 when the overhyped 3.0 is barely a thing. With that speed it’s become a running joke that a new JavaScript framework is released every day. Someone even made a website about it. Even faster – and not talked about as often – are npm packages. More than a million npm packages are publicly available at the time of writing and that number is growing daily.
These packages have become so vital in today’s development process that you could probably mirror Apple’s famous slogan “There’s an app for that” with “There’s an npm package for that”. But – as with apps – because you can, doesn’t mean you should.
Normally there isn’t a problem with using NPM packages to help save time and money during the development process. But I’d argue that it’s become almost too easy. Don’t get me wrong, the people who develop these NPM packages are lifesavers and they’re an absolute necessity sometimes. After all, open source is one of the greatest feats developers have gifted the tech industry.
The concern for me is when developers reach for them mindlessly because they either don’t know how or don’t want to try building a framework themselves. Just to be clear, I’m not suggesting building your own framework like React, Vue, Angular, etc. – although there is a time for that, which I’ll discuss later.
When you find yourself looking for a package to add to a project, there are four main things to note before you embark on the adventure of creating your own. Use these as a guide to decide if it’s worth it or not. As an aside, you’ll notice that I interchangeably use NPM packages with libraries or frameworks. It’s important to note that they’re not the same but are usually added to projects as NPM packages.
Depending on the package you’re reconsidering, make sure you can rebuild it yourself. Nobody should be trying to rebuild the next React or state management library while already busy with a project.
If the need for the package is complex and multi-faceted, start from the beginning and reassess the original need. Let’s use the example of state management in React: Out of the box, React already comes with a way to manage state on a component level, but its biggest shortfall is sharing that state between components. It’s not impossible but can quickly become hard to scale on larger projects.
Because of this, most front-end developers settle for Redux, a state management library widely used in various React projects. The downside to Redux is its learning curve for less experienced developers on a team, as well as the boilerplate it comes with. What’s more important, however, is looking at the need for the project and deciding if Redux is even necessary. Does it fit your team, does the project still need a state management library and if yes, are there perhaps better alternatives?
On the flip side, when the moment is right, trying to rebuild something as complex as a fully featured JavaScript library could be an amazing learning experience even for seasoned developers.
As helpful as NPM packages can be, they can also be more trouble than they’re worth. You might find yourself using a package and trying to adjust it to the requirements of the project only to discover it doesn’t quite do it the way you’d like it to or is incompatible with a version of another package.
See, the thing you must keep in mind is the original purpose of some of these libraries. Usually they answer some need that came up in another project or what someone thought would be beneficial for others. You see this countless times with UI libraries developed for certain frameworks using a commonly used design language like Material Design.
These libraries will write components in a particular way that makes sense for the broader use case. This might not fit with what you need for your project and then you end up fighting the existing library more than you need to.
Consider the requirements for the project or the library based on its flexibility. Sometimes you don’t need dropdowns that can autocomplete or filter a list, but a plain HTML select will do just as well.
Any modern JavaScript project needs to consider performance at some point. It will always rear its head through poor code performance, infinite loops, or more commonly, large JavaScript bundles delivered to users’ devices.
Let's revisit the popular Redux state library for a moment. Adding it unnecessarily to a project you could have built without it will result not only in bloating the app bundle, but also the complexity of the project code.
Do not, however, take this as the absolute truth for all projects. There is a very good reason Redux is as popular as it is. It scales extremely well and it’s both mature and reliable for production use, but it’s not the only solution.
If you can create your own custom component for the project you’re working on instead of just adding an external one for convenience, you’ll create it exactly to the required specifications, and only add the minimum amount of code required for the project.
As important as all these points have been so far, one of the biggest factors will probably be the amount of time and budget you have. Using an existing UI library like Material Design can exponentially increase your productivity when creating new projects. So don’t be afraid to embrace some of the limitations that can come with these libraries. Features don’t always need to be as complicated as we think they should be.
On the other side of that coin, make sure you take a moment to consider how long it will take to build it from scratch. Perhaps you’re spending a little bit of extra time right now, but that investment will end up saving you lots of time further down the line. Instead of wrestling with a library to do what you want it to, adjust your code to serve the exact needs of the project.
We can certainly make arguments for both sides of this topic, but your focus should be on what’s best for the project and the team. While you are trying to optimise the output of the project, don’t be afraid to take some calculated risks. Ask other developers who’ve worked with it before about their experiences.
Should it be a huge success it doesn’t mean you’re done, because you’ll need to adjust your thinking for each project. If you end up stumbling, see it instead as a learning experience. You or your team will become better developers because of it, then use that knowledge to guide the next project you work on.
Head of Front-End Development