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/

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?

ESBuild already does a lot, and is already extendable via 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).

> 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).

> programming with wet noodles

Very balanced mature technical argument.

Made sense to me!

It's what we technical folk refer to as spaghetti code.

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.

Not sure why your comment was downvoted to death.

> 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.

That's definitely one path towards spaghetti code. An inexperienced developer can make a mess of their own codebase without contributors also though.

I do agree that it's very rarely the result of an actual defect in the chosen programming language. You can write clean code in almost any general purpose programming language, and conversely, you can write bad code in any language as well.

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.

> 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.

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.

What is your definition of scaling here? A large, untyped, JS-in-HTML via Htmx codebase reminds me of the jquery dark ages.

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.