The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985.

React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now.

The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it.

The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike.

> Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite

Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool.

I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations.

Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.

React is boilerplate madness.

Do the same in Svelte.

I did a form heavy app in Svelte, literally took 1/5th the time it would have taken in React.

SPA fundamentally means that instead of refreshing the page, just the data needed to update what is on screen is sent down to the user.

Ideally, "send data about products on next page of search results" is less than "send all HTML needed to render the next page of search results."

Also the backend ends up simpler, instead of trying to template strings together, the code can just worry about fetching and returning needed data.

I am legit confused why people think generating HTML in some other language (Python, Ruby, etc) is a good idea.

Keep HTML in the browser (easier to develop and debug!) and keep backend business logic someplace else.

No you don’t.

> In most cases you must choose a framework for routing. Also a framework for state management.

I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist.

> You also dedicate to duplicating validation and security trimming logic both on the client side and the server side.

I’ve been validating on the frontend for 15 years, long before I worked on an SPA. It has never been necessary but it provides a better experience. If you don’t like this, you can still let the server do all the validation. There is nothing about an SPA that enforces client-side validation. And you’re wasting your time if you’re doing security filtering on the the frontend.

> Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme.

“Grr this paradigm allows me to test my code, I hate it!”. Seriously, we’re now able to write unit tests which were previously impossible. How is this a bad thing? Also Enzyme hasn’t worked since React 17, I now use RTL which asserts user behaviour - super nice.

> Because you have a virtual DOM this is now a security risk.

What?

> You must build a component which duplicates the user interface which already exists.

How is this any different to a non-SPA? Regardless of technology you can’t just arbitrarily lift interfaces from unrelated applications and inject them into your application without a bit of work.

> If the user interface needs to be shared among many applications you must build a commons code base to host your components.

Again, how is this any different from a non-SPA? You UI isn’t going to magically share itself between applications just because you don’t have an SPA.

I’ve worked on all types of applications and I don’t think SPAs should be the defacto approach, but I really feel you’re clutching at straws with all of your arguments.

And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is a 4+ year old $999 Costco special.

Well made React sites can run just fine on devices like that, and Svelte runs even better.

Also SPAs scale better, I remember the days of website backends being slow, with page loads taking forever, massive amounts of HTML being generated server side using slow scripting languages.

Sending a JSON blob of some fields to the browser and having the browser update some nodes makes a lot more sense than the old school way of reloading the entire bloody page to change a couple fields.

https://sqlite.org/np1queryprob.html#the_need_for_over_200_s... talks about this in the context of Fossil, which uses hundreds of queries per page and loads extremely fast.

It turns out the N+1 thing really is only an anti-pattern if you're dealing with significant overhead per query. If you don't need to worry about that you can write code that's much easier to write and maintain just by putting a few SQL queries in a loop!

Related: the N+1 problem is notorious in GraphQL world as one of the reasons building a high performance GraphQL API is really difficult.

With SQLite you don't have to worry about that! I built https://datasette.io/plugins/datasette-graphql on SQLite and was delighted at how well it can handle deeply nested queries.