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

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

#51

Post by mst » Thu, Feb 05, 2015, 8:03 PM UTC

tomdale wrote: post #9

supporting wrote: post #5

You gotta love the Orwellian naming on this one. "Ember FastBoot" meaning Ember-we've-been-selling-you-very-slow-booting-for-years-and-now-we're-hoping-to-mitigate-it-slightly-but-it's-still-vaporware. Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at…

I don't want to get into a big discussion on small libraries vs. big frameworks (your use of the word "bloat" gives away your position here ;). I would ask readers of this discussion to visit any of the web applications they use on a daily basis, open the developer tools, and look at the size of the JavaScript payload. Whatever libraries or frameworks they're using, the payload size is almost always several hundred k…

I'd like to stand up and be counted as saying that both

1. Ember absolutely isn't to my taste and I've successfully avoided it so far and intend to continue doing so in future

2. The work you're doing is really cool and I'm looking forward to seeing it completed, both for the benefit of my friends with different tastes who're happily using ember and for the benefit of everybody else in that it provides a worked example of an awesome idea.

(and people who dislike it just because they dislike ember might, possibly, need to remember that trailblazing is important for new ideas)

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

#52

Post by lhorie » Thu, Feb 05, 2015, 8:04 PM UTC

Isofarro wrote: post #42

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

Really? I'd imagine most Ember projects are more like Gmail than Bustle (in the sense that they probably have at least login). If even a single byte of the payload changes, you're looking at O(n=users) instances and then you're potentially back at the problem of having the db hit happen before the first pixel on screen.

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

#53

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

Isofarro wrote: post #2

So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors. Sounds like Progressive enhancement [1]. [1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/

Hah! I'm glad others have seen we've come full circle again :)

As a developer of isomorphic (there's another term to pick apart!) React apps, I'm thrilled Ember and others are reaching the same conclusions on why server-side rendering is crucial.

I'll still call it Progressive Enhancement, since a server-generated response is "enhanced" with client-side functionally that still functions for those with it disabled.

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

#54

Post by smacktoward » Thu, Feb 05, 2015, 8:15 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?

Because writing an app in one language is easier than writing it in two or more, and since JavaScript is the only language you can do client-side scripting in you're probably going to be writing some JavaScript no matter what. So if you want the ease of writing your whole app in one language, the only language that one language can possibly be is JavaScript.

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

#55

Post by CGamesPlay » Thu, Feb 05, 2015, 8:16 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.

Good for the simplest of "rich" interactions, but quickly drops off when responsiveness becomes a factor. For example, you cannot implement optimistic responses using this library (click the "save todo" button and the saved item immediately appear in its read-only interface; this interaction requires reimplementing your templating library and validation code on the client and the server).

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

#56

Post by Twirrim » Thu, Feb 05, 2015, 8:19 PM UTC

pr0gramm wrote: post #43

(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) an…

It's worth noting that while that's OK for desktop visitors, shifting the workflow to the client means you're putting a lot more stress on mobile visitors and resulting in a worse experience for them.

Network performance and latency is all over the place, leaving AJAX an unpredictable mess. On top of that you're adding the overhead of spinning up the javascript runtime on the phone, running the code etc. etc, all of which eats precious battery time for them, and negatively impacts your time to screen, a very important metric.

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

#57

Post by ac2u » Thu, Feb 05, 2015, 8:24 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.

It's not really useful for the conversation to lump it in with the traditional definition of progressive enhancement that's been done for years.

Even middle of the road efforts I tried a few years ago (such as sharing a templating language between client and server even when the implmentation language differs) was fraught with friction compared to this technique.

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

#58

Post by dredmorbius » Thu, Feb 05, 2015, 8:25 PM UTC

azakai wrote: post #21

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…

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

What you've failed to grasp, twice, is that these sites do have javascript-free versions. Which work.

Not that they don't also have JS-infested versions. Which also sometimes work.

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

#59

Post by ac2u » Thu, Feb 05, 2015, 8:36 PM UTC

chrisdotcode wrote: post #36

iamstef wrote: post #33

Earlier quoted context omitted.

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.

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.

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

#60

Post by dsrw » Thu, Feb 05, 2015, 8:45 PM UTC

dsp1234 wrote: post #40

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…

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

This is an entirely different frontend that was added years after Gmail launched. The interface that most of us use absolutely won't function without JavaScript.

Adding a pure html view to a mature, profitable application to appeal to a niche audience probably makes sense. Building it that way from the start probably doesn't.