6 ms·

> Front-end frameworks like backbone.js, as well as advances in web technologies like HTML5's history.pushState are now making server-free views a realistic qua

> Front-end frameworks like backbone.js, as well as advances in web technologies like HTML5's history.pushState are now making server-free views a realistic quality of cutting-edge front-ends. This is not exactly correct. Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too.

riffraff 15y ago
I think there are examples in both directions, facebook and more recently linkedin seem to be have embraced "let's build a page out of many different calls in js", if I am not mistaken.
dmix 15y ago
Those sites aren't using Rails (edit: too heavily) either, which was the basis of comparison in the article. Github/Twitter are massive with millions of visitors... they need to minimize every millisecond. It's not just about choosing the best developer-friendly or cleanest option. Performance is #1. That's not the case for the average smaller apps. Frameworks like Backbone.js and Ember are growing very quicky and every open example app I've seen uses client-side templating.
- EvilTrout 15y ago
  Github absolutely uses Rails. Twitter too, although I understand less so than when they launched.
  - dmix 15y ago
    You're right. I stand corrected. I thought Github had moved away from rails but they seem to be still using it along with lots of erlang/js.
  - lapusta 15y ago
    Main Twitter UI is JS talking to api.twitter.com written in Scala. They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.
nailer 15y ago
> Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too. They had client side templating, and they switched back to server-side? Got any links for that, I'd love to read them (seriously, not snarkily).
- dmix 15y ago
  37signals recently posted about using PJAX and server-side templating to rebuild Basecamp. Theres a counterpoint of linkedin moving towards client side with dust.js: http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates http://engineering.linkedin.com/frontend/leaving-jsps-dust-m... But I'm also interested in hearing about twitter/githubs change of heart.
- scotth 15y ago
  No, they didn't. Pop the inspector's network panel open and watch what happens on Twitter. All the content comes down as JSON.
  - andybak 15y ago
    The claim is that they in the process of switching back, not that it's already rolled out.
    - lapusta 15y ago
      They were switching from hashbang routing to pushstate, not from client to serverside rendering. Although they might to pre-rendering for IE, which will get support of pushstate only in version 10. http://storify.com/timhaines/hashbang-conversation http://storify.com/timhaines/hashbang-conversation
      - andybak 15y ago
        Hopefully they are going with pushState with a fall-back to server rendering for all user agents that don't support pushState. That's a compromise I can get behind. And it's pretty much progressive enhancement...
eagsalazar 15y ago
There are several issues that make moving to a simple json api with all templating and routing on the client still very difficult. 1. Models on the client just aren't there yet. No relations, hacky one-off routing for sync. This is a big deal on more complicated apps where you want to represent multiple collections at once on a page and have nested resources. There are lots of other issues: sync timeouts, server validation failures, authorization, etc that you will have to write yourself. Also, then you are dealing with two different ORM which sucks. 2. i18n. This is basically unsupported on any of the client side frameworks I've seen. Even if it were, if you go partially client and part server rendering then where does your i18n live? You have to go all the way or not at all or deal with the mess. 3. SEO. If you care about SEO on the pages you are loading, you need to render on the server for the initial page load which is a PITA and redundant with client templates. Google is fixing this but their solution creates a different kind of mess. Not such big issues: 1. Browser compatibility. This will fix itself in a year, or two? 2. Performance?? I guess it depends on how you measure performance and where. I think in general it is only the initial page load that is impacted and only the first time with caching. You still have to do a second request for the data itself I guess. Whatever. This is the least of my (and probably most people's) concerns. The reality is, frameworks like Rails have built a lot of supporting features that are necessary and client frameworks like Backbone up to now just don't do everything they need to do. When they do, you'll still have SEO issues. All these problems can and will be resolved one day. I especially look forward to being able to use the exact same models/relations/templates on both the sever and client which hopefully is where some combo of express/node/jade + some client widget library.
- julian37 15y ago
  i18n. This is basically unsupported on any of the client side frameworks I've seen. Even if it were, if you go partially client and part server rendering then where does your i18n live? You have to go all the way or not at all or deal with the mess. Keep i18n strings and templates as JSON or some other format that can be easily parsed by both the client and the server, one for each language. Have both your client and server code use the file corresponding to the user's locale. Could this be easier with better i18n support in today's client-side and server-side frameworks? Most definitely. Is it really that messy? I don't think so. (And yes, I'm aware that not all i18n can be expressed as simple string templates, but those are corner cases that don't add THAT much complexity to the system.)

riffraff 15y ago

I think there are examples in both directions, facebook and more recently linkedin seem to be have embraced "let's build a page out of many different calls in js", if I am not mistaken.

dmix 15y ago

Those sites aren't using Rails (edit: too heavily) either, which was the basis of comparison in the article. Github/Twitter are massive with millions of visitors... they need to minimize every millisecond. It's not just about choosing the best developer-friendly or cleanest option. Performance is #1. That's not the case for the average smaller apps. Frameworks like Backbone.js and Ember are growing very quicky and every open example app I've seen uses client-side templating.

EvilTrout 15y ago
Github absolutely uses Rails. Twitter too, although I understand less so than when they launched.
- dmix 15y ago
  You're right. I stand corrected. I thought Github had moved away from rails but they seem to be still using it along with lots of erlang/js.
- lapusta 15y ago
  Main Twitter UI is JS talking to api.twitter.com written in Scala. They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.

nailer 15y ago

> Many web applications are now foregoing client-side templating and are back to doing it on the server. GitHub is a great example of this, and Twitter is going this route too. They had client side templating, and they switched back to server-side? Got any links for that, I'd love to read them (seriously, not snarkily).

dmix 15y ago
37signals recently posted about using PJAX and server-side templating to rebuild Basecamp. Theres a counterpoint of linkedin moving towards client side with dust.js: http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates http://engineering.linkedin.com/frontend/leaving-jsps-dust-m... But I'm also interested in hearing about twitter/githubs change of heart.
scotth 15y ago
No, they didn't. Pop the inspector's network panel open and watch what happens on Twitter. All the content comes down as JSON.
- andybak 15y ago
  The claim is that they in the process of switching back, not that it's already rolled out.
  - lapusta 15y ago
    They were switching from hashbang routing to pushstate, not from client to serverside rendering. Although they might to pre-rendering for IE, which will get support of pushstate only in version 10. http://storify.com/timhaines/hashbang-conversation http://storify.com/timhaines/hashbang-conversation
    - andybak 15y ago
      Hopefully they are going with pushState with a fall-back to server rendering for all user agents that don't support pushState. That's a compromise I can get behind. And it's pretty much progressive enhancement...

eagsalazar 15y ago

There are several issues that make moving to a simple json api with all templating and routing on the client still very difficult. 1. Models on the client just aren't there yet. No relations, hacky one-off routing for sync. This is a big deal on more complicated apps where you want to represent multiple collections at once on a page and have nested resources. There are lots of other issues: sync timeouts, server validation failures, authorization, etc that you will have to write yourself. Also, then you are dealing with two different ORM which sucks. 2. i18n. This is basically unsupported on any of the client side frameworks I've seen. Even if it were, if you go partially client and part server rendering then where does your i18n live? You have to go all the way or not at all or deal with the mess. 3. SEO. If you care about SEO on the pages you are loading, you need to render on the server for the initial page load which is a PITA and redundant with client templates. Google is fixing this but their solution creates a different kind of mess. Not such big issues: 1. Browser compatibility. This will fix itself in a year, or two? 2. Performance?? I guess it depends on how you measure performance and where. I think in general it is only the initial page load that is impacted and only the first time with caching. You still have to do a second request for the data itself I guess. Whatever. This is the least of my (and probably most people's) concerns. The reality is, frameworks like Rails have built a lot of supporting features that are necessary and client frameworks like Backbone up to now just don't do everything they need to do. When they do, you'll still have SEO issues. All these problems can and will be resolved one day. I especially look forward to being able to use the exact same models/relations/templates on both the sever and client which hopefully is where some combo of express/node/jade + some client widget library.

julian37 15y ago
i18n. This is basically unsupported on any of the client side frameworks I've seen. Even if it were, if you go partially client and part server rendering then where does your i18n live? You have to go all the way or not at all or deal with the mess. Keep i18n strings and templates as JSON or some other format that can be easily parsed by both the client and the server, one for each language. Have both your client and server code use the file corresponding to the user's locale. Could this be easier with better i18n support in today's client-side and server-side frameworks? Most definitely. Is it really that messy? I don't think so. (And yes, I'm aware that not all i18n can be expressed as simple string templates, but those are corner cases that don't add THAT much complexity to the system.)