Providers
If you’re building software, it’s generally a good idea to avoid the Not-Invented-Here syndrome. This is when you insist on writing absolutely everything from scratch even if it would make more sense to use a third-party provider.
Need your app to take payments? Don’t try to become your own payment provider—use an existing provider instead.
Need your app to send email? Don’t try to code all that up yourself—just use an existing service.
This same thinking seems to apply to JavaScript libraries too. If you don’t use a library or framework, you’ll just end up writing your own library or framework instead, right?
Except that’s not the way that JavaScript frameworks work. At least not any more.
There was a time when JavaScript libraries really did abstract away browser differences that you probably didn’t want to deal with yourself. In the early days of jQuery—before querySelector existed—trying to work with the DOM could be a real pain. Libraries like jQuery helped avoid that pain.
Maybe it was even true in the early days of Angular and React. If you were trying to handle navigations yourself, it probably made sense to use a framework.
But that’s not the case any more, and hasn’t been for quite a while.
These days, client-side JavaScript frameworks don’t abstract away the underlying platform, they instead try to be an alternative. In fact, if you attempt to use web platform features, your JavaScript framework will often get in the way. You have to wait until your framework of choice supports a feature like view transitions before you get to use it.
This is nuts. Developers are choosing to use tools that actively get in the way of the web platform.
I think that most developers have the mental model of JavaScript frameworks completely backwards. They believe that the framework saves them time and effort (just like a payment provider or an email service). Instead these frameworks are simply limiting the possibility space of what you can do in web browsers today.
When you use a JavaScript framework, that isn’t the end of your work, it’s just the beginning. You still have to write your own code that makes use of that framework. Except now your code is restricted to only what the framework can do.
And yet most developers still believe that using a JavaScript framework somehow enables them to do more.
Jim Nielsen has a great framing on this. JavaScript libraries aren’t like payment providers or email services. Rather, it’s the features built into web browsers today that are like these third-party providers. When you use these features, you’re benefiting from all the work that the browser makers have put into making them as efficient as possible:
Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing new their offerings.
So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself.
Want to do nifty page transitions? Don’t use a library. Use view transitions.
Want to animate parts of the page as the user scrolls? Don’t use a library. Use scroll-driven animations.
Want to make something happen when the user clicks? Don’t use a library. For the love of all that is holy, just use a button.
If you agree that using a button makes more sense than using a div, then I encourage you to apply the same thinking to everything else your app needs to do.
Take advantage of all the wonderful things you can do in web browsers today. If instead you decide to use a JavaScript framework, you’re basically inventing from scratch.
Except now all of your users pay the price because they’re the ones who have to download the JavaScript framework when they use your app.