has_many :through

Shifting to the client again

10 comments — architecture

Comments

1. David Brady – 2012-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.

   ....wheeeeEEEEEEeeee....eeeeeEEEEeeeee....eeeeeEEEEeeeee....eeeeeEEEEeeeee....

2. Josh Susser – 2012-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 Grosenbach – 2012-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 Klaiber – 2012-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 Susser – 2012-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ścicki – 2012-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 Klabnik – 2012-03-16 08:11:50

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

8. Paul D – 2012-03-16 09:30:16

   It's HTML5

9. Allerin - Ruby on Rails – 2012-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 riche – 2012-06-09 10:23:09

    Thanks for this information!