6 ms·

Thoughtworks downgrade “SPAs as default” to “Hold”

33 points by brtkdotse 5y ago

MattGaiser 5y ago
The specific content: https://www.thoughtworks.com/radar/techniques/spa-by-default https://www.thoughtworks.com/radar/techniques/spa-by-default
- brtkdotse 5y ago
  Hmm, seems HN strips out query strings. Can't seem to update the URL manually either. Thanks!
  - MattGaiser 5y ago
    Which is interesting, as HN uses query strings for bits of content.
pangolin1 5y ago
> Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React This is exactly why it's often best to use React even if it's overkill. It makes recruiting and onboarding new devs to the codebase much easier. Given the rate of turnover for frontend devs, this is a significant advantage.
- lucasyvas 5y ago
  This is a tough stance for me to get on board with. You're not wrong to value SPAs for this reason, but I don't think picking the wrong architecture on purpose is defensible either.
  - dbbk 5y ago
    There are no panaceas in technology stacks, but it does shock me sometimes how teams blindly jump to React (and sometimes Next) just due to perceived popularity and don't actually do any analysis on what their problem points are, and whether it would make sense for them.
    - jen20 5y ago
      A few months ago (around the Christmas break) I decided to build a web UI for something. The last time I personally touched “front end” HTML or JS was when IE5 was a thing, although I’ve done a lot with server side TypeScript and the Node ecosystem. I spent a couple of days evaluating the options, coming at this with fresh eyes, but not as a beginner to programming or architecture, and found the following: - Ember makes the most sense to me personally, but at the time the stable ember packages pulled in several dependencies npm called out as vulnerable, and editor support was not great. The webstorm plug-in basically didn’t do anything useful. Finally, it was not obvious that TypeScript was a first class citizen, which put me off. - Vue seemed ok, if a little harder to reason about than Ember - I can see why people like it but there didn’t seem to be a compelling reason to put effort into it. - React is hands down the “winner” of the ecosystem, is easy to get up and running with and has great editor support. As someone that generally likes functional programming, the concepts clicked nicely. TypeScript was first class, TSX seems nice enough. In the end, the limited time I had meant I just wrote a native Mac app with SwiftUI, and resolved not to touch web stuff for another 2 decades if I could avoid it. I have a huge amount of respect for people who can keep the front end web ecosystem straight in their head - I really don’t understand why people consider “back end” the more complex technical domain.
    - brtkdotse 5y ago
      Especially for things that are for all intents and purposes, read-only.
- ydlr 5y ago
  And if a client asks why you are recommending an SPA, are you going to tell them the ignorance of your employees requires it?
- FractalHQ 5y ago
  Svelte is still the better choice. It compiles to much better optimized and smaller bundles, and a team of React devs can learn Svelte in a weekend thanks to how much leaner and more intuitive it is, as well as how true it stays to writing vanilla JS/HTML/CSS. The huge gains in dev speed and ability to plug and play any vanilla library without a framework wrapper make it hard to justify React over Svelte.
lucasyvas 5y ago
Someone taking a stance on this is long overdue. I basically exclusively write SPAs and they are way, way harder than MPAs to keep straight due to state behaviour and the mountain of JS. Additionally, component-first designs are frankly often NOT what is wanted by your product and design team. What they want is to easily update how the page looks, and a lot of the time that is factually way easier with a template-first approach. There exists a gray area, but SPA by default is ludicrous. Please consider what you are trading off if you do this, because it's often not worth it and I'm tired of having to argue such an obvious point everywhere I work. From what I've observed, SPAs will never close the performance gap with a MPA server-rendered page. Even if you could, the effort required would not be worth it.
- brtkdotse 5y ago
  > From what I've observed, SPAs will never close the performance gap with a MPA server-rendered page. Even if you could, the effort required would not be worth it. It feels like the performance was one of the key selling points of stuff like Gatsby, but in reality it scored absymaly on all metrics compared to a vanilla WordPress installation on a $5 DO droplet.
  - valand 5y ago
    Without numbers, I doubt this. With the same computer spec, serving file via HTTP (gatsby) is cheaper - or at least wont scale parallel to complexity - compared to WordPress which build the page at request-time, unless I'm not up to date with how WordPress is rendered right now.
- Spivak 5y ago
  I can sympathize with the “mountain of JS” but SPAs way easier to reason about in abstract. In SPA world there’s an API server which is self-contained and has clear boundaries — take JSON payload ish and return JSON payload ish. Server has no knowledge or connection to any client. Client is a static bundle of JS and assets which just calls the API just like our iOS/Android/CLI. Once you involve SSR (beyond hydration) you’re in for a world of hurt because you’re mixing the two. The JS doesn’t know about the HTML despite them hard depending on one another and the two processes can’t communicate back and forth anymore. Both sides are disconnected but have shared state because half of the client is actually on the server. Way more complicated than every half keeping its own books without any care. If it weren’t for “it’s what we had to do back then” it would be considered nuts to codegen whole applications and then send them across the network to run but that’s SSR.
jka 5y ago
A slight tangent, but it also seems that the progressive web application (PWA) technique, although briefly recommended[1] for "trial" has been removed from the radar. [1] - https://www.thoughtworks.com/radar/techniques/progressive-web-applications https://www.thoughtworks.com/radar/techniques/progressive-we...
- erikdoe 5y ago
  Almost everything gets "removed" from the radar every six months. The Thoughtworks radar is published twice a year, and each volume of it only contains what Thoughtworks found new and noteworthy in the six months leading up to the publication of a volume. There's more in the FAQ: https://www.thoughtworks.com/radar/faq-and-more https://www.thoughtworks.com/radar/faq-and-more

33 points by brtkdotse 5y ago

The specific content: https://www.thoughtworks.com/radar/techniques/spa-by-default https://www.thoughtworks.com/radar/techniques/spa-by-default

brtkdotse 5y ago
Hmm, seems HN strips out query strings. Can't seem to update the URL manually either. Thanks!
- MattGaiser 5y ago
  Which is interesting, as HN uses query strings for bits of content.

pangolin1 5y ago

> Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React This is exactly why it's often best to use React even if it's overkill. It makes recruiting and onboarding new devs to the codebase much easier. Given the rate of turnover for frontend devs, this is a significant advantage.

lucasyvas 5y ago
This is a tough stance for me to get on board with. You're not wrong to value SPAs for this reason, but I don't think picking the wrong architecture on purpose is defensible either.
- dbbk 5y ago
  There are no panaceas in technology stacks, but it does shock me sometimes how teams blindly jump to React (and sometimes Next) just due to perceived popularity and don't actually do any analysis on what their problem points are, and whether it would make sense for them.
  - jen20 5y ago
    A few months ago (around the Christmas break) I decided to build a web UI for something. The last time I personally touched “front end” HTML or JS was when IE5 was a thing, although I’ve done a lot with server side TypeScript and the Node ecosystem. I spent a couple of days evaluating the options, coming at this with fresh eyes, but not as a beginner to programming or architecture, and found the following: - Ember makes the most sense to me personally, but at the time the stable ember packages pulled in several dependencies npm called out as vulnerable, and editor support was not great. The webstorm plug-in basically didn’t do anything useful. Finally, it was not obvious that TypeScript was a first class citizen, which put me off. - Vue seemed ok, if a little harder to reason about than Ember - I can see why people like it but there didn’t seem to be a compelling reason to put effort into it. - React is hands down the “winner” of the ecosystem, is easy to get up and running with and has great editor support. As someone that generally likes functional programming, the concepts clicked nicely. TypeScript was first class, TSX seems nice enough. In the end, the limited time I had meant I just wrote a native Mac app with SwiftUI, and resolved not to touch web stuff for another 2 decades if I could avoid it. I have a huge amount of respect for people who can keep the front end web ecosystem straight in their head - I really don’t understand why people consider “back end” the more complex technical domain.
  - brtkdotse 5y ago
    Especially for things that are for all intents and purposes, read-only.
ydlr 5y ago
And if a client asks why you are recommending an SPA, are you going to tell them the ignorance of your employees requires it?
FractalHQ 5y ago
Svelte is still the better choice. It compiles to much better optimized and smaller bundles, and a team of React devs can learn Svelte in a weekend thanks to how much leaner and more intuitive it is, as well as how true it stays to writing vanilla JS/HTML/CSS. The huge gains in dev speed and ability to plug and play any vanilla library without a framework wrapper make it hard to justify React over Svelte.

lucasyvas 5y ago

Someone taking a stance on this is long overdue. I basically exclusively write SPAs and they are way, way harder than MPAs to keep straight due to state behaviour and the mountain of JS. Additionally, component-first designs are frankly often NOT what is wanted by your product and design team. What they want is to easily update how the page looks, and a lot of the time that is factually way easier with a template-first approach. There exists a gray area, but SPA by default is ludicrous. Please consider what you are trading off if you do this, because it's often not worth it and I'm tired of having to argue such an obvious point everywhere I work. From what I've observed, SPAs will never close the performance gap with a MPA server-rendered page. Even if you could, the effort required would not be worth it.

brtkdotse 5y ago
> From what I've observed, SPAs will never close the performance gap with a MPA server-rendered page. Even if you could, the effort required would not be worth it. It feels like the performance was one of the key selling points of stuff like Gatsby, but in reality it scored absymaly on all metrics compared to a vanilla WordPress installation on a $5 DO droplet.
- valand 5y ago
  Without numbers, I doubt this. With the same computer spec, serving file via HTTP (gatsby) is cheaper - or at least wont scale parallel to complexity - compared to WordPress which build the page at request-time, unless I'm not up to date with how WordPress is rendered right now.
Spivak 5y ago
I can sympathize with the “mountain of JS” but SPAs way easier to reason about in abstract. In SPA world there’s an API server which is self-contained and has clear boundaries — take JSON payload ish and return JSON payload ish. Server has no knowledge or connection to any client. Client is a static bundle of JS and assets which just calls the API just like our iOS/Android/CLI. Once you involve SSR (beyond hydration) you’re in for a world of hurt because you’re mixing the two. The JS doesn’t know about the HTML despite them hard depending on one another and the two processes can’t communicate back and forth anymore. Both sides are disconnected but have shared state because half of the client is actually on the server. Way more complicated than every half keeping its own books without any care. If it weren’t for “it’s what we had to do back then” it would be considered nuts to codegen whole applications and then send them across the network to run but that’s SSR.

jka 5y ago

A slight tangent, but it also seems that the progressive web application (PWA) technique, although briefly recommended[1] for "trial" has been removed from the radar. [1] - https://www.thoughtworks.com/radar/techniques/progressive-web-applications https://www.thoughtworks.com/radar/techniques/progressive-we...

erikdoe 5y ago
Almost everything gets "removed" from the radar every six months. The Thoughtworks radar is published twice a year, and each volume of it only contains what Thoughtworks found new and noteworthy in the six months leading up to the publication of a volume. There's more in the FAQ: https://www.thoughtworks.com/radar/faq-and-more https://www.thoughtworks.com/radar/faq-and-more