My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available.
We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done.
So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.
I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web.
I think the answer lies in part in this line:
“The complexity merchants…”
With so much free money floating around, software development has grown more bureaucratic than ever.
I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat.
One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” - Dijkstra
> I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now.
It is important to look at these things in a context of software fads... Back when Google/Facebook got big around 2007-2008 it was all about big data cargo culting, then era of frameworks & efficiency & productivity, following that epoch of apps, after that we've had blockchain, and now AI & chatGPT are "eating the world".
Of course in the middle of that we've also had a huge bull market with tons of money thrown at everything.
I think part of the problem is the nature of ownership versus a salary. Would you rather have equity within a company and partake of the profits, or would you like a nice salary?
I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
The money has something to do with it. But with too much money in the system. People hoping jobs too quickly. And the accountability loop for producing bad systems is short circuited and ineffective. Hype cycles where young devs never see the other side where they fall flat.
Does anyone else find this writing style hard to follow and alienating? The clever section titles, verbose passages, inflated vocabulary, and indirect descriptions, make it frustrating to read. Just say things directly.
The writing does a horrendous job presenting an argument. The author constantly references events and trends but does not focus on specifics until much later in the post. Even then, he paraphrases, making it even harder to judge the evidence.
TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
Every non-SPA that I’ve worked on ended up accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well.
I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective.
I personally don’t miss the old native UI days.
The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens.
Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview.
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
> the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.
If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.
My god, this article reads like a non fiction incarnation of "infinite jest" its basically impossible to understand the authors concrete intent and meaning of whole paragraphs without reading the footnotes and the linked articles while reading the post. And if i understand it correctly, it completely misses the point who is to blame. Angular and react solutions were seldom sold from an actor with deep information to a manager or business with less information. In my experience the top 2 situations were a) managers/half-technical founders wanted what they had read about and google or facebook were backing and did not want to hear about a proper evaluation, b) devs and whole dev teams wanted to just use what they knew and read about 100% thinking this was the best solution because of their inexperience and lack of reflection. The first is just your usual ignorance towards the experts by buzz word driven and half-knowledge managers, the latter could be more likened to the brainwashing of cult members than intransparent market situations.
I can't look at an app and tell you that it's written in framework A or B, but so many websites are becoming dogs these days, and not just because they have to run Javascript. I think the scripts actually spend a lot of time blocking on the I/O that would have originally been delivered with the initial page. Server side rendering may be a solution but it seems lots of sites have a rather modular approach to putting components on a page that then load lazily over ridiculous amounts of time.
As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.)
Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.
I remember when Reddit (old.reddit.com, the good one) loaded ultra fast and didn’t move around. I could use the back button without noticeable waiting.
And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow.
SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
At this point articles like this exhaust me beyond the point of caring. The popular tools are all reasonably good and in my experience the people complaining about the JavaScript ecosystem do so at the expense of getting stuff done.
Absolutely. Always eye-roll inducing, particularly the ones with bitter, angry, or in this case accusatory tones. JS solves problems people have, and it's not goin away anytime soon. I would love to be something other than a frontend code monkey, but I don't see that happening anytime soon. I just wish people here could shut the fuck up about it.
The author spends the bulk of the post (as far as I could tell from the opaque writing style) criticizing React and the React ecosystem.
But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably:
Preact (basically just another implementation of React)
Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc)
SolidJS
Svelte
Etc.
Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above).
Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".
> You wouldn't know it from today's frontend discourse, but the modern era has never been without high-quality alternatives to React, Angular, Ember, and other legacy desktop-era frameworks.
"You wouldn't know it from today's frontend discourse"??? Seriously? Everybody and their dog know about those frameworks.
It feels like the first footnote was added in response to criticism from the reviewers of the drafts. It contradicts the body of the article and makes the whole thing incomprehensible.
The original article must have been a criticism of frontend frameworks in general. It points to the "sandy foundations" and frames all attempts at solutions as simply adding complexity - probably including all those new frameworks everybody talks about.
I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought.
Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it:
https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages.
My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers.
If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to?
Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions.
Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man!
The senior eng team absolutely regrets going Next.js (decision made before I joined).
The article is a bit too bitter for my taste, but I agree with most of it. Except for the developer experience improvement these frameworks supposedly offer, I don’t even buy that.
For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever.
I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since.
I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.
I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience.
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
TFA is a rant that seems mostly targeted at React, judging from the links/examples. The article is not very clear or easy to follow but it still has a point. All modern frameworks are ridiculously complex, esp. given the fact that modern JavaScript is extremely versatile, with classes, modules, web components, etc.
A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer).
It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.
As someone whose worked with React/Angular/Svelte/etc for the past 5-6 years, the biggest benefit and the biggest hurdle to these frameworks is the complexity. The complexity in these frameworks has resulted in us being able to build massive complex applications, but if not done with the proper level of care, that application will be a performance crap sandwich.
And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup.
But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app.
All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.
And there are a number of vulnerabilities with those packages, which are not being fixed. I think NPM should remove any package that are not maintained or have severe (any?) vulnerabilities. IMO, we have too many packages,some restriction to publish will be good.
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.
Has this author been on the other side of the fence? I have encountered, for every bloated javascript problem child, an equally burdensome python monolith, or sprawling maze of go microservices. I suspect the root cause is something to do with human error, but I digress.
The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.
We are replacing truly the most disgusting codebase I've ever seen right now, a WP instance (alright) highly customized (worrisome) written by pre-for-loop contractors (uh-oh) which has over 10k lines of jQuery (uh-oh) for a relatively small site, but all of the jQuery lives in one main.js (UH-OH) and executes on every page whether or not it does anything to that page. It's also written in such a way that it crawls the DOM so many times on huge HTML payloads that the entire page slows to a crawl as your computer fan winds up. You'll often get 10 seconds of non-responsive page after the first paint. There's barely any interactivity here as well, just a couple of modals and buttons.
As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting.
All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.
> We lost a decade to smooth talkers and hollow marketeering
To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).
Despite all this NextJS has brought me a lot of joy using it. Probably the most joy of all front end experiences web or even desktop (and I quite liked WPF!)
That said I get it: it can be
annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing.
The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.
The author is not advocating for native apps over Web apps. That's not the pretext for this post, and if you're reading it (and the author's motives) through that lens, then you're reading it wrong.
(In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)
I wish I knew what the author was fulminating about.
This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article.
Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.
Is the author talking about information websites, websites with limited interactivity, or web applications that would feel more at home as desktop applications?
I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.)
That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.
the author recommends in the first footnote to use other frameworks like vue, svelte, lit/polymer etc., which makes this seem more like an argument against react, when the entire article is about how javascript-driven spa/ssr stacks are bad. there are a couple clarifications next to it to soften that blow but react also "start[s] with simple output" in the same way these tools do. why act like react is the only lemon merchant? i say this as an active user of vue, so maybe im simply at the most complex of them but from my perspective the other tools are about as complex
[+] [-] locallost|3 years ago|reply
One of the linked articles is much better and to the point: https://ericwbailey.website/published/modern-health-framewor...
My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available.
We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done.
So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.
[+] [-] cxr|3 years ago|reply
The recurring resume-requires-React pattern sure isn't helping.
[+] [-] Existenceblinks|3 years ago|reply
[+] [-] travisgriggs|3 years ago|reply
I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web.
I think the answer lies in part in this line:
“The complexity merchants…”
With so much free money floating around, software development has grown more bureaucratic than ever.
I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat.
One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.
[+] [-] doctor_eval|3 years ago|reply
[+] [-] TrainedMonkey|3 years ago|reply
It is important to look at these things in a context of software fads... Back when Google/Facebook got big around 2007-2008 it was all about big data cargo culting, then era of frameworks & efficiency & productivity, following that epoch of apps, after that we've had blockchain, and now AI & chatGPT are "eating the world".
Of course in the middle of that we've also had a huge bull market with tons of money thrown at everything.
[+] [-] mathgladiator|3 years ago|reply
I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
[+] [-] drewda|3 years ago|reply
[+] [-] BackBlast|3 years ago|reply
It's the engineers and orgs, not the tools.
[+] [-] stevebmark|3 years ago|reply
[+] [-] apozem|3 years ago|reply
[+] [-] slightlyoff|3 years ago|reply
TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
[+] [-] tjpnz|3 years ago|reply
[+] [-] christophilus|3 years ago|reply
I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective.
I personally don’t miss the old native UI days.
The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens.
It is a misplacement of blame to blame React.
[+] [-] xyzelement|3 years ago|reply
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
[+] [-] danielvaughn|3 years ago|reply
I didn’t understand that until I became a manager. Your whole perspective shifts because you realize that salaries don’t just grow on trees.
[+] [-] patrickthebold|3 years ago|reply
Sticking with what you know is generally good advice. Especially if you consider hiring and onboarding.
[+] [-] sublinear|3 years ago|reply
I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.
If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.
[+] [-] jFriedensreich|3 years ago|reply
[+] [-] giaour|3 years ago|reply
You did not. Per the article, the "buyers" of SPAs are the developers and teams who heard about a technology and thought it would be the right tool.
[+] [-] projektfu|3 years ago|reply
As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.)
Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.
[+] [-] MBCook|3 years ago|reply
And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow.
SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] beckingz|3 years ago|reply
[+] [-] ng12|3 years ago|reply
[+] [-] DangitBobby|3 years ago|reply
[+] [-] ramones13|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] naet|3 years ago|reply
But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably:
Preact (basically just another implementation of React)
Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc)
SolidJS
Svelte
Etc.
Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above).
Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".
[+] [-] squillion|3 years ago|reply
"You wouldn't know it from today's frontend discourse"??? Seriously? Everybody and their dog know about those frameworks.
It feels like the first footnote was added in response to criticism from the reviewers of the drafts. It contradicts the body of the article and makes the whole thing incomprehensible.
The original article must have been a criticism of frontend frameworks in general. It points to the "sandy foundations" and frames all attempts at solutions as simply adding complexity - probably including all those new frameworks everybody talks about.
[+] [-] CharlieDigital|3 years ago|reply
It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table...
And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages.
My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers.
If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to?
Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions.
Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man!
The senior eng team absolutely regrets going Next.js (decision made before I joined).
We've been fleeced.
[+] [-] tambourine_man|3 years ago|reply
For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever.
I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since.
I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.
[+] [-] twodave|3 years ago|reply
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
[+] [-] sublinear|3 years ago|reply
You just described exactly why most web devs strongly prefer to build SPAs today instead of using SSR (separation of concerns).
[+] [-] bambax|3 years ago|reply
A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer).
It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.
[+] [-] _fat_santa|3 years ago|reply
And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup.
But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app.
All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.
[+] [-] nnurmanov|3 years ago|reply
[+] [-] friedman23|3 years ago|reply
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?
[+] [-] simonw|3 years ago|reply
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.
[+] [-] quxbar|3 years ago|reply
The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.
[+] [-] DangitBobby|3 years ago|reply
As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting.
All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.
[+] [-] college_physics|3 years ago|reply
To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).
[+] [-] quickthrower2|3 years ago|reply
That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing.
The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.
[+] [-] postalrat|3 years ago|reply
Installing, maintaining, and securing native apps is too much trouble.
[+] [-] cxr|3 years ago|reply
(In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)
[+] [-] effie|3 years ago|reply
The real reason is HTML/JS/CSS is universal platform to code against, unlike myriad of OS-specific toolkits.
[+] [-] Sai_|3 years ago|reply
This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article.
Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.
[+] [-] ebiester|3 years ago|reply
I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.)
That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.
[+] [-] asherah|3 years ago|reply