14 ms·

The Single-Page-App Morality Play

207 points by midrus 5y ago

DeathArrow 5y ago
What's worse, those frontend devs who love Javascript frameworks began writing desktop and mobile apps in Javascript.
hunterb123 5y ago
Yeah pretty much. Depends if you are making a web app or a web site.
antihero 5y ago
Is this just an advert for Hotwire? Every single point just seems to mention Hotwire.
- moon_other 5y ago
  Not really. Hotwire is provided as an example of a Hybrid app framework / toolkit and is mentioned about five times. But so also is Svelte.
- rk06 5y ago
  Doesn't like it considering below snippet from the post > (* I say ‘was’ because the instability of Basecamp’s management and the massive turnover of the team working on Stimulus and Turbo makes me wary of using Hotwire on a project. But given how popular Rails is, that’s probably me being overcautious. The principles they describe in their books, such as Shape Up, are still sound. The problem, as many have pointed out, was that they didn’t follow through in practice on what they wrote.)
  - rk06 5y ago
    EDIT: doesn't look like it Can't update original comment
crate_barre 5y ago
What did I just read? GPT spotting here guys?
bulatb 5y ago
For anyone deciding whether to read, I'd say the article is broadly centered on this: > As developers, we need to operate under the assumption that good management is the exception, not the norm. Multi-Page-Apps and hybrid frameworks let under-resourced, mismanaged developer teams deliver reliable and safe code. That should not be dismissed lightly. There's also a helpful "Summary" section at the bottom. Overall it frames the SPA vs. TWA[0] debate in terms of which approach is likelier to produce successful software... or successfully produce software, at least. [0] Traditional Web Application? Do we call it that?
- SilasX 5y ago
  <deleting because comment was based on a misreading>
  - mwcampbell 5y ago
    Can you elaborate on what you found laughable? I thought the article made valid points.
    - SilasX 5y ago
      <deleting because comment was based on a misreading>
      - afavour 5y ago
        Is the article not arguing the opposite? That multi page apps are the ones that better insulate against management failure?
        SilasX 5y ago
        <deleting because comment was based on a misreading>
        afavour 5y ago
flerchin 5y ago
The bits about SPAs seemed to have no relation to the thesis, which is that management drives the antipatterns, not the tech.
- bulatb 5y ago
  The author argues that the non-SPA approach deals better with that kind of management than SPA does.
gorgoiler 5y ago
Nice to read something that made me laugh out loud. Pro tech work really is 80% coordinating people (quashing jerks, dealing with drama, etc: “don’t leave the new guy alone with the CTO”) and 20% funtimes-computer-stuff. It might not seem like that in terms of wallclock time, but it sure feels like it in terms of energy spent.
- not2b 5y ago
  Since he refers to misogyny elsewhere, I suspect he might mean "the new gal".
jrochkind1 5y ago
This article is blowing my mind, as is the linked article "Agile as Trauma"[1], written by apparently a different author but with a very similar broad perspective. I want to read more like this. [1] https://doriantaylor.com/agile-as-trauma https://doriantaylor.com/agile-as-trauma [update: holy cow, this one too https://www.baldurbjarnason.com/2021/software-crisis-2/ https://www.baldurbjarnason.com/2021/software-crisis-2/ Today is turning into "read about existential problems with how software is developed" day for me]
pjc50 5y ago
I really like the virtue/vice discussion framing this. You don't see virtue-oriented discussion of topics very often unless it's the accusation of "virtue signalling" being flung around. > I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time. Very true - and also of mobile apps that behave in this way, either because they're using the same SPA technology or are just misconceived. However: > The Multi-Page-App forces the team to narrow the scope to a level they can handle. It puts a hard limit on their technological aspirations. I don't see how this follows at all? The link to https://doriantaylor.com/agile-as-trauma https://doriantaylor.com/agile-as-trauma is fantastic too, as is the whole "I am Vanity" section. But yes, I also agree with the people here asking what this has to do with SPA vs MPA, because I don't understand the scope argument. (Frankly I could write a paragraph response to each section as if it were a separate blog post, that's how much good content there is here)
- bulatb 5y ago
  I think he's implying that traditional MPAs are relatively well-understood. The team will pretty much know how to make them and will not expect to break new ground on architecture, discover new things the model enables, or spend a lot of time on "How do we build applications?" versus just delivering on business goals. SPA development is less mature, so there's a lot more room (and sometimes need, or just temptation) to reinvent things.
  - throwaway284534 5y ago
    Maybe I’m just full of Ruby on Rails induced trauma, but I can’t remember any particular pleasant memories. Every app would start with a reasonable and straightforward view layer, usually ERB templates sprinkled with jQuery, and then slowly but surely be consumed by one-off JavaScript snippets. “We need a sortable table on this route and it should support pagination without a reload, but the pagination needs to be persisted to the address bar for outside link sharing.” This feature alone can introduce all kinds of unmanaged state and be a testing nightmare. And if another part of the site uses the same functionality, you’ve just signed up for an lifetime of maintenance, usually somewhere between your server-side templates, and your asset pipeline. God help you if your bugs can be described as, “I have some local state here, but I’m not sure how to get it either up or down to the right place.” Personally, these kind of code smells demoralize me enough to consider a job elsewhere, preferably at a company that uses something like React where there’s bound to be complexity, but at least there’s component boundaries to keep your mental facilities from being overrun by a “simple multi page architecture.”
cardanome 5y ago
As someone that had my fair share of experience with mismanaged teams, this rings very true. For example I had to maintain a legacy PHP project, relatively old school PHP before there was even OO, plain HTML with just a bit of JS sprinkled it. Everyone complained about it and sure the code was horrible but I could dive in and be productive on day one. Same company, more recent project with a more modern stack, trying to follow all the OO patterns and everything. I was not even able to fix minor bugs in any reasonable time even studying the code for weeks. What happened? While the developers made good technical choices and the quality of the code in isolation was fine, it was horrible mismanaged. There was no continuity, just people working on it for a couple of days then doing something totally different and forgetting everything again on repeat. Individual design decisions were "industry best practice" but the end result was something I wished I could just delete. Everyone loves to play wiht the newest toys but you got to keep you developer vanity in check. Sometimes the boring CRUD app should use boring technology. With horrible management you will learn to hate what you once loved anyway.
- draw_down 5y ago
  Article: bad management is the number one problem. Your post: yeah someone needs to rein in these stupid developers!
- userbinator 5y ago
  For some reason, web development seems to have an obsession with "progress" and the new-and-shiny-but-objectively-worse. I've noticed that constant reinvention of the wheel and doing the same thing more inefficiently ("but it's more modern!") is a common theme.
  - grey-area 5y ago
    When people say a web app is 'modern' I know it involves a javascript framework. I'm not sure how or why this came about, but it seems to be a code-word meaning one of the newer javascript frameworks, that single word is almost a shibboleth at this point for an entire culture of development.
afavour 5y ago
This article rings very true to me. In my mind a badly managed project (and yes, these are legion) will accumulate complexity very quickly. The important technical difference between MPAs and SPAs is where they put that complexity. In a multi-page app the complexity largely lives on the server, which is a known quantity, profile-able and scaleable. In a single-page app the complexity lives on the user's device. There are innumerable variations in device power, capability and so on so there is no good sense of what "good performance" even is. But it'll work great on the developers supercharged MacBook Pros, so the code gets shipped.
- chrismorgan 5y ago
  > The important technical difference between MPAs and SPAs is where they put that complexity. Just as important a practical difference (an outworking of the complexity location) is the matter of statefulness. With an MPA, each page load is its own thing, generated from scratch from the canonical data source each time. Pages are essentially stateless. With an SPA, the client will generally be interested in retaining data and caching things for at least the duration of the session, and it’s easy for state to get out of sync. That can go wrong so many ways, and cause so much pain, and resolving that commonly takes reloading the whole page, which is normally distinctly slower than it would have been in the MPA world. (Not that it need be noticeably slower, but it almost always will be.) Or the absolute worst case, persisted wrong data… that’s a nightmare.
louissm_it 5y ago
I've always found that when people say they dislike SPAs they actually mean they dislike APIs and the whole circus of how to handle building, consuming, validating, error handling, network errors, etc. Not affiliated, but Inertiajs[1] has been a fantastic middle ground between MVC goodness and using React/Vue/Svelte for client side interactivity. It even plugins in with your Rails/Laravel errors for form handling. [1] - https://inertiajs.com https://inertiajs.com
endisneigh 5y ago
It’s hard to draw any real conclusions from this. The author says things that the delta between an average single page app is great from multi page, but is that true? The author makes tons of claims but presents no evidence. Seems more about poorly designed apps and managed teams than anything inherent in either type of app.
jgwil2 5y ago
> Single-Page-Apps can be amazing. > You can make a great Single-Page-App with a User Experience that a traditional site will never be able to close to matching. What is actually meant by this? What is an example of a feature that can be far better in a SPA than in an MPA?
- afavour 5y ago
  You can persist data on the client with IndexedDB and make a SPA with zero load times no matter what page you’re loading. That would never be possible with a MPA. It’s also almost never something that actually happens with SPAs but it certainly is possible.
  - mwcampbell 5y ago
    The best example I know of a purely client-side web app that makes effective use of local storage is the Pinafore [1] client for Mastodon. Edit: And it's worth noting that this app is a labor of love by an expert web developer, i.e. the antithesis of a typical corporate project. [1]: https://pinafore.social/ https://pinafore.social/
- resignThis2021 5y ago
  Spreadsheet apps in the browser?
- rcakebread 5y ago
  Playing audio or video without interruption while navigating the site.
  - jgwil2 5y ago
    Somewhat niche but a good use case, thanks.
  - bestinterest 5y ago
    Eh unfortunately its muddy there too, see changelog.com which is not an SPA and instead uses Turbolinks (now Turbo) to persist the podcast element at the bottom of the screen.
jonathan-adly 5y ago
I have been developing lately with A django/HTMX stack[0]. It covers a lot of the positives of JS SPA, without the headache. Also, I get to use the Django superpowers. https://htmx-django.com https://htmx-django.com
- mwcampbell 5y ago
  I appreciate that Django is a good old full-stack server-side framework, and there's a lot to like about that. But I can't bring myself to start a new project with something that has the gross inefficiency of CPython (or, IIUC, stock Ruby), as discussed at, for example, [1] and [2]. I want a runtime environment that's efficient enough that I can deploy the web application on a couple of small VMs, still have plenty of headroom for load spikes (which, in my experience, are usually due to screwups on my part and not actual demand spikes), and delay thinking about scaling as long as possible. [1]: https://rachelbythebay.com/w/2020/03/07/costly/ https://rachelbythebay.com/w/2020/03/07/costly/ [2]: https://blog.clubhouse.com/reining-in-the-thundering-herd-with-django-and-gunicorn/ https://blog.clubhouse.com/reining-in-the-thundering-herd-wi...
- harryvederci 5y ago
  Surprised htmx isn't mentioned more in the comments. I'm using it with Janet for a side project, really liking it so far. Writing server-side html with a hiccup-like library is very nice! :) (Clojure Hiccup library, similar libraries exist for other lisp-like languages: https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup)
est 5y ago
if SPAs are bad, compiled JS are evil. They only seem to hijack the scrollbar or give cookie consent or waste 2/3 of viewport with a fucking subscribe/login cover. Every page should promise some kind of plain text content length vs full page resource bytes ratio. Why would anyone emit 20MB of .min.js only to deliver 140 characters of tweet?
- kbsspl 5y ago
  thank you for saying that.
- Raidion 5y ago
  I get the feeling, but it's worth noting that it's not just 140 characters of tweet. It's also delivering all the analytics, the content surrounding the tweet (replies, likes, etc), and is a teaser to the rest of the app. The business driver isn't just delivering the content, it's increasing engagement, and the SPA application provides a significantly better and scalable way to make that happen. Everyone seems to think they could do better, and we end up with yet another "modern" JS framework.
DerekBickerton 5y ago
For the bulk of my Internet surfing, I have JS turned off by default in uBlock. Now and then I encounter a white screen of death which on closer inspection is a Single Page App (and didn't have the courtesy of having a <noscript> tag telling me I needed JS to view the page). I have JS turned off for accessibility and privacy reasons. What annoys me is sometimes JS is needed just to render a bit of text when it could be rendered with plain HTML. Not everything needs to have JS in order to work/function. Also: many hamburger menus are rendered useless when JS is turned off when it could be implemented with CSS alone.
lsalvatore 5y ago
I can't relate to this at all. I've been happily working on SPAs with React and Redux for nearly 6 years. Hotwire makes no sense: switching to managing client-side state on the server and sending HTML over the wire introduces a ton of problems: you are going to have to write and debug JavaScript eventually. Now your server is running client-side code to update every local browser state? How is that scalable at all? React has a ton of great libraries for UI that these articles always ignore: Something like react-select to manage a dynamic dropdown- you can't implement that on the server. You need SPAs for complex dashboards, and React is a great library to store and update local state. I don't understand what the controversy is.
- sanderjd 5y ago
  I've always thought some of it stems from the nomenclature and the cultures that flow from it. A lot of people (reasonably) don't think the best architecture for their application is a "single page". But many of those same people nonetheless have (often large) portions of their application that benefit from complex client side interactivity. But the whole thing can seem really all or nothing, either you have a "single page application" that does everything client side or you do everything through html from the server. Of course in practice everybody does some hybrid in between these two extremes. But the apparent split creates a cultural battle between the extremes, which is not helpful.
  - lsalvatore 5y ago
    I come from a financial reporting background where pages needed to be dynamic and update through filters / sorting / etc- think Excel or Robinhood- these are applications, not pages. When you are building an application, users don't want to experience a page refresh. You either want a dynamic behavior without page refresh, or not. React Router gives you client-side routing- I don't know why you wouldn't want that even if you were building something like AirBnB where there is mostly static content- to argue against dynamic search and filtering without page refresh seems silly to me.
    - sanderjd 5y ago
kbsspl 5y ago
Great style of writing. A great example of a 'forced perspective'. The entire ecosystem of browsers, standards, devices, business imperatives is being forcefully turned into a spa/mpa comparison.
sanderjd 5y ago
Maybe an unpopular opinion here: as a user of web applications, I very strongly prefer the "modern" javascript heavy SPA dominated culture of recent years. Every once in awhile I get annoyed by something that is just a webpage but thinks it's an application, but more often I have the reverse annoyance. But as a developer, I agree that it is harder to develop these kinds of applications that I like than it used to be to develop multi page applications with mostly server side logic and only sprinkles of javascript. I guess I just do, actually, think there is UX benefit to the complexity. But of course there are better and worse ways to accomplish it, figuring out that balance is the hard part.
- mwcampbell 5y ago
  Can you expand on why you prefer the JS-heavy SPA style?
  - sanderjd 5y ago
    Because they are faster and easier to use. Using them is like using an application, rather than like using a website. I think a good rule of thumb is: am I mostly clicking or mostly scrolling? If I'm mostly clicking - say, something like AirBnB or Zillow or Discord - where I'm exploring things and interacting a bunch, that feels better to me as a rich client-side application. If I'm mostly scrolling, like a blog or substack or a newspaper or even twitter, that feels better as a website. I thought of a good concrete comparison: Vanguard vs. Coinbase Pro. Vanguard is a website, and it basically works for them because their business model is very passive, but you wouldn't want to do active trading there. Coinbase Pro is a web application where you can do lots of exploration and take actions quickly, and for me, it would be a major hindrance if they implemented it in a traditional page-based way.
    - DeathArrow 5y ago
      If you want to use an application, then why don't you download and run an application? You will have a better experience running an application on desktop instead of running it on the browser.
denton-scratch 5y ago
SPAs make web resources impossible to index or link to - by definition, they do not contain "pages". OP failed to mention this at all. For me, this is the killer "anti" posture. Hyperlinks are the defining feature of the WWW; that people put resources on the WWW that can't be linked to, is cause for regret.
- ngrilly 5y ago
  It used to be impossible to link to specific page in a SPA without using hashes in the URL, but this problem has been solved years ago, and all modern browsers support it.
  - denton-scratch 5y ago
    What's a "specific page" in the context of discussing single-page applications?
    - hbn 5y ago
      If you go to example.com/user/jim in your browser, it'll navigate to (presumably) the profile for the user with the handle "jim" Maybe I don't understand what you're asking. Browsers these days have functionality that enables SPAs to navigate between URLs, push/pop to and from the back history, etc. without full page reloads.
      - denton-scratch 5y ago
        Well, example.com/user/jim looks to me like a Unique Resource Locator. If that's right, then what I'll get is a "page" (you could call it a resource). If the locator is really "unique", It'll be different from the page I get if I ask for example.com/user/jane, right? (modulo aliasing) Well if that's right, then this site is not a "single-page application". It has multiple pages with different URLs, and I don't know how that's different from any other website with server-side state. [Edited to mention state; state is irrelevant to whether its an MPA or an SPA, but without state it's hard to argue its an application at all]
shadowgovt 5y ago
This rings extremely true based on my observation. Fundamentally, companies working on large projects will ship their org chart. It is modestly more difficult, if your org chart gets spilt in two such that two or more teams are now maintaining the same SPA, to synchronize their work such that they don't interfere with each other's activities. You begin looking at a more traditional application development model with full program integration testing in the mix. Multiple pages means multiple entirely separate client-side contexts that are a security hole if they can clobber each other.
hahamrfunnyguy 5y ago
I've been doing web development for over twenty years now. Perl, PHP, ASP, Rails, .NET, Flash, Flex, Silverlight and various JavaScript and SPA frameworks. I really like the MPA approach. To me it means building a bunch of mini SPAs. You can still stuff everything into a single SPA to deploy to a mobile app, but it gives you the advantage quicker first-time page loads and a lot of extra flexibility. Compared to the Web 1.0 way of doing things where you POST and then reload the page, you're taking an API based approach so when a 3rd party needs to integrate with you - that part is probably done already. A lot of sites use the MPA approach wrong though. They load the "apps", then proceed to make a whole bunch of asynch requests for data. In most cases, using a mechanism to inject in data when a page first loads makes everything feel a lot faster. It's the best of both worlds: you get the speed of the old school web and the flexibility of modern practices.
- martin_drapeau 5y ago
  I couldn't agree more. It is a spectrum. <-- Fully MPA ... MPA with mini SPAs ... Fully SPA. --> Many don't venture in the middle. Not sure why. Do not stay on either end. It will bite you!
  - zerkten 5y ago
    People don't venture in the middle because it's complicated and scary for many people due to the skill requirements. It only starts to feel safe to play there when you have experience with development at both ends of the spectrum because you likely won't have the support of tools which are intended to run there. Further, it's a compromise that is difficult to explain and justify to management. If they are risk averse then they won't want to move far from the safety of the frameworks at either end of the spectrum. If you are a developer of frameworks, it also seems advantageous to go to one end of the spectrum because it's easier to reason about the problem space. When you target the middle there starts to be more variations in how to handle it best. It's really the only place to go though, if folks really want to innovate and provide better experiences for all.
    - 5y ago
DeathArrow 5y ago
It's the Web what Tim Berners Lee envisioned it to be, a web of "dumb" hypertext used to disseminate information or a web of interlinked apps which happen to run in the browser instead of desktop or mobile? In the 2000 it was clear: if you wanted to find informations, you went on the www. If you wanted to chat, you used an IRC app. If you wanted to type a document, you opened a text processor. If you wanted to see a movie, you used a movie player. If you wanted to listen to music, you opened a music player. If you wanted to game, you fired a game. Now all this are on the web. It's not clear to me if I am a web developer or an app developer because the borders are erased day by day.
DeathArrow 5y ago
For me SPAs are when we want to run apps in the browser less efficiently than on the desktop or mobile, while taking more time to develop them.
oblib 5y ago
Well this made me feel good about being a lone developer who gets to make all the decisions on how to make an app.
etchalon 5y ago
Is this a React thing? I haven't run into any of these problems in five years of building Vue.js SPAs. Literally everything is easier, and faster, than traditional MPA development.
toddmorey 5y ago
Those interested in this debate really need to watch a very fantastic presentation on this exact topic: "Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes" [1] [1] https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77lF-XaNacKxWk7yOKgeCMveAS&index=2 https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77l...
nyanpasu64 5y ago
> the root cause of every bad Single-Page-App isn’t that it’s a Single-Page-App. The root cause of https://vector-of-bool.github.io/ https://vector-of-bool.github.io/ scrolling incorrectly when navigating between pages isn't due to bad management or lack of care, it's because it's a single page app that didn't handle scrolling correctly (which a browser would provide for free), and the author didn't notice despite coming in with good intentions.
- snarkypixel 5y ago
  That's the point of the article though. SPA is /hard/. Using a normal many-page app, you get scrolling that works across all browser - even mobile - for free, without having to do anything. I'm not saying I necessarily agree, but that's what this article is about.
  - nyanpasu64 5y ago
    > Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations. I don't think the vector-of-bool website, and the broken JS transitions, were designed by a dysfunctional organization (or an organization for that matter) (though the author has suffered from burnout: https://vector-of-bool.github.io/2019/05/23/signals.html https://vector-of-bool.github.io/2019/05/23/signals.html).
- bestinterest 5y ago
  It gets even muddier when you consider the fact that MPA transitions will be in browsers hopefully quite soon and you will be able to achieve the exact same effect. https://developer.chrome.com/blog/shared-element-transitions-for-spas/ https://developer.chrome.com/blog/shared-element-transitions...
KarlKemp 5y ago
So... the idea is that there's a gray area in most debates, the answer usually isn't found at the extremes, the tech community needs to beware of groupthink, and, fundamentally, hold on to your hats, that ... ... management is just really stupid? Yeah, that's a really really rare opinion in tech circles.

207 points by midrus 5y ago

DeathArrow 5y ago

What's worse, those frontend devs who love Javascript frameworks began writing desktop and mobile apps in Javascript.

hunterb123 5y ago

Yeah pretty much. Depends if you are making a web app or a web site.

antihero 5y ago

Is this just an advert for Hotwire? Every single point just seems to mention Hotwire.

moon_other 5y ago
Not really. Hotwire is provided as an example of a Hybrid app framework / toolkit and is mentioned about five times. But so also is Svelte.
rk06 5y ago
Doesn't like it considering below snippet from the post > (* I say ‘was’ because the instability of Basecamp’s management and the massive turnover of the team working on Stimulus and Turbo makes me wary of using Hotwire on a project. But given how popular Rails is, that’s probably me being overcautious. The principles they describe in their books, such as Shape Up, are still sound. The problem, as many have pointed out, was that they didn’t follow through in practice on what they wrote.)
- rk06 5y ago
  EDIT: doesn't look like it Can't update original comment

crate_barre 5y ago

What did I just read? GPT spotting here guys?

bulatb 5y ago

For anyone deciding whether to read, I'd say the article is broadly centered on this: > As developers, we need to operate under the assumption that good management is the exception, not the norm. Multi-Page-Apps and hybrid frameworks let under-resourced, mismanaged developer teams deliver reliable and safe code. That should not be dismissed lightly. There's also a helpful "Summary" section at the bottom. Overall it frames the SPA vs. TWA[0] debate in terms of which approach is likelier to produce successful software... or successfully produce software, at least. [0] Traditional Web Application? Do we call it that?

SilasX 5y ago
<deleting because comment was based on a misreading>
- mwcampbell 5y ago
  Can you elaborate on what you found laughable? I thought the article made valid points.
  - SilasX 5y ago
    <deleting because comment was based on a misreading>
    - afavour 5y ago
      Is the article not arguing the opposite? That multi page apps are the ones that better insulate against management failure?
      - SilasX 5y ago
        <deleting because comment was based on a misreading>
        afavour 5y ago

flerchin 5y ago

The bits about SPAs seemed to have no relation to the thesis, which is that management drives the antipatterns, not the tech.

bulatb 5y ago
The author argues that the non-SPA approach deals better with that kind of management than SPA does.

gorgoiler 5y ago

Nice to read something that made me laugh out loud. Pro tech work really is 80% coordinating people (quashing jerks, dealing with drama, etc: “don’t leave the new guy alone with the CTO”) and 20% funtimes-computer-stuff. It might not seem like that in terms of wallclock time, but it sure feels like it in terms of energy spent.

not2b 5y ago
Since he refers to misogyny elsewhere, I suspect he might mean "the new gal".

jrochkind1 5y ago

This article is blowing my mind, as is the linked article "Agile as Trauma"[1], written by apparently a different author but with a very similar broad perspective. I want to read more like this. [1] https://doriantaylor.com/agile-as-trauma https://doriantaylor.com/agile-as-trauma [update: holy cow, this one too https://www.baldurbjarnason.com/2021/software-crisis-2/ https://www.baldurbjarnason.com/2021/software-crisis-2/ Today is turning into "read about existential problems with how software is developed" day for me]

pjc50 5y ago

I really like the virtue/vice discussion framing this. You don't see virtue-oriented discussion of topics very often unless it's the accusation of "virtue signalling" being flung around. > I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time. Very true - and also of mobile apps that behave in this way, either because they're using the same SPA technology or are just misconceived. However: > The Multi-Page-App forces the team to narrow the scope to a level they can handle. It puts a hard limit on their technological aspirations. I don't see how this follows at all? The link to https://doriantaylor.com/agile-as-trauma https://doriantaylor.com/agile-as-trauma is fantastic too, as is the whole "I am Vanity" section. But yes, I also agree with the people here asking what this has to do with SPA vs MPA, because I don't understand the scope argument. (Frankly I could write a paragraph response to each section as if it were a separate blog post, that's how much good content there is here)

bulatb 5y ago
I think he's implying that traditional MPAs are relatively well-understood. The team will pretty much know how to make them and will not expect to break new ground on architecture, discover new things the model enables, or spend a lot of time on "How do we build applications?" versus just delivering on business goals. SPA development is less mature, so there's a lot more room (and sometimes need, or just temptation) to reinvent things.
- throwaway284534 5y ago
  Maybe I’m just full of Ruby on Rails induced trauma, but I can’t remember any particular pleasant memories. Every app would start with a reasonable and straightforward view layer, usually ERB templates sprinkled with jQuery, and then slowly but surely be consumed by one-off JavaScript snippets. “We need a sortable table on this route and it should support pagination without a reload, but the pagination needs to be persisted to the address bar for outside link sharing.” This feature alone can introduce all kinds of unmanaged state and be a testing nightmare. And if another part of the site uses the same functionality, you’ve just signed up for an lifetime of maintenance, usually somewhere between your server-side templates, and your asset pipeline. God help you if your bugs can be described as, “I have some local state here, but I’m not sure how to get it either up or down to the right place.” Personally, these kind of code smells demoralize me enough to consider a job elsewhere, preferably at a company that uses something like React where there’s bound to be complexity, but at least there’s component boundaries to keep your mental facilities from being overrun by a “simple multi page architecture.”

cardanome 5y ago

As someone that had my fair share of experience with mismanaged teams, this rings very true. For example I had to maintain a legacy PHP project, relatively old school PHP before there was even OO, plain HTML with just a bit of JS sprinkled it. Everyone complained about it and sure the code was horrible but I could dive in and be productive on day one. Same company, more recent project with a more modern stack, trying to follow all the OO patterns and everything. I was not even able to fix minor bugs in any reasonable time even studying the code for weeks. What happened? While the developers made good technical choices and the quality of the code in isolation was fine, it was horrible mismanaged. There was no continuity, just people working on it for a couple of days then doing something totally different and forgetting everything again on repeat. Individual design decisions were "industry best practice" but the end result was something I wished I could just delete. Everyone loves to play wiht the newest toys but you got to keep you developer vanity in check. Sometimes the boring CRUD app should use boring technology. With horrible management you will learn to hate what you once loved anyway.

draw_down 5y ago
Article: bad management is the number one problem. Your post: yeah someone needs to rein in these stupid developers!
userbinator 5y ago
For some reason, web development seems to have an obsession with "progress" and the new-and-shiny-but-objectively-worse. I've noticed that constant reinvention of the wheel and doing the same thing more inefficiently ("but it's more modern!") is a common theme.
- grey-area 5y ago
  When people say a web app is 'modern' I know it involves a javascript framework. I'm not sure how or why this came about, but it seems to be a code-word meaning one of the newer javascript frameworks, that single word is almost a shibboleth at this point for an entire culture of development.

afavour 5y ago

This article rings very true to me. In my mind a badly managed project (and yes, these are legion) will accumulate complexity very quickly. The important technical difference between MPAs and SPAs is where they put that complexity. In a multi-page app the complexity largely lives on the server, which is a known quantity, profile-able and scaleable. In a single-page app the complexity lives on the user's device. There are innumerable variations in device power, capability and so on so there is no good sense of what "good performance" even is. But it'll work great on the developers supercharged MacBook Pros, so the code gets shipped.

chrismorgan 5y ago
> The important technical difference between MPAs and SPAs is where they put that complexity. Just as important a practical difference (an outworking of the complexity location) is the matter of statefulness. With an MPA, each page load is its own thing, generated from scratch from the canonical data source each time. Pages are essentially stateless. With an SPA, the client will generally be interested in retaining data and caching things for at least the duration of the session, and it’s easy for state to get out of sync. That can go wrong so many ways, and cause so much pain, and resolving that commonly takes reloading the whole page, which is normally distinctly slower than it would have been in the MPA world. (Not that it need be noticeably slower, but it almost always will be.) Or the absolute worst case, persisted wrong data… that’s a nightmare.

louissm_it 5y ago

I've always found that when people say they dislike SPAs they actually mean they dislike APIs and the whole circus of how to handle building, consuming, validating, error handling, network errors, etc. Not affiliated, but Inertiajs[1] has been a fantastic middle ground between MVC goodness and using React/Vue/Svelte for client side interactivity. It even plugins in with your Rails/Laravel errors for form handling. [1] - https://inertiajs.com https://inertiajs.com

endisneigh 5y ago

It’s hard to draw any real conclusions from this. The author says things that the delta between an average single page app is great from multi page, but is that true? The author makes tons of claims but presents no evidence. Seems more about poorly designed apps and managed teams than anything inherent in either type of app.

jgwil2 5y ago

> Single-Page-Apps can be amazing. > You can make a great Single-Page-App with a User Experience that a traditional site will never be able to close to matching. What is actually meant by this? What is an example of a feature that can be far better in a SPA than in an MPA?

afavour 5y ago
You can persist data on the client with IndexedDB and make a SPA with zero load times no matter what page you’re loading. That would never be possible with a MPA. It’s also almost never something that actually happens with SPAs but it certainly is possible.
- mwcampbell 5y ago
  The best example I know of a purely client-side web app that makes effective use of local storage is the Pinafore [1] client for Mastodon. Edit: And it's worth noting that this app is a labor of love by an expert web developer, i.e. the antithesis of a typical corporate project. [1]: https://pinafore.social/ https://pinafore.social/
resignThis2021 5y ago
Spreadsheet apps in the browser?
rcakebread 5y ago
Playing audio or video without interruption while navigating the site.
- jgwil2 5y ago
  Somewhat niche but a good use case, thanks.
- bestinterest 5y ago
  Eh unfortunately its muddy there too, see changelog.com which is not an SPA and instead uses Turbolinks (now Turbo) to persist the podcast element at the bottom of the screen.

jonathan-adly 5y ago

I have been developing lately with A django/HTMX stack[0]. It covers a lot of the positives of JS SPA, without the headache. Also, I get to use the Django superpowers. https://htmx-django.com https://htmx-django.com

mwcampbell 5y ago
I appreciate that Django is a good old full-stack server-side framework, and there's a lot to like about that. But I can't bring myself to start a new project with something that has the gross inefficiency of CPython (or, IIUC, stock Ruby), as discussed at, for example, [1] and [2]. I want a runtime environment that's efficient enough that I can deploy the web application on a couple of small VMs, still have plenty of headroom for load spikes (which, in my experience, are usually due to screwups on my part and not actual demand spikes), and delay thinking about scaling as long as possible. [1]: https://rachelbythebay.com/w/2020/03/07/costly/ https://rachelbythebay.com/w/2020/03/07/costly/ [2]: https://blog.clubhouse.com/reining-in-the-thundering-herd-with-django-and-gunicorn/ https://blog.clubhouse.com/reining-in-the-thundering-herd-wi...
harryvederci 5y ago
Surprised htmx isn't mentioned more in the comments. I'm using it with Janet for a side project, really liking it so far. Writing server-side html with a hiccup-like library is very nice! :) (Clojure Hiccup library, similar libraries exist for other lisp-like languages: https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup)

est 5y ago

if SPAs are bad, compiled JS are evil. They only seem to hijack the scrollbar or give cookie consent or waste 2/3 of viewport with a fucking subscribe/login cover. Every page should promise some kind of plain text content length vs full page resource bytes ratio. Why would anyone emit 20MB of .min.js only to deliver 140 characters of tweet?

kbsspl 5y ago
thank you for saying that.
Raidion 5y ago
I get the feeling, but it's worth noting that it's not just 140 characters of tweet. It's also delivering all the analytics, the content surrounding the tweet (replies, likes, etc), and is a teaser to the rest of the app. The business driver isn't just delivering the content, it's increasing engagement, and the SPA application provides a significantly better and scalable way to make that happen. Everyone seems to think they could do better, and we end up with yet another "modern" JS framework.

DerekBickerton 5y ago

For the bulk of my Internet surfing, I have JS turned off by default in uBlock. Now and then I encounter a white screen of death which on closer inspection is a Single Page App (and didn't have the courtesy of having a <noscript> tag telling me I needed JS to view the page). I have JS turned off for accessibility and privacy reasons. What annoys me is sometimes JS is needed just to render a bit of text when it could be rendered with plain HTML. Not everything needs to have JS in order to work/function. Also: many hamburger menus are rendered useless when JS is turned off when it could be implemented with CSS alone.

lsalvatore 5y ago

I can't relate to this at all. I've been happily working on SPAs with React and Redux for nearly 6 years. Hotwire makes no sense: switching to managing client-side state on the server and sending HTML over the wire introduces a ton of problems: you are going to have to write and debug JavaScript eventually. Now your server is running client-side code to update every local browser state? How is that scalable at all? React has a ton of great libraries for UI that these articles always ignore: Something like react-select to manage a dynamic dropdown- you can't implement that on the server. You need SPAs for complex dashboards, and React is a great library to store and update local state. I don't understand what the controversy is.

sanderjd 5y ago
I've always thought some of it stems from the nomenclature and the cultures that flow from it. A lot of people (reasonably) don't think the best architecture for their application is a "single page". But many of those same people nonetheless have (often large) portions of their application that benefit from complex client side interactivity. But the whole thing can seem really all or nothing, either you have a "single page application" that does everything client side or you do everything through html from the server. Of course in practice everybody does some hybrid in between these two extremes. But the apparent split creates a cultural battle between the extremes, which is not helpful.
- lsalvatore 5y ago
  I come from a financial reporting background where pages needed to be dynamic and update through filters / sorting / etc- think Excel or Robinhood- these are applications, not pages. When you are building an application, users don't want to experience a page refresh. You either want a dynamic behavior without page refresh, or not. React Router gives you client-side routing- I don't know why you wouldn't want that even if you were building something like AirBnB where there is mostly static content- to argue against dynamic search and filtering without page refresh seems silly to me.
  - sanderjd 5y ago

kbsspl 5y ago

Great style of writing. A great example of a 'forced perspective'. The entire ecosystem of browsers, standards, devices, business imperatives is being forcefully turned into a spa/mpa comparison.

sanderjd 5y ago

Maybe an unpopular opinion here: as a user of web applications, I very strongly prefer the "modern" javascript heavy SPA dominated culture of recent years. Every once in awhile I get annoyed by something that is just a webpage but thinks it's an application, but more often I have the reverse annoyance. But as a developer, I agree that it is harder to develop these kinds of applications that I like than it used to be to develop multi page applications with mostly server side logic and only sprinkles of javascript. I guess I just do, actually, think there is UX benefit to the complexity. But of course there are better and worse ways to accomplish it, figuring out that balance is the hard part.

mwcampbell 5y ago
Can you expand on why you prefer the JS-heavy SPA style?
- sanderjd 5y ago
  Because they are faster and easier to use. Using them is like using an application, rather than like using a website. I think a good rule of thumb is: am I mostly clicking or mostly scrolling? If I'm mostly clicking - say, something like AirBnB or Zillow or Discord - where I'm exploring things and interacting a bunch, that feels better to me as a rich client-side application. If I'm mostly scrolling, like a blog or substack or a newspaper or even twitter, that feels better as a website. I thought of a good concrete comparison: Vanguard vs. Coinbase Pro. Vanguard is a website, and it basically works for them because their business model is very passive, but you wouldn't want to do active trading there. Coinbase Pro is a web application where you can do lots of exploration and take actions quickly, and for me, it would be a major hindrance if they implemented it in a traditional page-based way.
  - DeathArrow 5y ago
    If you want to use an application, then why don't you download and run an application? You will have a better experience running an application on desktop instead of running it on the browser.

denton-scratch 5y ago

SPAs make web resources impossible to index or link to - by definition, they do not contain "pages". OP failed to mention this at all. For me, this is the killer "anti" posture. Hyperlinks are the defining feature of the WWW; that people put resources on the WWW that can't be linked to, is cause for regret.

ngrilly 5y ago
It used to be impossible to link to specific page in a SPA without using hashes in the URL, but this problem has been solved years ago, and all modern browsers support it.
- denton-scratch 5y ago
  What's a "specific page" in the context of discussing single-page applications?
  - hbn 5y ago
    If you go to example.com/user/jim in your browser, it'll navigate to (presumably) the profile for the user with the handle "jim" Maybe I don't understand what you're asking. Browsers these days have functionality that enables SPAs to navigate between URLs, push/pop to and from the back history, etc. without full page reloads.
    - denton-scratch 5y ago
      Well, example.com/user/jim looks to me like a Unique Resource Locator. If that's right, then what I'll get is a "page" (you could call it a resource). If the locator is really "unique", It'll be different from the page I get if I ask for example.com/user/jane, right? (modulo aliasing) Well if that's right, then this site is not a "single-page application". It has multiple pages with different URLs, and I don't know how that's different from any other website with server-side state. [Edited to mention state; state is irrelevant to whether its an MPA or an SPA, but without state it's hard to argue its an application at all]

shadowgovt 5y ago

This rings extremely true based on my observation. Fundamentally, companies working on large projects will ship their org chart. It is modestly more difficult, if your org chart gets spilt in two such that two or more teams are now maintaining the same SPA, to synchronize their work such that they don't interfere with each other's activities. You begin looking at a more traditional application development model with full program integration testing in the mix. Multiple pages means multiple entirely separate client-side contexts that are a security hole if they can clobber each other.

hahamrfunnyguy 5y ago

I've been doing web development for over twenty years now. Perl, PHP, ASP, Rails, .NET, Flash, Flex, Silverlight and various JavaScript and SPA frameworks. I really like the MPA approach. To me it means building a bunch of mini SPAs. You can still stuff everything into a single SPA to deploy to a mobile app, but it gives you the advantage quicker first-time page loads and a lot of extra flexibility. Compared to the Web 1.0 way of doing things where you POST and then reload the page, you're taking an API based approach so when a 3rd party needs to integrate with you - that part is probably done already. A lot of sites use the MPA approach wrong though. They load the "apps", then proceed to make a whole bunch of asynch requests for data. In most cases, using a mechanism to inject in data when a page first loads makes everything feel a lot faster. It's the best of both worlds: you get the speed of the old school web and the flexibility of modern practices.

martin_drapeau 5y ago
I couldn't agree more. It is a spectrum. <-- Fully MPA ... MPA with mini SPAs ... Fully SPA. --> Many don't venture in the middle. Not sure why. Do not stay on either end. It will bite you!
- zerkten 5y ago
  People don't venture in the middle because it's complicated and scary for many people due to the skill requirements. It only starts to feel safe to play there when you have experience with development at both ends of the spectrum because you likely won't have the support of tools which are intended to run there. Further, it's a compromise that is difficult to explain and justify to management. If they are risk averse then they won't want to move far from the safety of the frameworks at either end of the spectrum. If you are a developer of frameworks, it also seems advantageous to go to one end of the spectrum because it's easier to reason about the problem space. When you target the middle there starts to be more variations in how to handle it best. It's really the only place to go though, if folks really want to innovate and provide better experiences for all.
  - 5y ago

DeathArrow 5y ago

It's the Web what Tim Berners Lee envisioned it to be, a web of "dumb" hypertext used to disseminate information or a web of interlinked apps which happen to run in the browser instead of desktop or mobile? In the 2000 it was clear: if you wanted to find informations, you went on the www. If you wanted to chat, you used an IRC app. If you wanted to type a document, you opened a text processor. If you wanted to see a movie, you used a movie player. If you wanted to listen to music, you opened a music player. If you wanted to game, you fired a game. Now all this are on the web. It's not clear to me if I am a web developer or an app developer because the borders are erased day by day.

DeathArrow 5y ago

For me SPAs are when we want to run apps in the browser less efficiently than on the desktop or mobile, while taking more time to develop them.

oblib 5y ago

Well this made me feel good about being a lone developer who gets to make all the decisions on how to make an app.

etchalon 5y ago

Is this a React thing? I haven't run into any of these problems in five years of building Vue.js SPAs. Literally everything is easier, and faster, than traditional MPA development.

toddmorey 5y ago

Those interested in this debate really need to watch a very fantastic presentation on this exact topic: "Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes" [1] [1] https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77lF-XaNacKxWk7yOKgeCMveAS&index=2 https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77l...

nyanpasu64 5y ago

> the root cause of every bad Single-Page-App isn’t that it’s a Single-Page-App. The root cause of https://vector-of-bool.github.io/ https://vector-of-bool.github.io/ scrolling incorrectly when navigating between pages isn't due to bad management or lack of care, it's because it's a single page app that didn't handle scrolling correctly (which a browser would provide for free), and the author didn't notice despite coming in with good intentions.

snarkypixel 5y ago
That's the point of the article though. SPA is /hard/. Using a normal many-page app, you get scrolling that works across all browser - even mobile - for free, without having to do anything. I'm not saying I necessarily agree, but that's what this article is about.
- nyanpasu64 5y ago
  > Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations. I don't think the vector-of-bool website, and the broken JS transitions, were designed by a dysfunctional organization (or an organization for that matter) (though the author has suffered from burnout: https://vector-of-bool.github.io/2019/05/23/signals.html https://vector-of-bool.github.io/2019/05/23/signals.html).
bestinterest 5y ago
It gets even muddier when you consider the fact that MPA transitions will be in browsers hopefully quite soon and you will be able to achieve the exact same effect. https://developer.chrome.com/blog/shared-element-transitions-for-spas/ https://developer.chrome.com/blog/shared-element-transitions...

KarlKemp 5y ago

So... the idea is that there's a gray area in most debates, the answer usually isn't found at the extremes, the tech community needs to beware of groupthink, and, fundamentally, hold on to your hats, that ... ... management is just really stupid? Yeah, that's a really really rare opinion in tech circles.