When I was first introduced to the term of client/server in the late 80s, "client" meant PCs and Server meant Database servers. This was an evolution from mini and mainframe computers, where a dumb terminal would basically display what was rendered on the server. There is no local "state" to speak of on a VT-100 or VT-220, and there was a very visible drop-off in application responsiveness when you had too many users of a system and the mini or mainframe was keeping track of the state of those sessions.
The “novel” idea then was, "PCs aren't dumb anymore; let the client keep its own state and let it render the data how it wants and let the server serve up the data, with the only need being the need to maintain a DB session." You ended up at the time with thick client applications which were extremely responsive (and relatively secure because the source of the application wasn't visible for inspection to anyone with a browser), but carried with them the additional administrative demands of distributing and updating those thick clients. When a new version of the software was released, someone had to send all those binaries out to the PCs that needed them. Please note while there was networking back then (why, hello Novell and IBM Token-Ring), but they were all closed networks. Someone somewhere along the way came up with the idea to make the software applications automatically “check in” when they were started to automatically update themselves, and that paradigm still exists with mobile apps (which in their best form are “thick” client applications).
The pattern you describe here is a refinement of that client-server concept, with all the benefits (and drawbacks) of running in a browser.
Benefits:
1. Let the local application render itself, mostly
2.Since the application runs in a browser, it’s mostly cross-platform and there's no (well, very little) OS specific proprietary rendering going on
3. Since the application runs in a browser, it updates itself everytime it's run
4. It doesn't have the initial boostrap costs when run on a brand new machine
Drawbacks:
1. Unless it's a Java app that has a client-side .JAR or the caching stars align, you are downloading the full application codebase every time you start the app in the browser
2. If it's JS, the client-side code can't contain anything you don't want the world to be able to inspect
3. Choose your framework of the day- React, Angular, Vue, Flutter, etc (To be fair, we had the same problem when doing strictly thick clients. Was the path "forward": MFC, VisualAge, IBM ICLUI ,OWL, Zinc, VCL, FMX, Qt, Swing- I've worked with all of those at one point or another over the years-of which VCL was the best, by far, which is probably why Microsoft promplty hired the VCL designer away from Borland).
In any case, it’s fascinating that there is very little that's new in the world; just "improved" upon concepts that have continually evolved.
