Missing the Point of Server-side Rendered JavaScript Apps • Hacker News Board

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

#41

Post by azakai » Thu, Feb 05, 2015, 7:40 PM UTC

Touche wrote: post #6

tomdale wrote: post #4

Earlier quoted context omitted.

Typical "progressive enhancement" calls for creating HTML in templates that have no knowledge of the JavaScript, and then using JavaScript to attach behavior to that HTML. The approach described in this blog post builds a JavaScript app from the get-go, and uses a server-side technique to extract standalone HTML from the JavaScript application. The net effect is the same (you get HTML on the client before you execute…

Tom, it's ok to backtrack here. You (and the rest of us) didn't know at the time that progressive enhancement could be possible without making development much more difficult.

I think this might be semantic quibbling at this point.

Yes, progressive enhancement and server-side rendered JS are similar. You can see the latter as a new version of the former. But it is implemented in such a way - a novel way - that it definitely deserves a term of its own.

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

#42

Post by Isofarro » Thu, Feb 05, 2015, 7:41 PM UTC

lhorie wrote: post #32

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

By having the app running on the server it can take advantage of being primed before the first request arrives. Primed in that the app is already running, and/or the data retrieved is cached and regularly refreshed.

Depending on the nature of the application, if it's largely not client personalised (a content site like Bustle, as opposed to a Gmail client), one instance of the app on the server can respond to multiple client requests in it's lifespan. So basically it's an already spun up ready to go instance of the app, or already processed, just needs to squirt the HTML buffer at a response object.

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

#43

Post by pr0gramm » Thu, Feb 05, 2015, 7:43 PM UTC

(Throwaway because I don't want my real name associated with the site)

So here's another perspective. I'm running a highly dynamic site[1] with 8m sessions and 650m pageviews per month. The site runs on a single moderately sized server (4 cores, 16gb RAM) for MySQL and PHP. I can only do this, because I offload everything I can to the client.

The site loads a single 80kb JS file (which also contains all templates) and fires of one AJAX request that gets the requested data. This data is the same for all visitors (for the same resource), so it can be easily cached on the server for a few seconds, before it gets stale.

Everything on this site can be voted (tags, comments, images). These votes are stored client side and synced with the server if needed. This means I can load my canned data from the server and augment it with client data when rendering.

If I were to render it server side, I'd have to create a custom page for each and every user and load the client's votes from the database for each request. This is simply not feasible with the current hardware.

[1] http://pr0gramm.com/

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

#44

Post by Procrastes » Thu, Feb 05, 2015, 7:45 PM UTC

carsongross wrote: post #3

My response to this consists of a library: http://intercoolerjs.org/ Server-side rendered HTML : an idea so crazy... It. Just. Might. Work.

Nice! I'll have to try this out in my next side project.

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

#45

Post by gkelly » Thu, Feb 05, 2015, 7:48 PM UTC

gweinberg wrote: post #25

Well, I freely concede I am still missing the point. You use client-side javascript because that's what runs in the client. Whatever your server-side code does, why would you write it in javascript?

I think the goal is to have FastBoot use your existing client-side javascript app, the idea being that one codebase in one language is simpler and better.

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

#46

Post by scribu » Thu, Feb 05, 2015, 7:54 PM UTC

gweinberg wrote: post #25

Well, I freely concede I am still missing the point. You use client-side javascript because that's what runs in the client. Whatever your server-side code does, why would you write it in javascript?

As the post mentions, the node.js app that servers the initial HTML would be separate from the API server. The code in the API server can, as before, be implemented in whatever language you want.

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

#47

Post by [deleted] » Thu, Feb 05, 2015, 7:55 PM UTC

failed_ideas wrote: post #28

adamnemecek wrote: post #13

Earlier quoted context omitted.

How long ago did you check out Ember?

We removed the last bits 3-4 weeks ago. We started with a pre-1.0, but all the headaches with that are on me, not Ember. I will probably check it out again at a 2.0 or 3.0 release, I love the potential. But for now, it doesn't work for us.

[deleted]

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

#48

Post by Animats » Thu, Feb 05, 2015, 7:57 PM UTC

They're misusing the term "rendered". Rendering is the graphics operation of turning some non-image representation into an image. Server-side rendering would be generating each page as an image and serving that. The article is just talking about fancier template systems for generating HTML. That's what content management systems do - assemble a page out of parts on the server and deliver it to the client.

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

#49

Post by chrisdotcode » Thu, Feb 05, 2015, 8:01 PM UTC

iamstef wrote: post #39

chrisdotcode wrote: post #34

Earlier quoted context omitted.

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

But that's the thing. It's far easier to 'program' a static HTML than any other dynamic alternative.

What people seem to not understand is that the exact same template that they are using on the client renders exactly the same on the server.

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

#50

Post by adamnemecek » Thu, Feb 05, 2015, 8:02 PM UTC

Animats wrote: post #48

They're misusing the term "rendered". Rendering is the graphics operation of turning some non-image representation into an image. Server-side rendering would be generating each page as an image and serving that. The article is just talking about fancier template systems for generating HTML. That's what content management systems do - assemble a page out of parts on the server and deliver it to the client.

Render has been hijacked a bit and AFAIK all (most?) web frameworks refer to HTML generation from templates as 'rendering', e.g. https://docs.djangoproject.com/en/1.7/topics/http/shortcuts/...

http://guides.rubyonrails.org/layouts_and_rendering.html