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

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

#61

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

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…

You don't seem to have that many downvotes right now, but I downvoted you, not because you said there are other ways to program, or even because I disagree with you that we've swung the pendulum too far toward the client, but because your comment seems to willfully ignore everything the article says. Here is what I mean:

> JS Hipsters offloading rendering everything to the client for absolutely no reason

Whether you think the reasons given are good or not, it is inarguable that the article lays out man reasons, so coming back and simply claiming there is no reason is not in good faith.

What's interesting is that the solution described in the article is functionally equivalent to what you think the solution should be, but you still don't seem to like it, presumably because retains the advantages of an approach you dislike.

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

#62

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

The term rendering predates computer graphics by quite a long while. Their usage here is extremely common, and seems perfectly acceptable to me.

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

#63

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

Whatever architecture you use, it all depends on your requirements. Example: If SEO is important, build server side rendering. Period.

Just make sure you provide best user experience possible.

Author claims Bustle is one of the good JS rendered site. If you scroll down http://www.bustle.com/ and click on the item, and if you use back button, you won't be at the same position. This is one of the biggest problem with JS rendered site.

Now compare this to reddit.com. It works great without client side rendering, and not have any issues that most client side rendering sites has.

I am not oppose to JS only app. Problem is, it is hard to build a good JS only app. I do build client only apps.

Hacker news: http://hn.premii.com/

Reddit: http://reddit.premii.com/

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

#64

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

I think if we had to do it over again, a better term would have been "serialize". But this has been a commonly used meaning of "render" for more than a decade now, as it was used by the earliest versions of ruby on rails.

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

#65

Post by krapp » Thu, Feb 05, 2015, 8:56 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…

I think that load balancing is a perfectly legitimate reason to use javascript, particularly if you're on a shared server with limited resources.

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

#66

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

Touche wrote: post #7

I would take it a step further and say that server-rendered JavaScript apps completely changes the game and will have ripple effects throughout the web industry. Here's MercuryJS's example of server rendered app: https://github.com/Raynos/mercury/tree/master/examples/serve... As you can see most of the code is the client-code. All the server code does is run a function and stringify the results. What this means is th…

yes, sure

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

#67

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

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…

You're getting downvoted because you miss the point. You want the web to cater to you, and big companies with infinite resources will, but smaller companies just won't. The cost to support users such as you is just not worth it, you're too small of a segment. People are going to focus their design + resources on the 99% of users who have decided they want the web to work properly.

I mean, shit, lots of startups completely eschew IE support, and they're a way more significant portion of the market than the neckbeards who disable javascript.

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

#68

Post by sanderjd » Thu, Feb 05, 2015, 9:07 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?

Here is an architecture that fits what the article is talking about:

    --------------------------
    | In-browser EmberJS app |------
    --------------------------     |
                |                  |
               HTML (1)            |
                |                  |
  -------------------------------  |
  | Same EmberJS app, running on|  |
  | server, generating HTML     |  |
  -------------------------------  |
                |         ----------
              JSON (2)  JSON (3)
                |         |
  ------------------------------------
  |JSON API server written in, eg. Go|
  ------------------------------------

You don't write any more javascript than you already would have for the client app, and you can write your API server however you want.

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

#69

Post by dsrw » Thu, Feb 05, 2015, 9:08 PM UTC

dredmorbius wrote: post #58

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

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.

In most cases these are separate apps. "Just build it twice!" is necessary in some cases, but is far from idea.

Progressive enhancement is hard, at least for complex interfaces that need to maintain state. Hard enough that many sites, if they support disabling JS at all, do so by writing an entirely new frontend with a simplified feature set.

Ember + Fastboot provides many of the advantages of progressive enhancement, but is far more productive in many cases.

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

#70

Post by sanderjd » Thu, Feb 05, 2015, 9:18 PM UTC

chrisdotcode wrote: post #38

bsimpson wrote: post #35

Earlier quoted context omitted.

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!