People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc.
Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too.
That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine.
So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection.
I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms.
Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones.
And JS will be replaced, but we don't have a good enough garbage collected language for it yet.
edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?
Nobody is trying to convince you to build a chess app that doesn't use JavaScript.
More importantly, Alex is not arguing for you not to build things with JavaScript either!
He's arguing against writing inefficient JavaScript where you ship MBs of code to the browser to serve simple functionality.
Scroll to the footnotes and you'll find a big list of JavaScript frameworks which Alex does recommend, because they optimize for performance and low overhead.
What do Solid, Svelte and Vue bring to the table exactly? None of those frameworks solve the dataflow problem and the performance benefits they bring do not make a dent. Also why would I want to use some DSL for html templating when I could use an actual programming language?
I personally like the article and I respect author deeply, as he's one of the people who did a lot for the web. Many developers have been raised on his articles and materials.
However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)
Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.
But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.
This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:
> Also why would I want to use some DSL/html templating when I could use an actual programming language?
I feel like the core issue is that HTML is radically insufficient, so DSL/Templates come into play to alleviate the burden. What's generally worse is having everyone going their own way doing random stuff within an org, so best practices must emerge and that starts to feel like a DSL in a way.
Perhaps I interpreted the article differently, but I don't think it's about Javascript - it's about complex Javascript frameworks. Ie, ones that cause bloat via large dependency trees, and unnecessary computations. These aren't required for the interactivity you described.
I've written one of those React clones in Rust you mention. It was as you say - as much of a mess in practice as a JS framework.
I get that and that's part of the point of my comment. That these screeds always make sure to mention javascript because by bundling javascript in the screed you get default acceptance from the JS haters.
But the fundamental essence of the article is about complaining about SPAs. Which betrays a striking ignorance of what most frontend web software engineers are working on. They are not working on websites for businesses that only need a single form and an email to get the form responses. That usecase is solved and does not require a software engineer. It can be built on wordpress or squarespace.
SPAs are the answer to the question of how do we build an app that is delivered in real time over an internet connection.
The reason these apps are built with JS is because until relatively recently it was the only option. Why is it still used while there are other options? Because WASM is not mature and JS is still faster and there is no killer reason to switch off it.
> People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc.
Facebooks and youtubes and tiktoks are built to push ads most efficiently and SPAs are just that. You're not the customer for them, you're product.
Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too.
That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine.
So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection.
I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms.
Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones.
And JS will be replaced, but we don't have a good enough garbage collected language for it yet.
edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?