4 ms·

To me, this seems really convoluted - maybe as a non-rails developer I'm missing some key information? Why, for example, would you use this over client-side te

To me, this seems really convoluted - maybe as a non-rails developer I'm missing some key information? Why, for example, would you use this over client-side templating and data-binding? Create the template once, grab some data with AJAX, bind it to the template...

schrodinger 13y ago
Then your initial page hit requires 2 round trips... one to download the page and the javascript, another to get the ajax, and then also a javascript based rendering step. This way, the rendering is done server side so the initial html comes with the first request, and ajax updates are still generated using the same server side code path, just sent back inside of some javascript.
- jakejake 13y ago
  Backbone does in the docs recommend "bootstrapping" your data to eliminate the round-trip to get the initial JSON. I personally don't usually do that myself since the call to the server for JSON doesn't have a significant visual effect (to my eyes anyway). Whereas two different ways of loading data creates more testing and maintenance (on the server as well as the client) Something about sending Javascript from the server seems like mixing up the application layers and creating dependencies that shouldn't' be there. I can see it perhaps if the code that you "own" is 100% on the server. Maybe I'm old school and it's just something that will have to sink in a bit before it makes sense to me.
- Encosia 13y ago
  It's not much work to include the "first page" of data as a JavaScript variable declaration embedded in the response to the initial page hit to avoid that second round trip.
sanderjd 13y ago
I'm a rails developer, and it seems really convoluted to me too. But it seems to work for them and to give them some good performance characteristics. To each their own and all that. I do think that there's a good deal of "splitting" going on in the rails community - I don't feel like I am using the same rails as DHH is talking about in this article - but I'm not sure if it's such a bad thing. It's tricky to pull off two (or more) "stacks" without a lot of configuration, but at least from my point of view, configuration hasn't become a pain point.
twerquie 13y ago
DHH, the author of this post and Rails itself, is and has been actively campaigning against client-side applications, as they clearly undermine his server-side ecosystem.
- rartichoke 13y ago
  He's set for life and rails is his pet project. I really don't think he cares if people move to alternative frameworks. I'm happy they continue to support methods like this though because I REALLY enjoy being able to put up a site that works perfect without javascript, gets crawled by everything and has a fantastic user experience for people with JS without having to worry about duplicating "MVC logic" on both sides, messing around with having to render something in 2 different template languages or add a lot of extra boilerplate. Everything just works and is lightning fast.

schrodinger 13y ago

Then your initial page hit requires 2 round trips... one to download the page and the javascript, another to get the ajax, and then also a javascript based rendering step. This way, the rendering is done server side so the initial html comes with the first request, and ajax updates are still generated using the same server side code path, just sent back inside of some javascript.

jakejake 13y ago
Backbone does in the docs recommend "bootstrapping" your data to eliminate the round-trip to get the initial JSON. I personally don't usually do that myself since the call to the server for JSON doesn't have a significant visual effect (to my eyes anyway). Whereas two different ways of loading data creates more testing and maintenance (on the server as well as the client) Something about sending Javascript from the server seems like mixing up the application layers and creating dependencies that shouldn't' be there. I can see it perhaps if the code that you "own" is 100% on the server. Maybe I'm old school and it's just something that will have to sink in a bit before it makes sense to me.
Encosia 13y ago
It's not much work to include the "first page" of data as a JavaScript variable declaration embedded in the response to the initial page hit to avoid that second round trip.

sanderjd 13y ago

I'm a rails developer, and it seems really convoluted to me too. But it seems to work for them and to give them some good performance characteristics. To each their own and all that. I do think that there's a good deal of "splitting" going on in the rails community - I don't feel like I am using the same rails as DHH is talking about in this article - but I'm not sure if it's such a bad thing. It's tricky to pull off two (or more) "stacks" without a lot of configuration, but at least from my point of view, configuration hasn't become a pain point.

twerquie 13y ago

DHH, the author of this post and Rails itself, is and has been actively campaigning against client-side applications, as they clearly undermine his server-side ecosystem.

rartichoke 13y ago
He's set for life and rails is his pet project. I really don't think he cares if people move to alternative frameworks. I'm happy they continue to support methods like this though because I REALLY enjoy being able to put up a site that works perfect without javascript, gets crawled by everything and has a fantastic user experience for people with JS without having to worry about duplicating "MVC logic" on both sides, messing around with having to render something in 2 different template languages or add a lot of extra boilerplate. Everything just works and is lightning fast.