Down With Javascript*

2025-08-09

It seems so out-of-character for the fast-paced world of technology to just flat-out fail to react¹ to changes. However, here we are in a day where we've learned so much and innovated so many cool techniques and yet we still insist on re-writing the browser INSIDE the browser!

"What is that supposed to mean?" some of you may ask while standing up, oiling your beards, straightening your glasses, and preparing for the type of smackdown that only a seasoned developer can dish out². The camera would show an extreme close-up of my mouth as it smirked and after a dramatic pause I'd whisper "Down with Javascript." and all hell would break loose.

But seriously: Why are we still using Javascript to rewrite the browser even after the browser is fixed?

After reading Jono Alderson's great article "It's time for modern css to kill the SPA" I was inspired to write this post and take it one step further: Let's just kill Javascript³.

A Sticky Standard

Let's cast our minds back to the days of Flash content on the web. Why did it exist? To me the answer is pretty simple: It was able to do things that HTML, Javascript, and the browser were unable to accomplish. Animations, interactions, fancy fade-outs, and even audio. You name it, Flash could deliver and, perhaps most importantly, deliver it with consistency⁴.

The funny thing here is that Flash was making the web "modern" by bypassing the web almost entirely. Sure the .swf files were still delivered over HTTP but once they were downloaded Adobe took over and the browser just became the TV hooked up to your GameCube. It didn't matter at the time because users were getting what they wanted and everyone building for the web could deliver their products exactly how they wanted.

While it's obvious now that things wouldn't always be this way, simply writing off browsers, HTML, and CSS became the normal attitude. This is a prime example of a "sticky standard"⁵: a rule (or set of rules) that is difficult to change. In this context the standard was "browsers/html/css just can't do it." That mentality stuck and it stuck hard. Nowhere is this more evident than in the existence of React and React-like libraries/frameworks and, quite frankly, the Javascript ecosystem as a whole.

If Only We Didn't Have to Use Browsers!

Early on when I began seeing React and other front-end frameworks my initial reaction was one of discomfort. First, I'm admittedly not a huge fan of JS⁶ so read this post knowing that its author has a lot of bias but I felt like we were going in the wrong direction. Browsers had improved tremendously and while far from perfect were much more consistent. All of these effort to recreate routing and a virtual dom made it seem like everyone was just trying to figure out a way to not use the browsers and their built-in support for HTML and CSS.

I'm not discounting the struggle. Browsers have only recently managed to eliminate themselves as the de-facto "problem child" on the web. But today, we've entered a time where modern CSS can replace most of our SPA-like functionality. I'd like to believe we're also in a time where we care even more about efficiency⁷.

Just Stop

There are many great examples out there but just look at what Ruby on Rails is doing for front-end development (yes yes, I know their framework is beefy but humor me for a sec). With things like Turbo and Stimulus they're pushing devs away from even writing Javascript. Honestly it's rare that you need much and when you do, you can usually accomplish what you need with a sprinkle of vanilla JS. Not everything has to be an app and with CSS transitions and things like Speculation Rules we can shed a LOT of weight and make things run faster with a lot less code. That's inherently a good thing, right?

I think we need a return to server-rendered content and lightweight delivery to browsers that are more than up to the task.

Do Less

In conclusion, we really don't need 20 metric tons of Javascript to recreate the browser inside the browser anymore. We can drop the idea of "the browser can't hack it" and start thinking about how to make things easier to develop, and more performant for our users.

I'd love to hear your thoughts: rick [at] makethingswork [dot] dev

P.S. A kind reader reached out with an excellent email that has compelled me to make a clarifying point and bring up a couple of great thoughts.

First, the title is hyperbole, I don't want to kill all Javascript, but I DO want to stop using heavy frameworks for literally everything. There are ways to make very interactive, performant, and highly polished applications without reaching for something like React that is, probably, overkill for your use case. But even the solutions I mentioned (Turbo and Stimulus) are Javascript frameworks. It's a technology that will never go away, and shouldn't, as it's an immensely useful connective layer between the server and the client.

React has its uses. Large JS frameworks have their uses. Like any tool, they have their proper application. Massively complex UI's with a lot of state management are very difficult to achieve without some form of library and building a game engine with nothing but HTTP calls would be less-than-ideal (I say with intentional understatement).

Additionally, it's worth pointing out that, while these frameworks are undoubtedly overused, they have played a significant part in driving innovation in the world of web standards (and, of course, have their appropriate uses today). JQuery created a lovely way to interact with the DOM, but now it's practically part of vanilla JS⁸. In the same way, these frameworks signal very clearly what devs need and want from the web and thus drive the new standards that we enjoy today.

-- Rick

#javascript #rails #rant