Somehow PC Mag seems like the best reference here: https://www.pcmag.com/encyclopedia/term/clientserver

It’s hard to see the hype up close sometimes. The closest analogy I can think of and it’s an older one might be how in the mid-2000s everyone needed to make a “Web 2.0 mash-up” or how for awhile everyone needed “social” (remember Ping?)... if you were stuck with a stack based on jQuery and global variables, good luck transitioning to React without Facebook’s scale. Sometimes all you can do is try to stay organized, see a project through and hope it can evolve to something greater after the fad wears off...

The PC Mag article seems mostly pretty accurate - however, I’d argue that the web isn’t classic client/server, since the server sends the code to the client just in time. Classic client/server had a totally different code deployment mechanism. It was a full app installation every time - often via sneaker network, since few corporate networks had enough bandwidth to deploy new apps over their network. And installation software infrastructure was almost non-existent. Version control systems? Seldom. Netscape was one of the very first apps that was entirely network delivered at really large scale.

If I had to describe the web to a time traveller from the 1980s, I might say the modern web browser is something like a super smart and capable 3270 terminal, while the cloud is the mainframe.

I remember just before my first web project. I worked on a Oracle client server project (SMDS management tool) and to install the client, you installed about 4 products via 14 floppy disks one after the other on the client PC.

Took two days for two of us to install it on five or six client PC's

So you can probably imagine what it was like when we had several dozens of client pc’s across several customer companies across several cities across the continent.

Oh yes in 94 that was my key take away, you could launch a new system as a website and save a lot on deployment cots on say 500 seats.

I recall discussing this with the engineering centre manager about how in 5 -10 years the web could replace fat clients on PC's

> Version control systems? Seldom.

SCCS ftw!

> if you were stuck with a stack based on jQuery and global variables, good luck transitioning to React without Facebook’s scale.

My team is doing exactly this on my initiative and seeing some positive effects already, even though we're only like 2% of the way there. Would you mind expanding on what you think is futile about it? I wouldn't want to be the one advocating something that with hindsight will look obviously stupid.

Well, leaving aside the React vs Web Components debate, the only issue is that some folks add technologies like React but forget to remove the old ones as they go. They half-finish the job. Then they do that up to 5 times more...

My advice would be to try to refactor the jQuery app to reduce global state first. For example, use ASTs and other techniques to programmatically determine what global state is used where. Think of it not as “porting” to React, but more as ‘re-writing in React” — the sooner you can finish the rewrite, the better. Take it in smaller, thin, but global (across the whole app) steps, and work to break the app dependencies back down to separate components — this is especially true for CSS, which historically has been global by design for much of its life...

If shipping during a rewrite, make sure you have some very basic tests running. Try to implementation-agnostically look for and click text or otherwise use the web app in your tests, then run the tests before and after making widespread changes... Use screenshots from the tests to quickly visually scan for errors. Pay attention to errors in browser consoles also, if not using TypeScript to its fullest yet.

There's loads written on re-writes.

I may be misreading them, but GP seems to be doing the re-write in the recommended way, small chunks at a time. I think the advice cautioning against wholesale replacement re-writes is sound, but piecemeal transition is much more achievable. I think it took about 5 years to transition Wayfair from asp to PHP one page/system/scheduled task at a time, but the result was a working system at all times that improved with the re-write. Not that I have any love for PHP, but (Classic) asp was even worse. (I can’t speak to asp.net, never used it.)

Asp.net Core is fantastic. ASp.net is ok but not as good.

Asp.net Core is cross platform, has a self hosted https server called Kestrel that is insanely fast, has a really sensible composition of middleware, built in DI, and a strong community. Hangfire is a great job runner, signalr is available with real-time push over web sockets, identity server 4 can handle all your Authn/Authz and Entity Framework Core + Linq is very powerful and a lot faster than the full framework version.

Cool, very good info thank you! I’ve heard great things about .net core but never had the pleasure of using it yet. I would love to play with F#!

I think he's saying the "foresight parts" were his initiatives, not the board's, and the board's part in it all had to be scrapped sooner rather than later while his initiatives did not.