Comment by iamstef | Hacker News Reader

Comment by iamstef | Hacker News Reader

Parent Full thread

> Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript.

I think we can all agree, maintaining two discrete code-bases is a sub-optimal experience. Especially for companies without the resource of the "big names" you point out.

> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast?

Several reason why this experience results in a faster mobile experience.

- cached data serves extremely quickly ;) - pre-emptively loading data to prime the cache. - data is smaller then data + html. - the app remains usable during loading phases.

Additionally, separating the concerns of rendering and data loading, does afford more creative optimizations as the need arises.

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.

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.

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.

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.

That's…exactly what the article is advocating.

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.

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!

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.

Reply on news.ycombinator.com