Well, it sounds so weird but intriguing. Do you mind telling the rest of the story?
Around 1994/95 client/server was unassailable in board rooms (much like AI is now). And after initially speaking up against it, I ended up shutting up about my criticism of that architectural approach, since it would have just gotten me fired.
So I ended up sneaking some early Internet technologies into a big client/server project I managed. Doing that ended up benefiting those developers in future jobs, and the company, because they didn't have to re-write that part so quickly. :-)
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...
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.
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.
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.
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.
Took two days for two of us to install it on five or six client PC's
I recall discussing this with the engineering centre manager about how in 5 -10 years the web could replace fat clients on PC's
SCCS ftw!
I would interpret it to mean any networked or Internet-based application that has both client- and server-side logic, which obviously isn't anything special in 2020, but it sounds like you're referring to something else that would now be considered outdated?
A modern analogue might be something like premature distributed computing.
A modern analogue might be something like premature distributed computing
A modern analogue might be n, where n is more familiar to the composer of this, or, the source of information determining the production of this text is most familiar with n, where n does not include the word premature
But you’re right in saying that the original client/server had all of the UI and business logic on a very fat client - and the server only served the data over very low bandwith networks.
Not a stupid question at all, since terminology has been shifting over the decades.
Back in the early 1990s, the original client/server generally meant all application code (logic and UI) on the client computer, and all the data on the server. So a very fat client.
Database stored procedures (i.e. some logic on the server) only arrived on the scene later during that time, because the original architecture of all code on the client caused performance nightmares. But don’t get me started on the trials and tribulations of early stored procedures. They often caused more project turmoil rather than smoothen things out. — Partly because they weren’t good languages yet, partly because of amplifying developer vs. dba conflicts.
Did row-level security already exist in some databases at that time? Otherwise this must have been quite limiting.