Well, it sounds so weird but intriguing. Do you mind telling the rest of the story?

The story would probably make little sense to most HN readers, since it's very old and what was very non-obvious back then, became very obvious 5 years later.

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. :-)

This may be a stupid question, but what does "client/server" mean in this context?

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?

> This may be a stupid question, but what does "client/server" mean in this context?

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.

Without any server-side logic, I suppose user permissions must have been handled entirely by the database, with clients connecting as different database users?

Did row-level security already exist in some databases at that time? Otherwise this must have been quite limiting.

Row level security was usually handled through database views.

There were alternatives to stored procedures for centralization. I remember RPC and CORBA being hot topics around that time. The tiered architecture was a thing before the Web.

I might be totally off the mark here, but in context I assumed the contrast was with doing all work on a thick "client". A client-server architecture in principle lets you run thinner clients and offload the heavy work, but in practice the network would've been expensive.

A modern analogue might be something like premature distributed computing.

If my memory serves me right, distributed computing was the advent of smaller computers (back then often called mini computers like DEC Vax or IBM AS/400, but those were more like smaller mainframes, still using dumb terminals as frontends.

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.

Maybe rather than:

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

I think they mean a dedicated thick client using the OS’s UI framework, rather than a web browser.

Not only the UI, but all of the business logic - so a very thick client indeed.

I've always called these direct database applications. The implication that the client directly connects to the database without the benefit of a middle tier.

Something like Oracle forms with a custom clinet application talking to a database server.

Yeah - kind of, but Oracle forms originally didn’t even have a graphical client - that’s probably why Powerbuilder and Visual Basic dominated the early 90s. Also, Oracle was still fighting it out with Sybase in the mini computer dbms space.

Oracle forms 2.3 & 3 where graphical terminal apps, starting forms 4.0 it also included windows (and X) clients.

Is this related to the "Network Computer" idea that Sun was pushing around that time in the 90s?

https://en.wikipedia.org/wiki/Network_Computer

Doesn't this speak more to the board's astounding foresight than inane projects?

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.