Shifting to the client again

— March 15, 2012 at 16:33 PDT

This is my take on the current shift to rich, in-browser JavaScript apps.

Looking back over a few decades, this is the progression of how applications have been built:

  1. mainframes and dumb terminals
  2. minicomputers and smart terminals
  3. networked workstations
  4. workstations and shared code/data repositories
  5. web apps and static HTML
  6. web services and rich browser apps

Translation: The main body of the application code lives on the:

  1. server
  2. server + client
  3. client
  4. server + client
  5. server
  6. server + client

The server/client pendulum swings back and forth. The next logical step is apps that run on the client using standard services. Just give it a few more years...

10 commentsarchitecture

  1. David Brady2012-03-15 16:46:58

    I don't think it'll be a few more years. It's upon us already. It stuttered in the form of Flex/Flash, but it's back in the form of backbone and spine and Ember... and this time with the broader platform of HTML5 and CSS3 I think it's just a matter of adoption.


  2. Josh Susser2012-03-15 16:55:55

    David, I agree it's heading there, but mostly the current rich client apps talk to custom web services. That is, you have to write code for both the client and the server. I expect there will be some standardization that lets the client code have all the custom logic. Think of a client app that can shove JavaScript into CouchDB for doing clever processing on the back end. Nathan Sobo took a crack at this with Unison, but we've still a way to go before there is real support for building apps that way.

  3. Geoffrey Grosenbach2012-03-15 18:13:12

    Dave Thomas covered this same idea in his RubyConf keynote in 2008.

    Isn't the real issue the capabilities of clients rather than the desired design of applications? Early dumb terminals couldn't run applications, and early browsers weren't capable of running full featured JavaScript applications. Rich clients in the browser were barely possible until now.

  4. Nate Klaiber2012-03-15 20:39:42

    The interesting part I see, is that the same Web Standards™ folk who despised flash, are now the ones supporting rich client apps with JavaScript. JavaScript apps still fail at the things they moaned about with Flash (accessibility, re-inventing UI, browser controls and settings, etc), but somehow now it's justified.

    It will be interesting to see how it evolves and plays out. I think the 'smart apps' are getting dumber, but developers want to be clever, so it's OK. I also see a lot of ecosystem bubbles.

    As you state, the core has always been the client + server. To me, it's a balance of the two in the given context (the browser). I think the playing field is widened when you have exposed API's - but we are still living in browsers, and we have to work within our constraints. Otherwise, we are no better than the browser wars and wild west - no matter how badly we want to justify the cleverness (or, new and shiny).

  5. Josh Susser2012-03-15 22:56:22

    Geoffrey, I think you're right about that, or at least to some extent. I didn't even try to address the reasons for why there has been a pattern of back-and-forth between client and server, but I agree it's significantly because of technological constraints, and probably also economic ones. On the other hand, there's probably some kind of chicken-and-egg thing going on where the capabilities of the client (or server) didn't get pushed forward until someone thought of a good reason for doing so.

  6. Paweł Gościcki2012-03-16 02:57:27

    There's also Tower.js which promises to bridge the gap between server and client - i.e. you write your code once (in cs) and it is executed both on the server and on the client.

  7. Steve Klabnik2012-03-16 08:11:50

    Nate, it's because Javascript isn't proprietary.

  8. Paul D2012-03-16 09:30:16

    It's HTML5

  9. Allerin - Ruby on Rails2012-04-30 05:00:08

    Yes, you are right it will take some more time for implementation of inbuilt Java Script Apps because we are still using client server synchronization methodologies and so far we do not have any other technique to bring this hot cake in market.

  10. comment devenir riche2012-06-09 10:23:09

    Thanks for this information!

Add Comment

Comments are styled using Markdown.