4 ms·

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 behavi

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.
- erikdoe 5y ago
  In my opinion the reasoning why "SPAs [are] way easier to reason about in the abstract" is neglecting to acknowledge that most applications evolve over time. There is no well-defined API on the server side. The application logic is smeared across code the runs in the browser and code that runs on a server. That "API" is usually merely an HTTP endpoint that connects both sides. Adding new functionality to the application requires touching both sides, and changing the HTTP endpoint. I would use different approaches to build those HTTP endpoints and to build a "proper" API that's used by different consumers. Full disclosure: I'm one of the authors of the Tech Radar, and we've actually written about this coupling between the two sides of an app in a different context here: https://www.thoughtworks.com/radar/techniques/ui-bff-shared-types https://www.thoughtworks.com/radar/techniques/ui-bff-shared-...
- brtkdotse 5y ago
  > 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. In theory yes, in practice I’ve more often than not seen the same team build both client and API meaning they’ve just added a bunch of operational complexity without having anything to show for it.
robertoandred 5y ago
What about an SPA do you think is slow vs server-rendered?
- valand 5y ago
  SPA usually consists of bulky js files if not utilizing lazy-loading correctly. The size makes it slow. But, I think this thread is conflating SPA vs MPA and compile-time vs request-time "rendering". With the same complexity, compile-time rendering should be faster than request-time rendering. But in reality, most compile-time rendering is also SPA. There are also other factors such as server's performance and cache utilization which people often forget when talking about this topic
MrJohz 5y ago
Can you clarify a bit what you mean with the component-first design part? In my experience, working with components is a significant force-multiplier in terms of being able to encapsulate behaviour within an application, but I'm intrigued what you see as difficult here.
- lucasyvas 5y ago
  It's only a force multiplier if your Design team sticks to it to the letter, and also if you are able to upkeep the components and refactor them nicely and often. What you more often get are requests to redo one page with a newer design and go from there. Well, the overhead for that is now massive, because all the components need to be refactored to allow customizable style, or you need to build new replacement components for pages to opt into, then redo the pages with all these new components slotted into a new layout. ...and all they wanted was to change the borders, input field appearance, colors and try to make the existing table more responsive. In other words, they are (probably?) hoping that the page has something like one giant data object / hook that is 100 percent separate from the UI, where you can just screw with the style sheet and the markup to try some things out quickly and call it a day. In a component design you have to think carefully about what gets data from where, but this is something the non-tech folks at an org just don't give a shit about, and they expected you to just be able to tweak the page. So, to me the optimal technical approach is page template first, maturing into component re-use second. And I would suggest you decide carefully what to make into components when nobody has formally asked you to do so, because: 1. The overhead of arguing about time required to refactor/rebuild components is absolutely real. The point of components is that you shouldn't build snowflakes, yet that is what is routinely wanted. 2. Scope of "simple" component changes potentially touch the whole app when you'd rather it - or morely need it to - NOT.
  - MrJohz 5y ago
    Thank you, that's a very interesting response, and also the complete opposite of my experience with this sort of thing! In my experience, the design team is often even more component-driven than the dev team, with more interest in things right down to things like design tokens to specify consistent line widths. Whereas developers also use components to encapsulate design, but mainly use it to encapsulate behaviour or local state - say, a drop-down that needs a particular search functionality, or a breadcrumb component that needs to update as the page history changes. But thanks for your perspective.

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.

erikdoe 5y ago
In my opinion the reasoning why "SPAs [are] way easier to reason about in the abstract" is neglecting to acknowledge that most applications evolve over time. There is no well-defined API on the server side. The application logic is smeared across code the runs in the browser and code that runs on a server. That "API" is usually merely an HTTP endpoint that connects both sides. Adding new functionality to the application requires touching both sides, and changing the HTTP endpoint. I would use different approaches to build those HTTP endpoints and to build a "proper" API that's used by different consumers. Full disclosure: I'm one of the authors of the Tech Radar, and we've actually written about this coupling between the two sides of an app in a different context here: https://www.thoughtworks.com/radar/techniques/ui-bff-shared-types https://www.thoughtworks.com/radar/techniques/ui-bff-shared-...
brtkdotse 5y ago
> 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. In theory yes, in practice I’ve more often than not seen the same team build both client and API meaning they’ve just added a bunch of operational complexity without having anything to show for it.

robertoandred 5y ago

What about an SPA do you think is slow vs server-rendered?

valand 5y ago
SPA usually consists of bulky js files if not utilizing lazy-loading correctly. The size makes it slow. But, I think this thread is conflating SPA vs MPA and compile-time vs request-time "rendering". With the same complexity, compile-time rendering should be faster than request-time rendering. But in reality, most compile-time rendering is also SPA. There are also other factors such as server's performance and cache utilization which people often forget when talking about this topic

MrJohz 5y ago

Can you clarify a bit what you mean with the component-first design part? In my experience, working with components is a significant force-multiplier in terms of being able to encapsulate behaviour within an application, but I'm intrigued what you see as difficult here.

lucasyvas 5y ago
It's only a force multiplier if your Design team sticks to it to the letter, and also if you are able to upkeep the components and refactor them nicely and often. What you more often get are requests to redo one page with a newer design and go from there. Well, the overhead for that is now massive, because all the components need to be refactored to allow customizable style, or you need to build new replacement components for pages to opt into, then redo the pages with all these new components slotted into a new layout. ...and all they wanted was to change the borders, input field appearance, colors and try to make the existing table more responsive. In other words, they are (probably?) hoping that the page has something like one giant data object / hook that is 100 percent separate from the UI, where you can just screw with the style sheet and the markup to try some things out quickly and call it a day. In a component design you have to think carefully about what gets data from where, but this is something the non-tech folks at an org just don't give a shit about, and they expected you to just be able to tweak the page. So, to me the optimal technical approach is page template first, maturing into component re-use second. And I would suggest you decide carefully what to make into components when nobody has formally asked you to do so, because: 1. The overhead of arguing about time required to refactor/rebuild components is absolutely real. The point of components is that you shouldn't build snowflakes, yet that is what is routinely wanted. 2. Scope of "simple" component changes potentially touch the whole app when you'd rather it - or morely need it to - NOT.
- MrJohz 5y ago
  Thank you, that's a very interesting response, and also the complete opposite of my experience with this sort of thing! In my experience, the design team is often even more component-driven than the dev team, with more interest in things right down to things like design tokens to specify consistent line widths. Whereas developers also use components to encapsulate design, but mainly use it to encapsulate behaviour or local state - say, a drop-down that needs a particular search functionality, or a breadcrumb component that needs to update as the page history changes. But thanks for your perspective.