3 ms·

But there's no world where the tooling doesn't suck for an SPA. As the application grows, the bundle is going to grow and the caching / building / splitting pr

But there's no world where the tooling doesn't suck for an SPA. As the application grows, the bundle is going to grow and the caching / building / splitting problems will just increase higher and higher. All those esbuild & associated tools just slightly delay the inevitable. All the ones I worked on inevitably stumble upon this problem and the worst part is, the bigger your team is, the harder it's going to be to scale an SPA meaning that hiring more people doesn't even help here.

lelanthran 3y ago
> But there's no world where the tooling doesn't suck for an SPA. I dunno about that. I've seen good things with htmx. Also pretty nifty things with web components. An SPA doesn't have to use all the most modern frameworks. SPAs were being done long before React and friends were created, long before even Jquery was popular.
- realusername 3y ago
  Htmx isn't built with SPAs in mind. Htmx is the opposite approach to an SPA in my opinion, it's traditional views but improved. And yes, that does scale easier compared to an SPA, there's no bundling / splitting / caching complexity here. Technologies where the frontend bundle increase with a flat or nearly flat curve as the features get added have a much much easier time to scale than the ones which do not.
  - candiddevmike 3y ago
    What is your definition of scaling here? A large, untyped, JS-in-HTML via Htmx codebase reminds me of the jquery dark ages.
    - realusername 3y ago
      Scaling in this context means for me that features are decorrelated from the payload sent to the browser. If they are, it's good news as more stuff gets built into the product, you have time to figure out how to continue forward and you have more resources to throw at this small problem. If they aren't, well this is some pretty bad news since the more feature you add, the more complex the tooling is going to be to make it work, it becomes exponentially harder to maintain. As bad as Htmx might look visually, it's going to be significantly easier to scale on a large platform since everything is decoupled apart from some common js bits you could add here and there. On the opposite spectrum, we have a React SPA at work with a 65mb bundle which take 2GB of ram just to build, caching & splitting is obviously a nightmare. That's what happens when you have a lot of engineers working on a product and the bundle isn't decorrelated from the features.

lelanthran 3y ago

> But there's no world where the tooling doesn't suck for an SPA. I dunno about that. I've seen good things with htmx. Also pretty nifty things with web components. An SPA doesn't have to use all the most modern frameworks. SPAs were being done long before React and friends were created, long before even Jquery was popular.

realusername 3y ago
Htmx isn't built with SPAs in mind. Htmx is the opposite approach to an SPA in my opinion, it's traditional views but improved. And yes, that does scale easier compared to an SPA, there's no bundling / splitting / caching complexity here. Technologies where the frontend bundle increase with a flat or nearly flat curve as the features get added have a much much easier time to scale than the ones which do not.
- candiddevmike 3y ago
  What is your definition of scaling here? A large, untyped, JS-in-HTML via Htmx codebase reminds me of the jquery dark ages.
  - realusername 3y ago
    Scaling in this context means for me that features are decorrelated from the payload sent to the browser. If they are, it's good news as more stuff gets built into the product, you have time to figure out how to continue forward and you have more resources to throw at this small problem. If they aren't, well this is some pretty bad news since the more feature you add, the more complex the tooling is going to be to make it work, it becomes exponentially harder to maintain. As bad as Htmx might look visually, it's going to be significantly easier to scale on a large platform since everything is decoupled apart from some common js bits you could add here and there. On the opposite spectrum, we have a React SPA at work with a 65mb bundle which take 2GB of ram just to build, caching & splitting is obviously a nightmare. That's what happens when you have a lot of engineers working on a product and the bundle isn't decorrelated from the features.