SolidJS is Not the Future

Use the Platform™ has become an amusing rallying cry which is essentially more of a philosophical argument than a technical one.

Which is why I’m going to avoid virtually all technical jargon in this article, because I’m not here to refute Ryan Carniato.

I’m here to tell you how much I resent we’re even having this conversation in the first place.

Ready for some real talk? Good. Let’s goooooo…

Bad Web Standards Are Always Better Than Good “Userland” Solutions #

This is the first point I want to make, which is that if I can do something with a native “vanilla” web API, and that API is “less good” than a clever API written by a clever developer in userland, I will invariably go with the vanilla API.

Because in 10 years, we’ll have gotten used to that bad API, we’ll know how to deal with it, and we’ve moved on. Whereas in 10 years, the added support and cognitive burden of understanding and supporting that broken/outdated/deprecated/refuted dependency which was once thought to have been a clever API by a clever developer just isn’t fucking worth it.

In other words, I’m sorry Ryan Carniato, but I won’t be using today’s SolidJS in 10 years, whereas I will be use today’s custom elements in 10 years. That’s just a fact. And I know it’s a fact because of all the other vanilla web APIs I use today in the same way I used them 10, 20, even ~30 years ago.

Teaching People How to Write Less-Good Vanilla Web Apps is More Valuable than Teaching Frameworks #

Again, if you brought a junior developer to me who is seeking education, and asked me if I thought they’d be better off writing applications which are “less good” (in whatever metric you care to measure…let’s say slick UI polish for the sake of example) using vanilla APIs or writing “more good” (aka slicker) applications in the frontend framework du jour, I’d say the vanilla route is much more valuable.

Because those are skills which are going to be applicable to all projects, in all categories, for all users, in the years and decades to come. Whereas all the skills you learn in a particular frontend framework are by and large specific to that particular framework at this particular moment in time.

Furthermore, you can still apply many of the vanilla skills you once picked up now that you’re working in a framework in order to solve thorny problems no one else understands, whereas the framework stans are often rather lost without their framework.

I know this because for years now I have seen, over and over and over again, people missing out on great vanilla solutions to common problems because they never heard about them or don’t grok how they work…because of all the noise of userland JS solutions. I recommend every framework stan spend a few hours every month poring over MDN and other resources to learn what’s new for the web platform. That kind of platform-level developer knowledge over time is worth its weight in gold.

(Also, truth is that framework-y web apps regularly offer worse UX anyways, exhibiting severe performance and reliability issues. But I’m not even here to make that argument. Go talk to Alex Russell.)

Your Framework is Incompatible With My Stack #

This is perhaps the most damning argument I’ll be making today. The idea that I have to switch my entire stack over to your metaframework in order to make the most of your frontend framework is fucking bullshit.

Let me make myself quite clear here:

• I’m not going to adopt Next.js just so I can use React.
• I’m not going to adopt Nuxt just so I can use Vue.
• I’m not going to adopt SvelteKit just so I can use Svelte.
• I’m not going to adopt SolidStart just so I can use Solid.

There’s really only one JS metaframework I can think of that’s achieved some popularity in recent years and for good reason, and that’s Astro. And the thing which makes Astro rather awesome is precisely because you can start with real vanilla HTML, CSS, and JavaScript—and then go beyond that only when and where you need to.

Use React! But just on that one page where needed. Use Vue! But just on that one page where needed. And so on and so forth.

And guess what? Astro is a great place to get started using web components as well! Heck, you can even server-render Lit web components. Yeah, seriously.

Actually, Web Components Are Components #

I will now annoy many of my friends who do advocate for web components, because I reject the framing that “web components aren’t components” and that you can’t really replace the idea of framework components with web components.

I simply don’t agree with that argument at all.

You absolutely can build an entire web application out of components and those components can be custom elements and those custom elements can be called web components.

No, I’m not going to get into the nitty-gritty technical details here because that’s not what this article is about. You’ll either trust me on this, or not. That’s entirely up to you.

But it really, really, really bothers me that even while praising web components, we must for whatever reason feel the need to show deference to userland JS frameworks. Like, somehow, their concepts of what a “component” is and how “components” should work are so immensely important, we gotta give credit where credit is due.

Nope. 😝

If React, Vue, Angular, Svelte, Solid, etc. all simply “poofed” out of existence tomorrow and all we had to build web applications with were vanilla APIs & web components, a tiny handful of tiny userland libraries for a healthy splash of DX, and good ol’ fashioned server-side web framework stacks in a variety of server-side languages which have been trucking along just fine for the past 20+ years, that would be perfectly fine with me.

I simply don’t respect these frontend frameworks. Never have. Never will. I actually think—on the whole—today’s web is far worse off because of them.

But you do you.

This Entire Discussion is Pointless and Stupid #

I will now end this blog post with the rant of all rants. You’ll probably want to unfollow me on all the socials. Good for you!

I hate this conversation, I resent having to talk about all of this YET AGAIN, I think the JavaScript ecosystem is full of donkey-doo, this is all stupid, and talking about if web components should be web…components…AARGH it makes me want to gouge my eyes out. 😖

It’s time to touch grass, y’all. Go walk through a meadow by a lake. Enjoy a cuppa with your friends. Watch a movie. Write a poem. Throw a ball. Bake a cake.

Anything—anything—ANYTHING but this. 😭😭

We are literally shitting on the World-Wide Web as a healthy platform for reasonable people to build nice things on by endlessly arguing points which were already moot years ago.

Ryan Carniato, and a hundred clever developers like him, can write 1,000 more articles on DEV.to saying things like “the promise of Web Components is so alluring and so dangerous” and none of it actually matters. None of it.

But maybe that’s just me. I wake up every morning and ask myself if I even still want to work in this industry…for these very reasons! (checks watch) Oh, is it time for another Tailwind vs. Vanilla CSS debate again? Should we argue about if Safari is, indeed, the New IE™?

I DON’T FUCKING CARE!!!

Meanwhile, on Planet Earth, real people are having real problems. Generative AI is shredding any hope of creative people to make an honest day’s living, climate change is wiping out parts of modern civilization, political parties are being held hostage by radical extremists who hate democracy, housing prices are going through the roof, car culture (even with EVs!) is polluting urban environments, VC-fueled crony capitalism is enshittifying basic digital goods and services on a daily basis, and the bottom is falling out of sustainable open source due to maintainer burnout and corporate consolidation & entrenchment.

But nooooo, let’s not focus our precious waking hours on addressing these existential human issues, and instead let’s talk again about FUCKING WEB COMPONENTS !!??!?!! 🤬

I’m done y’all.

I’m done.

<im-done>So long, and thanks for all the fish.</im-done>

P.S. Subscribe to my podcast. It’s like ranting in a blog post, but there’s two of us and it’s way more fun! 😁