Missing the Point of Server-side Rendered JavaScript Apps

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.<p>Sounds like Progressive enhancement [1].<p>[1] <a href="http://tomdale.net/2013/09/progressive-enhancement-is-dead/" rel="nofollow">http:&#x2F;&#x2F;tomdale.net&#x2F;2013&#x2F;09&#x2F;progressive-enhancement-is-dead&#x2F;</a>

@tomdale,<p>I think you&#x27;re conceptually correct (server-rendered apps don&#x27;t replace your API&#x2F;data server); however, it&#x27;s just as misleading to say that a server-rendered app replaces your CDN.<p>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:<p>- Data layer&#x2F;API server: exposes your data to a client in a RESTful way<p>- Browser: a client (one of potentially many) that presents data from your API in an interactive way<p>- App server: a node&#x2F;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&#x2F;Django&#x2F;Rails&#x2F;PHP, though sometimes conflated with the data layer.<p>- CDN: makes your media that doesn&#x27;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.

(Throwaway because I don&#x27;t want my real name associated with the site)<p>So here&#x27;s another perspective. I&#x27;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.<p>The site loads a single 80kb JS file (which also contains all templates) and fires of one AJAX request that gets the requested data. This data is the same for all visitors (for the same resource), so it can be easily cached on the server for a few seconds, before it gets stale.<p>Everything on this site can be voted (tags, comments, images). These votes are stored client side and synced with the server if needed. This means I can load my canned data from the server and augment it with client data when rendering.<p>If I were to render it server side, I&#x27;d have to create a custom page for each and every user and load the client&#x27;s votes from the database for each request. This is simply not feasible with the current hardware.<p>[1] <a href="http://pr0gramm.com/" rel="nofollow">http:&#x2F;&#x2F;pr0gramm.com&#x2F;</a>

My response to this consists of a library: <a href="http://intercoolerjs.org/" rel="nofollow">http:&#x2F;&#x2F;intercoolerjs.org&#x2F;</a><p>Server-side rendered <i>HTML</i>: an idea so crazy... It. Just. Might. Work.

Whatever architecture you use, it all depends on your requirements. Example: If SEO is important, build server side rendering. Period.<p>Just make sure you provide best user experience possible.<p>Author claims Bustle is one of the good JS rendered site. If you scroll down <a href="http://www.bustle.com/" rel="nofollow">http:&#x2F;&#x2F;www.bustle.com&#x2F;</a> and click on the item, and if you use back button, you won&#x27;t be at the same position. This is one of the biggest problem with JS rendered site.<p>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.<p>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.<p>Hacker news: <a href="http://hn.premii.com/" rel="nofollow">http:&#x2F;&#x2F;hn.premii.com&#x2F;</a><p>Reddit: <a href="http://reddit.premii.com/" rel="nofollow">http:&#x2F;&#x2F;reddit.premii.com&#x2F;</a>

Great post but taking your Twitter example why not make a full HTML version like GMail does so you don&#x27;t have to scrap the client side stuff? Also so you don&#x27;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.<p>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 &#x27;meh&#x27; experience.<p>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.

Thank you Tom Dale for continuing to make ember better with Fast Boot. I personally write and live-test a lot of my apps on 4chan&#x27;s &#x2F;g&#x2F; and &#x2F;r&#x2F;programming (which I imagine hosts a large &quot;tinfoil&quot; user base), and the most common feedback I would get from them is &quot;why do you need javascript for this trash?&quot; (well, the actual most common feedback I&#x27;d get from them are personal insults regarding my sexual preferences, but they&#x27;re not constructive and heeding them will not lead to a better product). So thank you so much for working to make ember server-side-enabled.<p>Also, not to put the cart before the horse, but any chance we&#x27;ll be getting virtual dom any time soon?

I don&#x27;t think anyone is missing the point at all. I fully understand what you&#x27;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.<p>I really wanted to like Ember, but even with those issues aside, the two most common comments on out team about Ember were &quot;Wait, why is that working?&quot; and &quot;I didn&#x27;t change anything, why isn&#x27;t it working now&quot;. Neither is something you should be hearing from your dev team.<p>You can do some pretty cool things pretty quickly, but there are more promises that resolves.

&gt; 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<p>Maybe I&#x27;m just missing something obvious, but wouldn&#x27;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&#x27;s normal bootstrapping? I don&#x27;t think it&#x27;s that uncommon for the database to be a bigger bottleneck than the network.<p>Are there any benefits over, say, slapping a screenshot of the page as the background of body? (yes, I know I&#x27;m oversimplifying, but for instance, Facebook loads up wireframy graphics as placeholders until ajaxed stuff pops up.)

Well, I freely concede I am still missing the point. You use client-side javascript because that&#x27;s what runs in the client. Whatever your server-side code does, why would you write it in javascript?

EDIT: Lots of downvotes for saying that there are other ways to program apps besides doing everything on the client. <i>Render</i> content on the server, <i>enhance</i> content presentation on the client.<p>---<p>I don&#x27;t get it. Is this 1996? Why are people just <i>now</i> &#x27;discovering&#x27; that you don&#x27;t need to throw JS at an application to have it completely usable?<p>&gt; 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.<p>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.<p>&gt; Client-side JavaScript applications are damn fast.<p>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&#x27;t think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren&#x27;t fast?<p>---<p>JS Hipsters offloading rendering everything to the client for absolutely no reason is the &#x27;everything-looks-like-a-nail&#x27; or the &#x27;everyone surfs the web like I surf the web and has my specs&#x27; problem. Worst of all, in doing so, they completely neglect actual content. You don&#x27;t know how many million-dollar VC-funded company webpages I&#x27;ve visited that don&#x27;t even have a damn tagline visible on their landing page without JavaScript enabled. &lt;h1&gt;s with actual content inside of them are too complicated now?<p>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&#x27;s literally like we&#x27;re discovering DHTML all over again.

They&#x27;re misusing the term &quot;rendered&quot;. 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&#x27;s what content management systems do - assemble a page out of parts on the server and deliver it to the client.

You gotta love the Orwellian naming on this one. &quot;Ember FastBoot&quot; meaning Ember-we&#x27;ve-been-selling-you-very-slow-booting-for-years-and-now-we&#x27;re-hoping-to-mitigate-it-slightly-but-it&#x27;s-still-vaporware.<p>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 first. Load the rest later. This includes bootstrapping — remembering to put all the data you need to render the page inline as a JSON object in the HTML.<p>This can often result in less data sent over the wire than a large HTML page with tons of repeated DOM elements. It&#x27;s also far easier to cache appropriately.

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.<p>Here&#x27;s MercuryJS&#x27;s example of server rendered app: <a href="https://github.com/Raynos/mercury/tree/master/examples/server-rendering" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Raynos&#x2F;mercury&#x2F;tree&#x2F;master&#x2F;examples&#x2F;serve...</a><p>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.<p>What this means is that you no longer need a back-end team and a front-end team. Your front-end team is your team (not counting &quot;API&quot; teams). Sure, some companies have already been doing this but now you can do it with far less code. And you can do it faster. And with fewer developers (there&#x27;s less work). Which means you can do it cheaper.<p>All of this means is, if you are writing your front-end and back-end in different languages, <i>you are in a real competitive disadvantage</i>.<p>So any language used for web development is going to see its usage slide if they can&#x27;t find an answer for transpiling to JavaScript. And hopefully having an isomorphic answer the way JavaScript now has.