Missing the Point of Server-side Rendered JavaScript Apps

Re: Virtual DOM, keep an eye on https://github.com/tildeio/htmlbars/pull/282.

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 just a lot of dynamic stuff you need to do that can only be done in JavaScript.

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.

> Client-side JavaScript applications are damn fast.

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?

---

JS Hipsters offloading rendering everything to the client for absolutely no reason is the 'everything-looks-like-a-nail' or the 'everyone surfs the web like I surf the web and has my specs' problem. Worst of all, in doing so, they completely neglect actual content. You don't know how many million-dollar VC-funded company webpages I've visited that don't even have a damn tagline visible on their landing page without JavaScript enabled. s with actual content inside of them are too complicated now?

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.

@tomdale,

I think you're conceptually correct (server-rendered apps don't replace your API/data server); however, it's just as misleading to say that a server-rendered app replaces your CDN.

Instead, server-rendered apps add a new tier (if you were serving your app from S3 before) or replace an existing tier (your old app server). The kinds of people who needed a CDN before will still need one, and your API layer should not be tightly coupled to your app, esp. if you eventually want to support a native app or a developer ecosystem. So you end up with:

- Data layer/API server: exposes your data to a client in a RESTful way

- Browser: a client (one of potentially many) that presents data from your API in an interactive way

- App server: a node/io.js server that renders your app to HTML and sends it to the browser. It optimizes for search and slow devices without duplicating your app logic. This role was previously filled by Flask/Django/Rails/PHP, though sometimes conflated with the data layer.

- CDN: makes your media that doesn't change often highly available and lower latency. If you needed on of these before you added an app server, you probably still need one.

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 your really using slow internet and old devices than the experience is still going to be slow no matter what you do unless you really strip things down. So just make multiple experiences that are really good instead of one 'meh' experience.

With that said, Twitter made the right decision at the time because their client side implementation sucked on all machines not just the old ones.