[jimsmart]

> GWT had a place back when the frontend capabilities of browsers were very very badly balkanized and pathetic.

Everything that GWT did, frontend-wise, could be done just fine in any of the 'pathetic' browsers back then. Frontend capabilities of browsers were pretty good, if you knew what you were doing. (After all, GWT ran on top of that exact tech)

GWT's USP was that it enabled Java programmer's to build browser-based frontends, and not worry about HTML/CSS/JS. In theory at least — in practise: you'd eventually meet the edge of what GWT could do, the shit would hit the fan, and then you'd have to jump through hoops to e.g. integrate some JS library.

> server-side rendering, like bellbottoms is trendy again!

Modern server-side rendering actually still serves a modern JS SPA, with the exception that it hydrates (pre-populates with data/etc and renders) the page it serves.

— Your bellbottoms might look about the same at first glance, but it's a long way from being a simple apples-to-apples comparison.

> React? and in the few weeks you spend learning it, the entire javascript ecosystem has moved onto a new micropackage manager.

I've built apps for big clients using React (and SSR, FWIW). You pick your package manager and build system at the start of the project, and then you generally stick with it until (well after) the end of the project.

Tech always changes.

But for many big projects, you stick your stake in the ground, and work with that — it's a fool's errand to try and keep updating a real-world project to always use this week/month's fashion, and no decent management should even entertain the thought.

Doesn't mean you can't build a project on pretty recent versions of s/w though (e.g. React). Upgrades and changes to systems (e.g. package managers, build systems) should be managed properly, not chased like some primary goal of s/w development.

[bzzzt]

> I've built apps for big clients using React (and SSR, FWIW). You pick your package manager and build system at the start of the project, and then you generally stick with it until (well after) the end of the project.

Those big clients throw away their software at the end of the project? That's what bugs me about Javascript: the Java/.NET/PHP server-side rendered applications from 10 years ago can be moved forward. Not painless, but if you want you can adapt them to run on a modern stack while with Javascript frameworks from 10 years ago you mostly have to start over.

[jimsmart]

> Those big clients throw away their software at the end of the project?

Nope. Not at all. They're still in use, and still being further developed. None of it's been thrown away. Some things have been updated over time (in a managed way, e.g. newer React versions, updated build system, extra/better build-time tooling). New features have been added to the software. No problem hiring devs to do the work, React is a known quantity. The back-ends are a known quantity. All the apps are still a fairly modern stack: from front to back. No problem moving them forwards and implementing any of the things the customer/management wish for. All pretty painless.

— Some of the apps I refer to here were in fact a start-over from exactly what you describe, because that simply wasn't working out (for various different reasons on different apps, but one reason was the UI wasn't working as folk expected it to, in some cases wasn't responsive enough, etc).

Some apps are simply best done as a SPA. Horses for courses, innit. It's just a different kind of software development at the end of the day. It's not necessarily any less manageable to use React/similar in one's project(s). And we chose React because of what it brings to the table plus we could clearly see it would be well supported for some time into the future. — In fact we found React (plus the appropriate libraries) permitted very fast development / iteration, particularly compared to when one reaches the edge of what can comfortably be done using pure server-side rendering, and/or SSR plus 'spot' Javascript usage.