Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.
The small projects are where the people I care about are struggling.
Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.
And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
It's almost impossible. The first reaction is always `npm init`
e.g. WhatsApp back before the acquisition
Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.
However I'm taking about even lower down the food chain than this.
something like this: https://www.hotelpalacebarcelona.com/
they don't care it's not "html first"
I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.
If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.
The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.
Just like the original article, you might want to test your assumptions a bit more.
For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.
Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.
While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.
The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.
The big projects are of course important. But even chrome needs a simple little website with a download link.
> I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks.
I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality.
Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.
