[quanticle]

So, in other words, the web is rediscovering client/server programming. Welcome to 1990, everyone!

More seriously, though, I think a lot of the reason for the historical tendency towards server side rendering has been:

* Clients were slow: remember, until V8 raised the standard for speed, Javascript VMs were slow. So doing a lot of rendering or data processing in Javascript was a bad idea, since it negatively affected the user's experience with their entire computer, not just your site.

* DOM Manipulation is hard and inconsistent between browsers: Yes, JQuery and friends hide the native DOM API. But we have to remember that it wasn't always the case. Rich client-side libraries are all quite young, comparitively.

* Offline capabilites were non-existent: Even today, the HTML5 specification, as implemented, only grants you a fraction of the data storage and retrieval capabilities available to even the most sandboxed application. And previously, these capabilities simply weren't there - if your app needed to store data, it had to store data server side and tag the client with a cookie or some other for identification to keep track of which data belonged to whom.

Yes, there is progress being made on all three fronts, but you can't expect developers to throw away years of best practices in a day, then immediately turn around and write HTML5 webapps. I think the evolution towards a more balanced computing model (where more of the computational load is being handled by the client) is ongoing, and will accelerate as browsers become more capable.

[roel_v]

It's also a change in mindset in the 'developer community'. Up until let's say 5 years ago, Javascript was considered plain dirty. Javascript was a non-portable hack that was only to be touched in the most extreme circumstances. Websites that didn't work on Lynx were reviled. Oh how things have changed, and yet have stayed the same at that same time (i.e., your 'welcome to 1990' comment).

On a related note, the last couple of weeks I've been working on rewriting an old (2000-era) web app, originally written in Visual Interdev. Visual Interdev was widely derided back then, it was something only Visual Basic 'programmers' (the chaff of the programming community) would touch. Turns out that many things it did are a lot more popular nowadays - client side calculations, validation, dynamically updating the UI, etc. Of course there was no XMLHttpRequest, so by modern standards it was quite limited; still, it's funny how something so derided back then just turned out to be ahead of its time.

[brusch]

I once read a book about MFC (Microsoft foundation classes) programming in Windows. This book had some web programming chapters, and one of them was DTHML (dynamic HTML) how it was called then. The author even said "Silly HTML" to it (it makes more sense in German, because silly starts with a "d" in German) and said that this is absolutely worthless, cause it will never work in more than one browser.

These were the days. Funny how some things change and "silly ideas" are all the rage.

[wslh]

> Funny how some things change and "silly ideas" are all the rage.

This is because of the adoption of the technology and its evolution. It is not just the technology per se.

If a tree falls in the forest and no one is around to hear it does it make a sound?

[sebastianconcpt]

Is not strictly client/server, not at least in the sense of thin clients. I think of it as software that also takes advantage of the network (by using its internal client to interact with the server).

What we are really discovering here is that we can do software that uses the (big) network.

The opportunity is in that, differently from the past, this time we suck less at the UX design.

[diminish]

Younger developers appear to reject their senior colleagues's way of doing things and prefer their grand-senior colleaguues' way. That reminds me Structure of Scientific Revolutions from Thomas Kuhn where scientific developments only occur when an older generation passes away.

[asadotzler]

"remember, until V8 raised the standard for speed, Javascript VMs were slow."

Actually, it was Apple, not Google, that kicked off the JS performance wars. Apple and Mozilla were deep into JIT tech before anyone knew about the existence of Chrome.