5 ms·

How this goes against the recent Twitter move to return rendering to the server? How to find the right balance of client and server functionality?

Pewpewarrows 14y ago
I've found that the best solution is to _not_ make your website "just another client" of your API. On the initial page load, render the page normally using your server-side templating. Then have your JavaScript introspect the existing DOM and enhance it into a very interactive close to single-page app, using client-side rendering from that point forward. Yes, there's code duplication with templates, and you have to deal with certain peculiarities like implementing a user event queue between the time the page loads and the JavaScript is done hooking into everything so you don't lose user interaction. But those are pains I'm willing to deal with.
- ajacksified 14y ago
  That's a similar technique to what I'm doing; I use language-agnostic templates (mustache) so that I can do a full server side render, and then my Backbone app initializes with bootstrapped data. This way, we can progressively enhance the site and have a quick page load and at the same time build a single page Backbone app.
  - carlosedp 14y ago
    Do you share the same templates between server and backbone? I'm trying to escape code duplication as much as I can. Do anyone knows any pattern to have the server templates sent to backbone avoiding duplication?
    - gerrit 14y ago
      I've been using hogan.js to compile mustache templates to JavaScript functions on the server-side and write them to a js file that is then served to the browser: Templates={} Templates['templatename']=function(){/*compiled template*/} They can then be referenced quite easily in your backbone render methods.
nickfisher 14y ago
Hi Carlos, It was definitely something we thought about, and even discussed with the devs from Twitter. Twitter has a very different use-case to SoundCloud. When you follow a link to Twitter, it's usually to read a single tweet (or maybe a handful), and that's it. SoundCloud is visited by someone who is already willing to invest at least a couple of minutes to listen to a tune, and is much more likely to explore the site. Therefore, the value of making further navigation of the site fast (via client-side rendering, etc) is weighted differently at SoundCloud than at Twitter.
- robmcm 14y ago
  Yes, I don't think instant loading is as high a priority for soundcloud as it is for twitter. Twitter shouldn't be a SPA I don't think, or at least not initially.

Pewpewarrows 14y ago

I've found that the best solution is to _not_ make your website "just another client" of your API. On the initial page load, render the page normally using your server-side templating. Then have your JavaScript introspect the existing DOM and enhance it into a very interactive close to single-page app, using client-side rendering from that point forward. Yes, there's code duplication with templates, and you have to deal with certain peculiarities like implementing a user event queue between the time the page loads and the JavaScript is done hooking into everything so you don't lose user interaction. But those are pains I'm willing to deal with.

ajacksified 14y ago
That's a similar technique to what I'm doing; I use language-agnostic templates (mustache) so that I can do a full server side render, and then my Backbone app initializes with bootstrapped data. This way, we can progressively enhance the site and have a quick page load and at the same time build a single page Backbone app.
- carlosedp 14y ago
  Do you share the same templates between server and backbone? I'm trying to escape code duplication as much as I can. Do anyone knows any pattern to have the server templates sent to backbone avoiding duplication?
  - gerrit 14y ago
    I've been using hogan.js to compile mustache templates to JavaScript functions on the server-side and write them to a js file that is then served to the browser: Templates={} Templates['templatename']=function(){/*compiled template*/} They can then be referenced quite easily in your backbone render methods.

nickfisher 14y ago

Hi Carlos, It was definitely something we thought about, and even discussed with the devs from Twitter. Twitter has a very different use-case to SoundCloud. When you follow a link to Twitter, it's usually to read a single tweet (or maybe a handful), and that's it. SoundCloud is visited by someone who is already willing to invest at least a couple of minutes to listen to a tune, and is much more likely to explore the site. Therefore, the value of making further navigation of the site fast (via client-side rendering, etc) is weighted differently at SoundCloud than at Twitter.

robmcm 14y ago
Yes, I don't think instant loading is as high a priority for soundcloud as it is for twitter. Twitter shouldn't be a SPA I don't think, or at least not initially.