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

21–30 of 79 posts

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

#21

Post by azakai »

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

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

#22

Post by chrisdotcode »

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

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

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

#23

Post by ta_75000 »

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…

> Why are people just now 'discovering' that you don't need to throw JS at an application to have it completely usable?

I think a new generation of developers for whom the web has always been, essentially, a rich and dynamic applications platform is 'rediscovering' that it's really just document markup with Turing completeness on the side.

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

#24

Post by failed_ideas »

azakai wrote: post #19
failed_ideas wrote: post #10

I don't think anyone is missing the point at all. I fully understand what you're attempting to do because I tried to implement an Ember project only to have so many negatives pile up that it was actively working against our goals. I really wanted to like Ember, but even with those issues aside, the two most common comments on out team about Ember were "Wait, why is that working?" and "I didn't change anything, why is…

> I don't think anyone is missing the point at all. Perhaps you are not, but "anyone"? The article quotes 2 tweets that disagree with the point, and I've heard it misunderstood on internet comments. Perhaps it's not a common misunderstanding, or perhaps it is - it's hard to tell with anecdotes. Regardless, it's worth clarifying, as the author of the post did.

Absolutely, you are 100% correct. I definitely misspoke.

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

#26

Post by carsongross »

Scaevolus wrote: post #11
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.

I like the simplicity. How does this handle CSRF tokens?

It looks for the standard meta CSRF meta tag, it will include it if the request is within a form with a CSRF hidden input, and you can hook in via the usual jQuery AJAX hooks if you are doing something else.

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

#27

Post by iamstef »

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

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

#28

Post by failed_ideas »

adamnemecek wrote: post #13
failed_ideas wrote: post #10

I don't think anyone is missing the point at all. I fully understand what you're attempting to do because I tried to implement an Ember project only to have so many negatives pile up that it was actively working against our goals. I really wanted to like Ember, but even with those issues aside, the two most common comments on out team about Ember were "Wait, why is that working?" and "I didn't change anything, why is…

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.

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

#29

Post by jjbiotech »

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…

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

Very large generalization, it depends on the specifics of an implementation. Plus this isn't as scaleable since you're consuming CPU cycles rendering views on the server.

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

So you're telling me to write a web app that consists of: A Server-side application, multiple page-specific JavaScript "widgets", and an API endpoint for AJAX communication. That doesn't sounds very fun or efficient for the programmer. It's is taking a step back in time in terms of developer happiness, and application complexity (and possibly efficiency but that's implementation specific). Also, what about saving UI state?? Good luck with that...

What sounds better to me is a single RESTful interface and a JS application that renders all of your views. It does have it's downsides (SEO + tin-foil hat people disabling JS), but it's a much more elegant solution.

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

#30

Post by mixonic »

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 application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe.

The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications.

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. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler.

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

Post reply on HN