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

71–79 of 79 posts

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

#71

Post by carsongross »

CGamesPlay wrote: post #55
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).

I wouldn't dismiss it so blithely. I implemented a remote job runner UI here:

http://intercoolerjs.org/examples/jobrunner.html

You can get pretty far with it.

It isn't a perfect fit for every app, but most apps have at least a few areas where using it would simplify things considerably.

Also, there are a lot of nice things that are extremely easy to use that are a PITA with most other frameworks. For example, AJAX-aware history is an ic-push-url="true" away:

http://intercoolerjs.org/examples/history.html

I realize that most front end people who see this will immediately dismiss it as "simple", but it's a very rich library and can be used to accomplish an awful lot: you can fire client side events using custom HTTP headers, show and hide request indicators using only a CSS selector, etc.

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

#72

Post by quaunaut »

thekingshorses wrote: post #63

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

I don't know what you're talking about. The back button works on Bustle everywhere I've tried it. What browser and version are you using?

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

#73

Post by chrisdotcode »

sanderjd wrote: post #70
chrisdotcode wrote: post #38

Earlier quoted context omitted.

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

The oft-touted claim is that client-side templating is easier, but they're the same, really. The server solution is literally using the same exact templating engine and code.

What people are conflating is "doing things in the client with JavaScript" and "rendering templates in JavaScript", which are two entirely different domains.

You can't access many cool features client-side without JavaScript, full stop. But rendering things on the client, and presenting an absolutely un-usable design without turning-completeness is not content-first design.

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

#74

Post by chrisdotcode »

ctide wrote: post #67
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 compl…

> The cost to support users such as you is just not worth it, you're too small of a segment.

You don't understand. The web is content-based. Like motherfuckingwebsite.com [0] shows, you don't need dynamic content to present your message. If I need to download 1MB of JS to see your freaking tagline, then that's ridiculous.

[0] https://news.ycombinator.com/item?id=6791297

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

#75

Post by quaunaut »

cyberpanther wrote: post #18

Great post but taking your Twitter example why not make a full HTML version like GMail does so you don't have to scrap the client side stuff? Also so you don't have to build a framework specific server library like Fastboot. I feel like Fastboot is a more sensible solution than lets say Meteor.js; however, it is still about solving issues for a minority of your users who are on slow internet and older devices. If you…

It's not just for users on slow internet or older devices- Bustle was a good example, because as a content site, it generally has a lot of assets to load.

Fastboot can get you over the hump of the initial load when you're linked to a content-heavy page on the site for the first time, and hide the download/boot of the JS app for the moment it becomes ready.

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

#76

Post by subsection1h »

quaunaut wrote: post #72
thekingshorses wrote: post #63

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

I don't know what you're talking about. The back button works on Bustle everywhere I've tried it. What browser and version are you using?

In Chrome, when I scroll to the bottom of an article at Bustle, click a link to another article, and then go back, I'm directed to the top of the first article, not the bottom where I left off. In my experience, this behavior is the norm at sites that use client-side rendering, and it's the main reason why I hate browsing content sites that use client-side rendering.

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

#77

Post by recursive »

quaunaut wrote: post #72
thekingshorses wrote: post #63

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

I don't know what you're talking about. The back button works on Bustle everywhere I've tried it. What browser and version are you using?

I can reproduce with Chrome 40 on Windows 7.

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

#78

Post by remysharp »

tomdale wrote: post #4
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/

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…

Playing devil's advocate:

PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.

FastBoot, I suspect, will dictate how I code my application/server side logic.

On the surface, it looks like the cost of FastBoot is higher.

The benefits are, I suspect, are higher though: single code base, reusable views, etc.

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

#79

Post by Touche »

azakai wrote: post #41
Touche wrote: post #6

Earlier quoted context omitted.

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.

Progressive enhancement is not a technique, it's a goal. Server-side rendering is a method for achieving the goal.
Post reply on HN