When programming became gluing libraries togetherA couple of months ago, I did a talk on Web Components for a tech company where most attendees had no prior experience with them. It was a very fun and well-received talk that ended with a round of questions from the audience that lasted over half an hour.
Near the end, someone asked me if this meant that we were going back to the days of what he called “jQuery-like spaghetti code,” due to the raw DOM manipulation code I had shown. I could see some others nod in agreement, and this reaction really got me thinking.
A whole generation of developers got started using frameworks and starter kits that come with a whole bunch of dependencies out of the box. Just run npm install and tweak the code templates to your needs.
While this can be a good place to start, we do need to realize there’s more to programming than gluing third-party libraries together.
I’m Not Against DependenciesLet me first make it clear that I don’t advocate against the use of dependencies. In fact, I have quite some experience with multiple front end frameworks.
I do, however, encourage you to ask yourself if you really need these dependencies for your next project before you think about which ones to use.
This is a very important question to ask yourself. It’s a question that I feel is not asked enough, if it’s even asked at all.
The Fallacy of “Don’t Reinvent the Wheel”You probably heard this many times already. As a developer, you shouldn’t “reinvent the wheel,” but instead, you should use a library that already does what you’re trying to build.
This is good advice when you need a database ORM, for example, because it doesn’t make sense to write that from scratch when there are already good ones available.
The problem is: Where do we draw the line when deciding what to code ourselves and when to use a third-party dependency?
In 2016, the developer of the left-pad package decided to remove all his packages from NPM over a legal issue, and he almost broke the internet by doing so. It was illustrative of how insane the reliance on third-party software has become.
The only job of left-pad is to pad out the left side of a string with zeroes or spaces. The package consists of only a few lines of code, and it can be written by a junior developer in a few lines as well. In fact, it has already been deprecated in favor of the standard String.prototype.padStart(), yet thousands of projects depended on it.
And it gets even worse. The package isarray consists of only four lines of code and checks if a given argument is an array. Of course, this is meant for older browsers that don’t support the native Array.isArray() method, but this could literally be written in one line of code by any developer.
Coding that yourself is not “reinventing the wheel.” There’s really no need to have this as a dependency in your project.
We Have No Idea What We’re UsingStill, people argue that it’s better to use already available third-party modules — even when they’re very small — because these have been “battle-tested” and are “proved solutions.”
The question is: Are you sure?
Do you know that a dependency is a well-tested and proven solution, or do you just assume it is?
Do you really know all the stuff that’s in your node_modules folder?
I don’t, and probably nobody does. In all honesty, you don’t have to, but at least you should think about what to install as a dependency and what to code yourself.
Do you really need a bloated library to make simple HTTP calls when there’s already fetch in every modern browser? Or a large date parsing library that you can write yourself in a few lines of code and that does only what you really need?
It seems like a whole generation of developers are too insecure to write and use their own code, and instead, they resort to gluing libraries together that they assume to be well-tested and bug-free.
But this is a false sense of security.
How Did We Get So Insecure?Why are we as developers so afraid to trust our own code and rather use other people’s code we think is better and more secure?
After all, these people publishing their open-source code on Github are also developers, just like us. They’re not perfect either, and they might also write code that has bugs. Yet we choose to trust in them and not ourselves.
I understand that you don’t want to write a library like RxJS or React yourself, for example. These are large libraries that have been around for years, have many contributors, and are well-tested. I wouldn’t recommend reimplementing these unless you want to learn from it.
But for smaller functionality that you can easily code yourself and fully adapt to your own needs, I would recommend to write this yourself. At least you can easily modify and fix it when needed.
These are abstractions that, by their nature, are perceived as complex. Because of that, developers tend to use these as black boxes.
Again, I’m not anti-framework and I do see the value they bring. But now, it seems like there’s a whole generation of developers that only know how to program using a framework and have little-to-no knowledge of the underlying platform. They wouldn’t know how to work with the raw DOM because they have hardly been exposed to it, if ever.
I’ve been involved in a couple of evergreen projects where the first question was which framework we should use, not if we even should use one. The default assumption was that a framework was needed, and the main argument was that a framework would provide everything we needed and we shouldn’t reinvent the wheel.
The irony is that many of these people didn’t have enough knowledge of the native platform to tell whether or not the chosen framework was a good choice in the first place.
It’s understandable that the complexity of these frameworks is intimidating, especially for beginning developers. They’ll tend to use them as black boxes without understanding how they work internally.
Frameworks don’t encourage this either since their job is to make programming easier to get started with by hiding low-level details and APIs.
This creates dependence on the framework, which in turn doesn’t help in giving developers the confidence to code things themselves.
Using Dependencies Is Outsourcing Your BusinessWhen you’re using a dependency in your app, you’re basically outsourcing that part to some other developer, and so you better be sure that person is doing a good job.
If you have a business and you outsource customer service to some other company, you’d be in big trouble if they’d mess it up. What if they have a different idea of what good customer service is?
You probably wouldn’t let that happen, and you should treat the dependencies in your app in the same way. That doesn’t mean you need to read all of your dependencies’ source code, but at least you should have a solid idea of how it works.
Front end frameworks definitely bring value, but also complexity and overhead. I’ve been through the pain of learning and implementing several frameworks, and I can tell you that you need to make sure the effort is worth it.
There’s no reason not to use the native platform, and you’ll be surprised to see what it has to offer nowadays.
Don’t just parrot the people saying you shouldn’t reinvent the wheel. Learn the foundation first, and then decide whether or not you really need that library or framework.
You’ll be a better developer for it.