Zzzzzooooooooooom.
What was that sound? Oh, you know, the usual. That’s the sound of the JavaScript community stampeding on towards a new framework. Yep. Right after you just got comfortable working with the one that you’re using now. You were left behind yet again. Pack up, it’s time to move.
Hope you’re ready to learn something new. Again. Sigh.
Wouldn’t it be nice if we had a predictable, dependable platform that was always going to be around, even if it wasn’t the cool kid on the block? Like that one friend you had back in high school; they were a bit awkward, never really a part of the popular crowd, and smelled a bit funny–but goddammit, they were there when you needed them.
JS developers: that friend exists. And it’s been a part of your browser since 2014 with the introduction of Web Components.
Here are three reasons why Web Components might be the answer you or your organization has been searching for.
First, Web Components are built using native JavaScript language features. No need to learn any custom approaches by specific opinionated frameworks. Reduce your fatigue! Be lazy! It’s possible to make web applications using the classic and familiar JavaScript syntax you know and love.
Second, Web Components are stable. The slowness in which Web Components evolve is, believe it or not, a feature. This helps WCs to be supported in all major evergreen browsers, and that major consideration goes into the design paradigm before anything gets published to the spec.
Remember when the community thought client-side single-page applications were the future–then suddenly changed its tune and decided to move every application to be rendered on the server? Yeah, let’s not get ourselves in that situation again. Betting on native approaches is way more likely that your work won’t be rendered obsolete or frowned upon in a few years time.
Lastly, Web Components are compatible with any JavaScript framework. You might have a JavaScript library that you want to make available for React developers, Svelte developers, and Vue developers. What are you going to do? Publish a custom package for each environment? That sounds exhausting. Wouldn’t you rather be using your time to do something fun? I hear water coloring is relaxing and therapeutic (which you might need after managing code for all of these ecosystems).
What if, instead, you wrote your code once, and it was supported everywhere? Friends: this dream is possible. Web Components can be easily imported into any application and leveraged as if it were a native part of what that framework has to offer.
As a React developer working with Web Components for the first time, I’ll be honest with you: it takes some getting used to. Specifically, state management has been a little tricky. Some of these frameworks make it a lot easier to figure out how to solve for that. But I’m already getting the sense that the tradeoffs could be worth it for our application and use case.
I’d encourage you to give Web Components a try and see how they work for you! Maybe you’ll enjoy water coloring after all.