5 ms·

As I've said, > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaul

As I've said, > The solution is very simple: render all the data on the server, and progressively enhance subsets of your app with JS, by overriding the defaults of the rendered page. It's literally like we're discovering DHTML all over again. Client.js, rendered on the client: render(template, data) Server.js, rendered on the server: render(template, data) --- They're exactly the same. You use a templating engine library for either JS, or your server language to process the same data. What client.js should do is change things dynamically, progressively.

iamstef 12y ago
One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state. As the complexity increases, this problem explodes. One can use local storage (when available), but unfortunately this isn't always available, or needed. Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare. It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI. Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.
- chrisdotcode 12y ago
  I agree. This is the progressive enhancement I've talked about earlier. Present a long, full form for JS-less users, and present it all nice-ified for those with, and send it off for server processing when you're done.
  - ac2u 12y ago
    I think you're simplifying too much in order to make a point. And I've no doubt your point is valid in a lot of cases. However, this idea of a template rendered on the server and then the same template on the client is often fraught with difficulties the more interactive your application gets. It gets more complicated when you want to 'componetize' your javascript. A couple of years ago to do that I would have brought in something like backbone. "I know!" I thought, "I'll switch my templating to mustache, which has a parser in both ruby and javascript. Then I'll have ruby render the page with mustache using a ruby hash. Subsquent AJAX updates then pull down JSON in the same shape and I'll have Backbone use that same mustache template to render it! That way I can send the HTML down from the server pre-rendered for speed and SEO and then progressively enhance!" All great in theory, but then I had to build awareness into my components so that they could be instantiated without a pre-existing representation built by the server or attached to a pre-rendered version made in Ruby. (You don't want to only make a component that NEEDs a real DOM to be tested do you?) So while I agree your advice is great for forms, I've found real world cases of highly interactive applications where it reaches its limits. And the proper progressive enhancement we need is only coming now thanks to efforts like this and isomorphic react applications.
bsimpson 12y ago
That's…exactly what the article is advocating.
- chrisdotcode 12y ago
  I'm not bashing the article - I'm referring to the mindset necessary for the fact that this article even needed to be created. Server-side rendering should have always been first-class.
  - sanderjd 12y ago
    What you're missing is the whole part of the article that talks about why many people migrated to that mindset. You are dismissing the problems out of hand, as unimportant and easy to work around, which is frustrating for the many of us who changed our mindsets in search of a better solution to those problems, which client-side-heavy apps absolutely are. But the better solution had trade-offs; it spoke to many real problems with the fully server-side rendered approach, but caused new problems. Now we're starting to find solutions to those new problems without giving up the entire approach. That's a good thing. Your comments don't seem to argue that it's a good thing, but rather that the whole endeavor has been folly, which, for many people, just isn't true!
    - chrisdotcode 12y ago
      The oft-touted claim is that client-side templating is easier, but they're the same, really. The server solution is literally using the same exact templating engine and code. What people are conflating is "doing things in the client with JavaScript" and "rendering templates in JavaScript", which are two entirely different domains. You can't access many cool features client-side without JavaScript, full stop. But rendering things on the client, and presenting an absolutely un-usable design without turning-completeness is not content-first design.

iamstef 12y ago

One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state. As the complexity increases, this problem explodes. One can use local storage (when available), but unfortunately this isn't always available, or needed. Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare. It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI. Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.

chrisdotcode 12y ago
I agree. This is the progressive enhancement I've talked about earlier. Present a long, full form for JS-less users, and present it all nice-ified for those with, and send it off for server processing when you're done.
- ac2u 12y ago
  I think you're simplifying too much in order to make a point. And I've no doubt your point is valid in a lot of cases. However, this idea of a template rendered on the server and then the same template on the client is often fraught with difficulties the more interactive your application gets. It gets more complicated when you want to 'componetize' your javascript. A couple of years ago to do that I would have brought in something like backbone. "I know!" I thought, "I'll switch my templating to mustache, which has a parser in both ruby and javascript. Then I'll have ruby render the page with mustache using a ruby hash. Subsquent AJAX updates then pull down JSON in the same shape and I'll have Backbone use that same mustache template to render it! That way I can send the HTML down from the server pre-rendered for speed and SEO and then progressively enhance!" All great in theory, but then I had to build awareness into my components so that they could be instantiated without a pre-existing representation built by the server or attached to a pre-rendered version made in Ruby. (You don't want to only make a component that NEEDs a real DOM to be tested do you?) So while I agree your advice is great for forms, I've found real world cases of highly interactive applications where it reaches its limits. And the proper progressive enhancement we need is only coming now thanks to efforts like this and isomorphic react applications.

bsimpson 12y ago

That's…exactly what the article is advocating.

chrisdotcode 12y ago
I'm not bashing the article - I'm referring to the mindset necessary for the fact that this article even needed to be created. Server-side rendering should have always been first-class.
- sanderjd 12y ago
  What you're missing is the whole part of the article that talks about why many people migrated to that mindset. You are dismissing the problems out of hand, as unimportant and easy to work around, which is frustrating for the many of us who changed our mindsets in search of a better solution to those problems, which client-side-heavy apps absolutely are. But the better solution had trade-offs; it spoke to many real problems with the fully server-side rendered approach, but caused new problems. Now we're starting to find solutions to those new problems without giving up the entire approach. That's a good thing. Your comments don't seem to argue that it's a good thing, but rather that the whole endeavor has been folly, which, for many people, just isn't true!
  - chrisdotcode 12y ago
    The oft-touted claim is that client-side templating is easier, but they're the same, really. The server solution is literally using the same exact templating engine and code. What people are conflating is "doing things in the client with JavaScript" and "rendering templates in JavaScript", which are two entirely different domains. You can't access many cool features client-side without JavaScript, full stop. But rendering things on the client, and presenting an absolutely un-usable design without turning-completeness is not content-first design.