4 ms·

I think that this all boils down to "The tooling sucks". The specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. None

I think that this all boils down to "The tooling sucks". The specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. None of the SPA problems mentioned are specific to SPA, they're specific to current toolsets.

realusername 3y ago
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.
toastercat 3y ago
Just like to say, you can have a pretty robust SPA tooling experience ONLY using esbuild. Yes, you give up a lot of the features provided by larger tools, but you also have less things to have to understand. I recommend this article about a non-js savvy person: https://jvns.ca/blog/2021/11/15/esbuild-vue/ https://jvns.ca/blog/2021/11/15/esbuild-vue/
- candiddevmike 3y ago
  I don't know why esbuild still lacks these features over all these years. Seems like everyone is using it for various things (like vite) but no one wants to contribute to it to make it The One Tool. Is it JS/TS devs not wanting to work on a Go app? Folks not wanting to disrupt the status quo of Vite?
  - toastercat 3y ago
    ESBuild already does a lot, and is already extendable via plugins https://github.com/esbuild/community-plugins https://github.com/esbuild/community-plugins. I think it's more that the maintainers of ESBuild want it to focus on doing the essentials well (which it does, IMO).
cpursley 3y ago
> specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. These are all issues, but the real issue is JavaScript itself (i.e., programming with wet noodles).
- throwitaway1123 3y ago
  > programming with wet noodles Very balanced mature technical argument.
  - rokkitmensch 3y ago
    Made sense to me!
    - deleted 3y ago
      [deleted]
  - lelanthran 3y ago
    It's what we technical folk refer to as spaghetti code.
    - throwitaway1123 3y ago
      I'm familiar with the term, I'm just wondering what features of JS as a language necessitates code degenerating into spaghetti. The comment I was replying to was a bit light on technical details. I'm not convinced by someone broadly gesturing at a language and saying "it's all spaghetti code". It just reeks of snark, and feels like a very shallow dismissal of a programming language.
      - practicemaths 3y ago
        > language necessitates code degenerating into spaghetti I'm by no means a thoroughly vested expert, so my speculation has little merit here. However if I had to guess code becoming spaghetti is more a symptom of collaboration between many individuals over a span of time rather than an issue with a specific programming language. Everyone has preferences and different backgrounds, various "best practices" they've been taught or adhere to. So when all those little differences merge together over time you get globs and hard to follow code due to changes in conventions or just being lazy when meeting a deadline.

realusername 3y ago

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.

toastercat 3y ago

Just like to say, you can have a pretty robust SPA tooling experience ONLY using esbuild. Yes, you give up a lot of the features provided by larger tools, but you also have less things to have to understand. I recommend this article about a non-js savvy person: https://jvns.ca/blog/2021/11/15/esbuild-vue/ https://jvns.ca/blog/2021/11/15/esbuild-vue/

candiddevmike 3y ago
I don't know why esbuild still lacks these features over all these years. Seems like everyone is using it for various things (like vite) but no one wants to contribute to it to make it The One Tool. Is it JS/TS devs not wanting to work on a Go app? Folks not wanting to disrupt the status quo of Vite?
- toastercat 3y ago
  ESBuild already does a lot, and is already extendable via plugins https://github.com/esbuild/community-plugins https://github.com/esbuild/community-plugins. I think it's more that the maintainers of ESBuild want it to focus on doing the essentials well (which it does, IMO).

cpursley 3y ago

> specific SPA problems mentioned are due to the bundling, the packing, the dependencies, etc. These are all issues, but the real issue is JavaScript itself (i.e., programming with wet noodles).

throwitaway1123 3y ago
> programming with wet noodles Very balanced mature technical argument.
- rokkitmensch 3y ago
  Made sense to me!
  - deleted 3y ago
    [deleted]
- lelanthran 3y ago
  It's what we technical folk refer to as spaghetti code.
  - throwitaway1123 3y ago
    I'm familiar with the term, I'm just wondering what features of JS as a language necessitates code degenerating into spaghetti. The comment I was replying to was a bit light on technical details. I'm not convinced by someone broadly gesturing at a language and saying "it's all spaghetti code". It just reeks of snark, and feels like a very shallow dismissal of a programming language.
    - practicemaths 3y ago
      > language necessitates code degenerating into spaghetti I'm by no means a thoroughly vested expert, so my speculation has little merit here. However if I had to guess code becoming spaghetti is more a symptom of collaboration between many individuals over a span of time rather than an issue with a specific programming language. Everyone has preferences and different backgrounds, various "best practices" they've been taught or adhere to. So when all those little differences merge together over time you get globs and hard to follow code due to changes in conventions or just being lazy when meeting a deadline.