10 ms·

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network req

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct. But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead. Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.

buffalobuffalo 1y ago
I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js
- deleted 1y ago
  [deleted]
- kassner 1y ago
  ExtJS/Sencha was quite powerful and complete. I’ve built tons of SPAs with it in the late 00s.
  - gjtorikian 1y ago
    Wow, I remember Sencha! It’s been a while since I’d heard that name.
- dsego 1y ago
  I mostly remember doing $(document).ready blocks in php templates :)
- PaulHoule 1y ago
  I wrote my first SPA, a knowledge graph editor, using GWT (Google Web Toolkit) which compiled a dialect of Java to JavaScript circa 2006 or so.
TimTheTinker 1y ago
Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.
- andix 1y ago
  Latency might even be more relevant than bandwidth. Especially if it's a good SPA, that uses optimistic updates (or sync), and some kind of caching for fetching data (tanstack query or similar).
- cosmic_cheese 1y ago
  It really depends. There’s a lot of SPAs which are practically unusable on a bad connection simply because it’s a challenge to even get the whole thing loaded in the first place. There’s been several occasions where I’ve had poor cell connectivity and a huge chunk of the web was effectively off limits due to this. So in addition to aggressive caching, I’d say keeping the app’s file size down is also pretty important to making it useful on poor connections. That’s frequently something that’s barely optimized at all, unfortunately.
  - tomnipotent 1y ago
    All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.
  - jaredklewis 1y ago
    I work on an SPA with hundreds of screens. We package it using off the shelf tooling with barely any configuration. All of the code and styling is still far under a megabyte gzipped. So unless it is an all text app, the size of the code bundle is probably going to be quickly dwarfed by the size of media like images, animated images, or videos. If a site has an SPA with a, say, 3mb code bundle, I think in most cases, that’s not an architecture issue. It’s probably an issue of poor engineering and switching to a MPA is not suddenly going to make those engineers competent.
chaps 1y ago
Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)
- chrisweekly 1y ago
  Java applets are entirely distinct from SPAs, at least as that term is used in the webdev community.
  - chaps 1y ago
    Hm, alrighty then. Seems like an unnecessary distinction to me in that it deeply constrains what SPAs can be, but I'm not a webdev.
    - Dylan16807 1y ago
      The rule is either "uses html to render" or an even looser "renders in the browser". That doesn't seem like a deep constraint to me. You exclude a couple very popular but historical plugins where the browser set up a rectangle and handed it off to an external piece of code, and pretty much nothing else.
- threatofrain 1y ago
  Those apps came from an era when these terms weren't even coined yet.
- pstuart 1y ago
  I think of java applets as being more akin to wasm; SPAs were/are a collection of html that recreate the experience of a "plain old" html web site.
- brailsafe 1y ago
  Java applets and ASP.Net did have a superficial answer to this, as well as Flash, but they varied in terms of their ability to actually function as raw web interfaces using the URL to navigate between sections. Being able to reliably and programmatically interact with client-side storage and the url, as well as improvements in DOM apis and commodification of hardware with more ram and faster faster CPUs, among many others factors, seem to have contributed.
Cthulhu_ 1y ago
> and load up a giant pile of jQuery spaghetti I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification. Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; biggest ones was its modularization (which wasn't a thing in JS yet), dependency injection, and testability. When we started out with an app in Backbone (to replace a Flex app because it wouldn't work on the ipad), I actually advocated against things like testing, thinking that the majority of functionality would be in the back-end. I was wrong, and the later AngularJS rebuild was a lot more intensive in front-end testing. Of course, nowadays I'm repulsed by the verbosity, complexity and indirection of modern-day Angular code. or Java code for that matter.
- aryonoco 1y ago
  Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns. Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt new Angular patterns. Still, I believe Angular is a really great platform for building B2B or enterprise apps. It’s testing and forms handling is far ahead of every other SPA, and it actually fees like a cohesive framework where people have spent time designing things the right way; something I absolutely cannot say about react frameworks such as Next.js or Remix.
  - youngtaff 1y ago
    Angular was created so Java developers could create browser apps
    - leptons 1y ago
      Angular 1.x seems vastly different than Java. I doubt a Java developer would want to use it, so I'm not sure your claim is valid.
QuadrupleA 1y ago
Side note, sick of jQuery being always associated with spaghetti in the tech lexicon. Any Turing-complete system is spaghetti in the hands of bad programmers. And simple & clear in the hands of good ones who know how to design.
- sverhagen 1y ago
  Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. Not much to do about it anymore once the concrete has set. You can't still be an exception to rules, good for you! But that doesn't change the culture...?
  - albedoa 1y ago
    > If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. My bet is that everyone here both agrees with you and is able to replace "jQuery" with "HTML", "CSS", and "JavaScript" to reach similar conclusions about the cultures of each. The problem is bad programmers, not the tech.
- bobthepanda 1y ago
  Jquery is good for dom manipulation, though most of the best ideas have become vanilla javascript standards. It isn’t really equipped or opinionated on statefulness, which means that everybody was at one point kludging stuff onto it that didn’t make sense.
- PaulHoule 1y ago
  It drives me crazy when it used together with React —- I want to have one authoritative copy of the state of my app, and jQuery bypasses that, at least if I’m using controlled forms. Now I used to hate uncontrolled forms but now I like react-hook-form.
jiggawatts 1y ago
The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else. Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”. My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice. Theoretically, sure, but every app I come across just dumps half the database down the wire and picks out a few dozen bytes in JS code. There's a comment right here in this discussion advocating for this! [1] Another angle is this: if you had a top 100 site with massive bandwidth costs, then sure, converting your app to a SPA might make financial sense. But instead what I see is tiny projects start as a SPA from day one, and no chance that their bandwidth considerations — either cost or performance — will ever be a factor. Think internal apps accessed only over gigabit Ethernet. I’ve seen static content presented as a SPA, which is just nuts to me. [1] "It's much better ux when a user downloads the whole catalogue" from: https://news.ycombinator.com/item?id=44688834 https://news.ycombinator.com/item?id=44688834
- geraldwhen 1y ago
  Can’t hire for anything else. Competence in development no longer exists. And AI is making this march to idiocy worse.
- dsego 1y ago
  And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.
  - usrusr 1y ago
    This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial. If you have a huge org working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.
mattbrewsbytes 1y ago
If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache. HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.
- wldcordeiro 1y ago
  Lots of SPAs now are code-split too for what it's worth so you shouldn't really have large bundles to download if you're splitting things well.
- paulryanrogers 1y ago
  Is this true everywhere? Isn't much of the world still on slow mobile networks?
  - yawaramin 1y ago
    Being on a slow mobile network and having to reload changing bundles multiple times a day to use SPAs would be an even worse UX.
- youngtaff 1y ago
  > HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here) Large Js bundles are a huge problem though
jongjong 1y ago
SPAs are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions. There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing to build an SPA is not just some arbitrary whimsical decision that you can always avoid. Sometimes people just go straight to SPA because they're unsure about the level of complexity of the app they're building and they build an SPA just to be sure it can handle all the requirements which might come up later. One of my first jobs involved rebuilding a multi-page EdTech 'website' as an SPA, the multi-page site was extremely limiting, slow and not user-friendly for the complex use cases which had to be supported. There was a lot of overlay functionality which wouldn't make sense as separate pages. Also, complex state had to be maintained in the URL and the access controls were nuanced (more secure, easier enforce and monitor via remote API calls than serving up HTML which can mix and match data from a range of sources). I think a lot of the critiques of SPAs are actually about specific front end frameworks like React. A lot of developers do not like React for many of the reasons mentioned like 'resetting scrollbars' etc... React is literally a hack to try to bypass the DOM. It was built on the assumption that the DOM would always be unwieldy and impossible to extend, but that did not turn out to the the case. Nowadays, with custom web components, the DOM is actually pretty easy to work with directly but info about this seems to be suppressed due to React's popularity. Having worked with a wide range of front end frameworks including React for many years, the developer experience with Web Components is incomparably superior; it works exactly as you expect, there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to. You can have complex nested components; it's fast and you have full control over the rendering order... You can implement your own reactivity easily by watching attributes from inside a Web Component. The level of flexibility and reliability you get is incomparable to frameworks like React; also you don't need to download anything, you don't need to bundle any libraries (or if you do, you can choose how to bundle them and to what extent; you have fine-grained control over the pre-loading of scripts/modules), the code is idiomatic.
- Tokumei-no-hito 1y ago
  i remember seeing web components years ago, it sounds like they've improved a lot. what do you do about the lack of (i assume) ecosystem? due to the ready ubiquity there's practically a library for everything. do you find that using WC you are having to hand roll a lot? i don't mean to be a package slave but for complex and tedious things like graphs / charts.
wild_egg 1y ago
> in exchange for having really small network requests after the load. I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well. Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.
- raron 1y ago
  > I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://easyeda.com/ https://www.onshape.com https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?
  - deleted 1y ago
    [deleted]
  - niutech 1y ago
    No, HTTP compression is widely used (brotli increasingly).
  - chuckadams 1y ago
    BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off. It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).
cheema33 1y ago
> ...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct. Agreed. The article was a frustrating read. The author is an SEO consultant. SEO consultants likely have a heavy focus on marketing websites. Actual apps and not marketing websites do benefit significantly from SPA. Imagine building Google Maps without SPA. You can animate page transitions all you want, the experience will suck!
- Tokumei-no-hito 1y ago
  to be fair to both points: he has a really warped view that SPAs are somehow purely about routing. he does correctly point out that a lot of sites could and should be treated as sites not apps.
  - pyman 1y ago
    I agree with you. The author's point is that browsers have finally understood why some traditional sites were created as SPAs, which involves recreating some of the functionality browsers already offer today. But that doesn’t mean all SPAs should turn into MPAs now. IMO it will be hard for some traditional sites to adapt to the new browser capabilities, since we've built an entire ecosystem around SPAs. The author's advice should've been: use the browser's built-in capabilities instead of client-side libraries whenever possible. Also, keep in mind he's sharing his own experience, which might be different from ours. I've used some great SPAs and some terrible ones. The bad ones usually come down to inexperience from developers and hiring managers who don't understand performance, don't measure it, don't handle errors properly, and ignore edge cases. Some devs build traditional sites as SPAs and leave behind a horrible UX and tech debt the size of Mount Everest. If you don't know much about software architecture, you're more likely to make mistakes, no matter what language or framework you're using. I realised years ago there's no "better" language, framework, platform, or architecture, just different sets of problems. That's why developers spend so much time debating implementation details instead of focusing on the actual problems or ideas. And that's fine, debates can be useful as long as we don't lose sight of what we're trying to solve and why. For example: Amazon's developers went with an MPA. Airbnb started as an MPA but now uses a hybrid approach. Google Maps was built as an SPA, while the team behind Search went with an MPA.
thro1 1y ago
> But SPAs came about in the days of jQuery, not React. (viper.pl 2000, philips.pl 2001 .. - are.. 'unreal' ?? 'µloJSON': https://web.archive.org/web/20020702120539js_/http://www.viper.pl/shop/shop.js#:~:text=postload https://web.archive.org/web/20020702120539js_/http://www.vip... historised chained htmls restart onerror: https://web.archive.org/web/20020402025320js_/http://www.autointernet.pl/htm/load.js#:~:text=restart https://web.archive.org/web/20020402025320js_/http://www.aut... ) jQuery 2006, React 2013
youngtaff 1y ago
> SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Only for certain types of applications… the route change time for many SPA’s is way higher than for the equivalent MPA
KronisLV 1y ago
> SPAs make sense when your users have long sessions in your app. SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update). > When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.
zero_shift 1y ago
This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised? 3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?
- cleoxjefbjxis 1y ago
  You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.
  - zero_shift 1y ago
    Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom. Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective. One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy. These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises. It's a social dynamic as much as any technical one.
twelve40 1y ago
> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load ...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever. Click then to check the balance, just one number pulled in as tiny JSON, right? No, the website starts flashing another skeleton forever, why? You could say, no true SPA that is properly built would do that, but I run into this daily, many websites and apps made by companies with thousands of developers each.
- jazzypants 1y ago
  Yeah, I see a lot of poorly written back-end APIs too.
  - twelve40 1y ago
    backend has many traps but no one totally dominating "load the slow bundle once, near-native subsequent page loads" narrative which is (for whatever the reason!!) a non-existent illusion on most average daily websites.
layer8 1y ago
> It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. Why would the browser have to reload the code (JS files) on every page transition, with proper caching headers?
- jazzypants 1y ago
  Click on a link on Amazon and take notice of all the kb of data in the head of every document that doesn't get cached.
  - layer8 1y ago
    But you were talking about code, not data, hence my question. Also, Amazon doesn’t need to be that way (and wasn’t twenty years ago, the motivating period we are talking about).
camillomiller 1y ago
Not sure what kind of clients you work with, but in my experience this is actually accurate and you won’t believe how many times I had to put my hands and fix SPAs that should have been a static website to begin with. I think this is a consequence of a generation of webdevs, especially front-end, that graduated from bootcamps teaching them only JS frameworks and React as if that’s the only way the Web works. They were given a hammer, told how to use it, and everything then just looks like a nail.
tomhallett 1y ago
Depends on the definition of SPA, but in the days of jquery, I hardly consider any of that single page app. For example, the server rendered page had most of the html initial rendered, jquery would attach a bunch of listeners, and then on an update it incrementally. If lucky, we had a duplicated x-template-mustache tag which had a logic-less template that we could use to update parts. Jquery and duplication was the “problem” which drove everyone to SPAs.
matwood 1y ago
A SPA also makes it much easier to package your site into an app that you can put on the stores.

buffalobuffalo 1y ago

I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js

deleted 1y ago
[deleted]
kassner 1y ago
ExtJS/Sencha was quite powerful and complete. I’ve built tons of SPAs with it in the late 00s.
- gjtorikian 1y ago
  Wow, I remember Sencha! It’s been a while since I’d heard that name.
dsego 1y ago
I mostly remember doing $(document).ready blocks in php templates :)
PaulHoule 1y ago
I wrote my first SPA, a knowledge graph editor, using GWT (Google Web Toolkit) which compiled a dialect of Java to JavaScript circa 2006 or so.

TimTheTinker 1y ago

Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.

andix 1y ago
Latency might even be more relevant than bandwidth. Especially if it's a good SPA, that uses optimistic updates (or sync), and some kind of caching for fetching data (tanstack query or similar).
cosmic_cheese 1y ago
It really depends. There’s a lot of SPAs which are practically unusable on a bad connection simply because it’s a challenge to even get the whole thing loaded in the first place. There’s been several occasions where I’ve had poor cell connectivity and a huge chunk of the web was effectively off limits due to this. So in addition to aggressive caching, I’d say keeping the app’s file size down is also pretty important to making it useful on poor connections. That’s frequently something that’s barely optimized at all, unfortunately.
- tomnipotent 1y ago
  All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.
- jaredklewis 1y ago
  I work on an SPA with hundreds of screens. We package it using off the shelf tooling with barely any configuration. All of the code and styling is still far under a megabyte gzipped. So unless it is an all text app, the size of the code bundle is probably going to be quickly dwarfed by the size of media like images, animated images, or videos. If a site has an SPA with a, say, 3mb code bundle, I think in most cases, that’s not an architecture issue. It’s probably an issue of poor engineering and switching to a MPA is not suddenly going to make those engineers competent.

chaps 1y ago

Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)

chrisweekly 1y ago
Java applets are entirely distinct from SPAs, at least as that term is used in the webdev community.
- chaps 1y ago
  Hm, alrighty then. Seems like an unnecessary distinction to me in that it deeply constrains what SPAs can be, but I'm not a webdev.
  - Dylan16807 1y ago
    The rule is either "uses html to render" or an even looser "renders in the browser". That doesn't seem like a deep constraint to me. You exclude a couple very popular but historical plugins where the browser set up a rectangle and handed it off to an external piece of code, and pretty much nothing else.
threatofrain 1y ago
Those apps came from an era when these terms weren't even coined yet.
pstuart 1y ago
I think of java applets as being more akin to wasm; SPAs were/are a collection of html that recreate the experience of a "plain old" html web site.
brailsafe 1y ago
Java applets and ASP.Net did have a superficial answer to this, as well as Flash, but they varied in terms of their ability to actually function as raw web interfaces using the URL to navigate between sections. Being able to reliably and programmatically interact with client-side storage and the url, as well as improvements in DOM apis and commodification of hardware with more ram and faster faster CPUs, among many others factors, seem to have contributed.

Cthulhu_ 1y ago

> and load up a giant pile of jQuery spaghetti I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification. Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; biggest ones was its modularization (which wasn't a thing in JS yet), dependency injection, and testability. When we started out with an app in Backbone (to replace a Flex app because it wouldn't work on the ipad), I actually advocated against things like testing, thinking that the majority of functionality would be in the back-end. I was wrong, and the later AngularJS rebuild was a lot more intensive in front-end testing. Of course, nowadays I'm repulsed by the verbosity, complexity and indirection of modern-day Angular code. or Java code for that matter.

aryonoco 1y ago
Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns. Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt new Angular patterns. Still, I believe Angular is a really great platform for building B2B or enterprise apps. It’s testing and forms handling is far ahead of every other SPA, and it actually fees like a cohesive framework where people have spent time designing things the right way; something I absolutely cannot say about react frameworks such as Next.js or Remix.
- youngtaff 1y ago
  Angular was created so Java developers could create browser apps
  - leptons 1y ago
    Angular 1.x seems vastly different than Java. I doubt a Java developer would want to use it, so I'm not sure your claim is valid.

QuadrupleA 1y ago

Side note, sick of jQuery being always associated with spaghetti in the tech lexicon. Any Turing-complete system is spaghetti in the hands of bad programmers. And simple & clear in the hands of good ones who know how to design.

sverhagen 1y ago
Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. Not much to do about it anymore once the concrete has set. You can't still be an exception to rules, good for you! But that doesn't change the culture...?
- albedoa 1y ago
  > If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. My bet is that everyone here both agrees with you and is able to replace "jQuery" with "HTML", "CSS", and "JavaScript" to reach similar conclusions about the cultures of each. The problem is bad programmers, not the tech.
bobthepanda 1y ago
Jquery is good for dom manipulation, though most of the best ideas have become vanilla javascript standards. It isn’t really equipped or opinionated on statefulness, which means that everybody was at one point kludging stuff onto it that didn’t make sense.
PaulHoule 1y ago
It drives me crazy when it used together with React —- I want to have one authoritative copy of the state of my app, and jQuery bypasses that, at least if I’m using controlled forms. Now I used to hate uncontrolled forms but now I like react-hook-form.

jiggawatts 1y ago

The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else. Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”. My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice. Theoretically, sure, but every app I come across just dumps half the database down the wire and picks out a few dozen bytes in JS code. There's a comment right here in this discussion advocating for this! [1] Another angle is this: if you had a top 100 site with massive bandwidth costs, then sure, converting your app to a SPA might make financial sense. But instead what I see is tiny projects start as a SPA from day one, and no chance that their bandwidth considerations — either cost or performance — will ever be a factor. Think internal apps accessed only over gigabit Ethernet. I’ve seen static content presented as a SPA, which is just nuts to me. [1] "It's much better ux when a user downloads the whole catalogue" from: https://news.ycombinator.com/item?id=44688834 https://news.ycombinator.com/item?id=44688834

geraldwhen 1y ago
Can’t hire for anything else. Competence in development no longer exists. And AI is making this march to idiocy worse.
dsego 1y ago
And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.
- usrusr 1y ago
  This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial. If you have a huge org working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.

mattbrewsbytes 1y ago

If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache. HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.

wldcordeiro 1y ago
Lots of SPAs now are code-split too for what it's worth so you shouldn't really have large bundles to download if you're splitting things well.
paulryanrogers 1y ago
Is this true everywhere? Isn't much of the world still on slow mobile networks?
- yawaramin 1y ago
  Being on a slow mobile network and having to reload changing bundles multiple times a day to use SPAs would be an even worse UX.
youngtaff 1y ago
> HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here) Large Js bundles are a huge problem though

jongjong 1y ago

SPAs are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions. There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing to build an SPA is not just some arbitrary whimsical decision that you can always avoid. Sometimes people just go straight to SPA because they're unsure about the level of complexity of the app they're building and they build an SPA just to be sure it can handle all the requirements which might come up later. One of my first jobs involved rebuilding a multi-page EdTech 'website' as an SPA, the multi-page site was extremely limiting, slow and not user-friendly for the complex use cases which had to be supported. There was a lot of overlay functionality which wouldn't make sense as separate pages. Also, complex state had to be maintained in the URL and the access controls were nuanced (more secure, easier enforce and monitor via remote API calls than serving up HTML which can mix and match data from a range of sources). I think a lot of the critiques of SPAs are actually about specific front end frameworks like React. A lot of developers do not like React for many of the reasons mentioned like 'resetting scrollbars' etc... React is literally a hack to try to bypass the DOM. It was built on the assumption that the DOM would always be unwieldy and impossible to extend, but that did not turn out to the the case. Nowadays, with custom web components, the DOM is actually pretty easy to work with directly but info about this seems to be suppressed due to React's popularity. Having worked with a wide range of front end frameworks including React for many years, the developer experience with Web Components is incomparably superior; it works exactly as you expect, there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to. You can have complex nested components; it's fast and you have full control over the rendering order... You can implement your own reactivity easily by watching attributes from inside a Web Component. The level of flexibility and reliability you get is incomparable to frameworks like React; also you don't need to download anything, you don't need to bundle any libraries (or if you do, you can choose how to bundle them and to what extent; you have fine-grained control over the pre-loading of scripts/modules), the code is idiomatic.

Tokumei-no-hito 1y ago
i remember seeing web components years ago, it sounds like they've improved a lot. what do you do about the lack of (i assume) ecosystem? due to the ready ubiquity there's practically a library for everything. do you find that using WC you are having to hand roll a lot? i don't mean to be a package slave but for complex and tedious things like graphs / charts.

wild_egg 1y ago

> in exchange for having really small network requests after the load. I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well. Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.

raron 1y ago
> I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://easyeda.com/ https://www.onshape.com https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly disabled after CRIME and BREACH attack?
- deleted 1y ago
  [deleted]
- niutech 1y ago
  No, HTTP compression is widely used (brotli increasingly).
- chuckadams 1y ago
  BREACH would be the relevant attack for content-encoding compression, it's only good for guessing the content of the response that can't actually be read otherwise, i.e. stealing a csrf token in cross-site requests, requires that the server echo back a chosen plaintext in the response (e.g. a provided query string), and takes thousands of requests to pull it off. It's a vanishingly small number of things that are actually vulnerable to this attack, and I've never even heard of a successful real-world exploit (tho it's not like the attackers that might use this go and tell everyone).

cheema33 1y ago

> ...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct. Agreed. The article was a frustrating read. The author is an SEO consultant. SEO consultants likely have a heavy focus on marketing websites. Actual apps and not marketing websites do benefit significantly from SPA. Imagine building Google Maps without SPA. You can animate page transitions all you want, the experience will suck!

Tokumei-no-hito 1y ago
to be fair to both points: he has a really warped view that SPAs are somehow purely about routing. he does correctly point out that a lot of sites could and should be treated as sites not apps.
- pyman 1y ago
  I agree with you. The author's point is that browsers have finally understood why some traditional sites were created as SPAs, which involves recreating some of the functionality browsers already offer today. But that doesn’t mean all SPAs should turn into MPAs now. IMO it will be hard for some traditional sites to adapt to the new browser capabilities, since we've built an entire ecosystem around SPAs. The author's advice should've been: use the browser's built-in capabilities instead of client-side libraries whenever possible. Also, keep in mind he's sharing his own experience, which might be different from ours. I've used some great SPAs and some terrible ones. The bad ones usually come down to inexperience from developers and hiring managers who don't understand performance, don't measure it, don't handle errors properly, and ignore edge cases. Some devs build traditional sites as SPAs and leave behind a horrible UX and tech debt the size of Mount Everest. If you don't know much about software architecture, you're more likely to make mistakes, no matter what language or framework you're using. I realised years ago there's no "better" language, framework, platform, or architecture, just different sets of problems. That's why developers spend so much time debating implementation details instead of focusing on the actual problems or ideas. And that's fine, debates can be useful as long as we don't lose sight of what we're trying to solve and why. For example: Amazon's developers went with an MPA. Airbnb started as an MPA but now uses a hybrid approach. Google Maps was built as an SPA, while the team behind Search went with an MPA.

thro1 1y ago

> But SPAs came about in the days of jQuery, not React. (viper.pl 2000, philips.pl 2001 .. - are.. 'unreal' ?? 'µloJSON': https://web.archive.org/web/20020702120539js_/http://www.viper.pl/shop/shop.js#:~:text=postload https://web.archive.org/web/20020702120539js_/http://www.vip... historised chained htmls restart onerror: https://web.archive.org/web/20020402025320js_/http://www.autointernet.pl/htm/load.js#:~:text=restart https://web.archive.org/web/20020402025320js_/http://www.aut... ) jQuery 2006, React 2013

youngtaff 1y ago

> SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Only for certain types of applications… the route change time for many SPA’s is way higher than for the equivalent MPA

KronisLV 1y ago

> SPAs make sense when your users have long sessions in your app. SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update). > When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.

zero_shift 1y ago

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised? 3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?

cleoxjefbjxis 1y ago
You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.
- zero_shift 1y ago
  Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom. Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective. One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy. These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises. It's a social dynamic as much as any technical one.

twelve40 1y ago

> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load ...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever. Click then to check the balance, just one number pulled in as tiny JSON, right? No, the website starts flashing another skeleton forever, why? You could say, no true SPA that is properly built would do that, but I run into this daily, many websites and apps made by companies with thousands of developers each.

jazzypants 1y ago
Yeah, I see a lot of poorly written back-end APIs too.
- twelve40 1y ago
  backend has many traps but no one totally dominating "load the slow bundle once, near-native subsequent page loads" narrative which is (for whatever the reason!!) a non-existent illusion on most average daily websites.

layer8 1y ago

> It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. Why would the browser have to reload the code (JS files) on every page transition, with proper caching headers?

jazzypants 1y ago
Click on a link on Amazon and take notice of all the kb of data in the head of every document that doesn't get cached.
- layer8 1y ago
  But you were talking about code, not data, hence my question. Also, Amazon doesn’t need to be that way (and wasn’t twenty years ago, the motivating period we are talking about).

camillomiller 1y ago

Not sure what kind of clients you work with, but in my experience this is actually accurate and you won’t believe how many times I had to put my hands and fix SPAs that should have been a static website to begin with. I think this is a consequence of a generation of webdevs, especially front-end, that graduated from bootcamps teaching them only JS frameworks and React as if that’s the only way the Web works. They were given a hammer, told how to use it, and everything then just looks like a nail.

tomhallett 1y ago

Depends on the definition of SPA, but in the days of jquery, I hardly consider any of that single page app. For example, the server rendered page had most of the html initial rendered, jquery would attach a bunch of listeners, and then on an update it incrementally. If lucky, we had a duplicated x-template-mustache tag which had a logic-less template that we could use to update parts. Jquery and duplication was the “problem” which drove everyone to SPAs.

matwood 1y ago

A SPA also makes it much easier to package your site into an app that you can put on the stores.