Panic at the SPA!

I began programming in 2015, now that’s not that long of a time, but coming on my 10 year anniversary I feel that it’s long enough that I can sit on my high pony and talk about the what the “good old days” where like. Really, it was the best of times, it was the worst of times, it was the age of PHP, it was the age of AngularJS. Considering that the best option for writing a SPA was AngularJS, and that no mere mortal would dare to recommend that a beginner learn that ghastly web framework, I existed in a programmer’s natural habitat: writing PHP in Notepad++ “hosting” L/WAMP on the LAN.

Soon, in a year or two, React would “get good” and then came the dark ages. I learned React late, it became appealing to the young and stary-eyed me who found out about GitHub Pages, free hosting (yay), and got tired of jQuery, .NET, and PHP in 2020^[1]. See when Elvis Presley sang “(You’re) The Devil in Disguise” he sang it about React, which (in my humble opinion) is the sole creator of the nine circles of Hell.

State-caused PAnic

In the real world, we’d use document to access the DOM. In React, like most SPA frameworks, the state of the application and the DOM are bound together. Developers often see this as a huge help in getting their applications off the ground, but as the complexity of the application grows (and the amount of things stored in the state of the application increases) keeping the unbearable weight of the DOM and state love story begins to make you wish that they could end up drinking alone.

The issue with DOM and state being managed together is that poorly written state logic, which is written in JavaScript or TypeScript mind you, can cause an overwhelming amount of pricy operations. React’s design of effects, and how components and hooks interact with one another in general, sets no unsuspecting developer up for success in this cruel and unfortunate world where memory leaks do in fact exist.

SPAs*

*with routers

How many pages does your single-page application have? If you answered more than one you might just be cooked. See, HTTP natively supports several pages and, if you hadn’t chose to use a SPA, you, probably, wouldn’t need to touch window.location.href, #, or query strings in order to create the illusion that there are several pages for your application.

Before my personal age of enlightenment I too was foolish, I figured that building a router for my applications was normal – and seemingly had no drawbacks. The truth is that the web was built around the idea of every page being an independent file. Not following this convention breaks your application’s compatibility with other services and tools – such as those for SEO and accessibility.

Performance

With many SPAs everything is rendered by JavaScript. There is some “optimization” that can be preformed, such as Next.JS’ Server Components that will render HTML on the sever, and it might not even be that bad – if you can figure out how to properly host Next.JS without using “the edge.” To chase more optimizations developers can setup hydration systems, allowing their servers to render even more of the content. Although this is simply more complexity on top of the already complex frameworks allowing developers to create SPAs, and produces feelings of déjà vu for AJAX^[2]. Plus, JavaScript on the server was a mistake and makes the operations that the server preforms, such as server components and hydration, more costly.

Tooling

If JavaScript on the server was a mistake now what does that make JavaScript on the desktop? A mistake. Okay, I’ll ignore Electron and React Native for now, maybe I’ll discuss how “true” desktop application development is down the drains as well in another post.

In most languages there is a single set of tools, but JavaScript isn’t most languages now is it? We have been graced with the presence of npm, the tried and true classic fork in the eyeball, and everything else which is faster but hasn’t taken off, yet^[3]. I’m not saying that these tools are exactly the worst things to happen to this universe, but giving developers (a naturally lazy species) a shorthand (npm i) to add external dependencies to their applications might be a close second.

Also, newsflash, JavaScript is an inefficient language, it was never made to be compiled – let alone to compile itself. Yet here I am in 2024 pondering the profound state of the micro-optimization differences between bun, yarn, and npm just to figure out the best way of creating a new web app.

npm

By this I mean the npm Registry. Look at left-pad, a “micro-package” which aids in the difficult task of adding a set number of strings before other strings. For the unaware this thing made it into React’s codebase and, when left-pad broke, rendered React unusable. This might sound like an isolated incident out of humor, but it’s just the JavaScript lifestyle.

There’s no logical reason for us to even have the term “micro-package.” If it’s so small that it’s “micro-” just throw it in a utils directory and never think about it again^[4] and, no, node_modules does not count as your utils directory.

Can’t we just get a good wheel?

I guess this is the issue with SPA. There are so many frameworks, all vastly different in behavior and convention, mostly due to the fact that it seem that everyone’s JavaScript is different. The language on a whole has set the mass migration to it up for failure, there aren’t even well-accepted standard styles, I mean I still don’t even know if I’m supposed to use two or four spaces!

It feels like we’ve made four thousand wheel, axel, body, and engine types but none of them fit on each other. The automotive industry is more interoperable than this!

That’s all folks!

Well, thanks for wasting your time with me. I spent a lot of time on this actually spent a lot of time on this so I hope you had fun reading it, but if you hated it you can direct the hate mail to the email on my homepage – same thing for all the love letters. If you always make SPAs I urge you to try something different, maybe give PHP^[5] a shot, and if you haven’t made a SPA before maybe try making one.

1. In defense of jQuery in 2020: I did a lot of different things other than web development in between all that (*cough* *cough* WPAs). ↩

2. Okay, I guess that’s mostly just partial hydration – but you get the point, we’re running around in circles. ↩

3. Don’t worry y’all, it’s a free market, they’ll take off soon! ↩

4. I’m not advocating for a utils directory, but it’s JavaScript so I know you already have one. ↩

5. Was this post just a plug for PHP in 2024? ↩