Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Missing the Point of Server-side Rendered JavaScript Apps

tomdale.net

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Missing the Point of Server-side Rendered JavaScript Apps

#31

Post by chrisdotcode »

iamstef wrote: post #27
chrisdotcode wrote: post #14

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. Render content on the server, enhance content presentation on the client. --- I don't get it. Is this 1996? Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? > All modern websites, even server-rendered ones, need JavaScript. There is j…

> 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…

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.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#32

Post by lhorie »

> If it needs to fetch data from your API server to render, so long as both servers are in the same data center, latency should be very low

Maybe I'm just missing something obvious, but wouldn't FastBoot make things slower if it needs to go hit the database to produce the static page, and then the clients hits the server again to fetch the unrendered templates and data as part of Ember's normal bootstrapping? I don't think it's that uncommon for the database to be a bigger bottleneck than the network.

Are there any benefits over, say, slapping a screenshot of the page as the background of body? (yes, I know I'm oversimplifying, but for instance, Facebook loads up wireframy graphics as placeholders until ajaxed stuff pops up.)

Re: Missing the Point of Server-side Rendered JavaScript Apps

#33

Post by iamstef »

chrisdotcode wrote: post #31
iamstef wrote: post #27

Earlier quoted context omitted.

> 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…

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 li…

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.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#34

Post by chrisdotcode »

mixonic wrote: post #30
chrisdotcode wrote: post #14

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. Render content on the server, enhance content presentation on the client. --- I don't get it. Is this 1996? Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? > All modern websites, even server-rendered ones, need JavaScript. There is j…

Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server. Look, saying "client-side JS apps are damn fast" is a vague statement. What we are talking about here is the architecture of a client-side application in any language. If you can ship applica…

> Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime.

It does? Why? The server is handling the data to be rendered either way, and as I say in response to another comment, rendering the data is as simple as:

    res.end(render(template, data))
> And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".

The argument is "you are VC-funded, and taking a 1mil+ dollars to build the Next Big (S|P)aaS. You are spending tons of money on A/B testing, designers, mockups, UI specialists, and your page does not even load for the lowest common denominator - and easiest to manage (static HTML) users of the web?"

The web was built for content-first, not flash.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#35

Post by bsimpson »

chrisdotcode wrote: post #31
iamstef wrote: post #27

Earlier quoted context omitted.

> 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…

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 li…

That's…exactly what the article is advocating.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#36

Post by chrisdotcode »

iamstef wrote: post #33
chrisdotcode wrote: post #31

Earlier quoted context omitted.

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 li…

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…

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.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#37

Post by azakai »

chrisdotcode wrote: post #22
azakai wrote: post #21

Earlier quoted context omitted.

> GMail, and probably others [..] All of which are big names that can and do work ENTIRELY without JavaScript. Gmail uses massive amounts of client-side JavaScript (perhaps compiled from a different language, of course).

There's an option for the basic HTML layout available if you have JS disabled. That's the second-best approach. The first is using a JS-redirect to the flashy AJAX page, or just overriding all the default handlers necessary with JavaScript (remember, at this point, your content was already (supposed to be) properly rendered for you by the server).

Sure, there is an option for a no-JS version of Gmail, but the default definitely uses Gmail, because the user experience is much better - I think that's pretty clear.

I agree doing some work on the server can also make sense, and that the new pre-rendered JS is an extension of progressive rendering which is not a new technique. It's a new way of doing it, though.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#38

Post by chrisdotcode »

bsimpson wrote: post #35
chrisdotcode wrote: post #31

Earlier quoted context omitted.

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 li…

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.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#39

Post by iamstef »

chrisdotcode wrote: post #34
mixonic wrote: post #30

Earlier quoted context omitted.

Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server. Look, saying "client-side JS apps are damn fast" is a vague statement. What we are talking about here is the architecture of a client-side application in any language. If you can ship applica…

> Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. It does? Why? The server is handling the data to be rendered either way, and as I say in response to another comment, rendering the data is as simple as: res.end(render(template, data)) > And your comments about shitty execution of web pages and apps could apply…

My experiences may be biased, but most startups I work with have target audiences that do not include tin-foil hatted JavaScript disabling individuals.

To the contrary, for them investing any energy in servicing this minority would be a mistake.

I suspect their exists some subset of startups were this may be reversed. But they are absolutely in the minority.

Re: Missing the Point of Server-side Rendered JavaScript Apps

#40

Post by dsp1234 »

mixonic wrote: post #30
chrisdotcode wrote: post #14

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. Render content on the server, enhance content presentation on the client. --- I don't get it. Is this 1996? Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable? > All modern websites, even server-rendered ones, need JavaScript. There is j…

Linode, Amazon, and Google all absolutely use JavaScript. Tom isn't saying that they use JavaScript on the server, he is suggesting that JavaScript is involved with their website despite using a different language on the server. Look, saying "client-side JS apps are damn fast" is a vague statement. What we are talking about here is the architecture of a client-side application in any language. If you can ship applica…

(including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript.

Gmail has an html/css only interface that uses no javascript. I use it every day, and everything just works. Additionally, on my device it's much snappier even with full page refreshes. This rebuts the original assertion that "All modern websites, even server-rendered ones, need JavaScript.".

Post reply on HN