▲ 46 points
back
51 comments
Probably not? Generally there is a need for more efficient orchestration than you can achieve without per-use-case endpoints (in other words, you need to do some interdependent operations such as database access calls that depend on previous database accesses, or what have you, and those are too expensive to do due to round-trip latency over the internet, so you do them server-server). Whether the endpoint is serving JSON vs HTML, which is basically the distinction in this article, is irrelevant.
I mean if you just make the same endpoints on the server that you would have made back in he HTML serving days, but instead serve JSON, and then call that an 'api', then sure, yes, but then it's a distinction without a difference, you are just moving the rendering of the data into html from the server to the client, this only a small a api, not an API as in 'the thing you use for generic 3rd party programmatic access to your features'.
Also, rendering html on the client is silly and has no benefit, no matter how hip it is. It's not faster, it's not more efficient, it's much harder to test, it forces you to use a terrible language (javascript) instead of your-choice-of-any-language (which can still be javascript), it makes capturing errors harder, it dramatically increases the amount of code that has to be cross browser compatible and also has to support older browsers, and ditto all the bug stuff for performance. It's just a completely stupid idea that people are doing for no clear reason at all, generally because they have little experience and are just cargo culting whatever the cool kids with blogs are talking about.
I give you everything, except efficiency. As an example, I did a view source of the blog entry linked in this submission. The instance of the page that I got was 22914 characters long, of which 2172 characters were actual article text - roughly 10%. If I as a user wanted to view more entries from that blog, I think I'd be very grateful if I only needed to download the remaining 90% once and not again for each blog entry.
There are 2 things wrong with your analysis, IMO.
First of all gzip will reduce this considerably. Both will end up much smaller, but also the % difference will be reduced, since the html version is likely to contain much less entropy per bit.
Secondly, in my version of how to do it, you can still use AJAX. It's fine to load blog posts via AJAX, and in that case you aren't reloading the boilerplate of the page? I am saying to return rendered html in the response rather than returning json and rendering it into html in the browser. The specific data returned can be the same either way, and the overhead of html over json in the case of a set of blog posts should be tiny, and depending on how much markup the posts themselves contain, the html version is quite possibly going to be smaller.
> The most obvious issue with this architecture is service startup-time. Since data is no longer embedded into HTML pages that are served at once, our static front-ends must make API calls and retrieve data before the page can be allowed to render.
Universal JS apps can help here. Render the JS app page server side using a thin Node server, hydrate the fully formed DOM on the browser and run it client side from there. Truly, the best of both worlds.
HTTP/2 seeks to address this as well, through server push, I believe. How successful that is isn't something we'll know until take up increases.
What idiot downvoted this? This is the solution for companies using single page sites. You render the page server side using some headless browser and serve that on the first load (or always for search engine spiders, or people with JavaScript disabled.) That way you don't suffer the latency penalty on the first load and subsequent loads work as usual with a single page app. I'm pretty sure I read that twitter does this, but it might be some other big player.
It's a fine architecture, true. Maybe you're thinking of AirBNB, they popularised this "holy grail" model (http://www.oreilly.com/pub/e/3009) since around 2012.
Twitter did have to backtrack from the #newtwitter pure client-side model. Serving a 140-character string shouldn't require a 1+ MB payload. So maybe they server-generate their pages this way too now.
It is definitely the solution, but I've yet to find the setup that makes it cheap and easy to do. Links welcome!
React + some sort sort of library to handle app state (Redux is recommended). You gain a modern componentised frontend app and the ability to render it server side. Server rendering of a React app is pretty simple, of order maybe a 100 lines of code or so. And that includes populating the server rendered pages from the same API as the frontend uses. Redux docs may be a decent place to start:
http://rackt.github.io/redux/docs/recipes/ServerRendering.ht...
React will render HTML on the server side using the same code and data structures you use for dynamic components on the client side. https://facebook.github.io/react/
To demonstrate this point for those not familiar. Here is an example of using React + Redux on the server to render with an initial state.
https://github.com/GordyD/3ree/blob/master/server/universalA...
This isn't the future. This is the present.
We built Userify[1] (ssh key management for EC2 & elsewhere) entirely using this model (REST API) because it gives us a clean way to inspect incoming data and respond with pure JSON.
Since it's just JSON over HTTPS, clients are all easily implementable in any language (i.e., Javascript and HTML5 for the web app, beta client SDK's currently in Python and JS, more on their way), or just a curl shell script. (The agent[2] is just a single Python script with no dependencies.)
And, now, with great tools like Phonegap/Adobe Build/etc, you can convert your responsive mobile web app into an Android or iPhone app in seconds (performance is no longer an issue, either).
Best of all, you maintain a clean separation of concerns and isolation between your API resources and the front end.
Compared to the server-driven ways from the last century, this is so much better; we can provide a full desktop app experience, make it feel more like a web page, or anywhere in between.
AJAX changed everything. This is simply better.
Can't believe such an uninformative post is trending#2 here. Literally didn't taught me anything new.
> API server and a static front end – the future?
It's not static front-end, but SPA - Single Page Application. It's the part of the larger Serverless / Backend-less computing trend.
We already have:
- static websites (i.e. served from Amazon S3 or Google Cloud Storage)
- static blogs and CMSes
- frameworks for SPAs (Ember.js, Angular, etc.)
- Firebase and the likes
- Amazon Lambda and the likes
And yes - Serverless is the future.
> Write the back-end initially in RoR or Flask, move it to Elixir or Scala when your servers start crashing.
why not to write it in Phoenix/Elixir from the start? I don't think it's any more harder than RoR.
Well, I just disabled JavaScript with ScriptSafe recently due to security and privacy concerns.
And there are many blank pages I get to see, because of this kind of Architecture and CDN's. Nowadays even blogs with mostly static content don't work. That's realy annoying.
If you depend on search engines, remember you get penalties for this kind of sites. You need to have some kind of prerendering to satisfy you ChiefSearchEngineOptimizer.
How do you support Bookmarking in a Single Page Application? I think this is an essential feature and not trivial to implement correct.
I tried Angular. It works. It looks nice and smooth, but I don't think it is a good solution. JS is nice as an enhancement, but I don't like it as a dependency to use the web.
===Addit Not so long ago we have had similar approaches to JS-SPA. They were called Java Applets and Flash. These Technologies are dead. Everything you do today with JS was 10 years ago possible with these technologies. The only constant in the web that's gonna stay is HTML.
JS is overused. There are so many things you're better off without JS, like Blogs, Hackernews or simply valueable content. There might be usecases for SPA, but a high percentage are better off without these cool and fency stuff.
Eliminating Serverside Rendering for scalability reasons as a first step is often followed by implementing prerendered content in script-Tags or via react on node. The only thing that gets scaled is complexity.
If you disable JavaScript, I'm afraid you're not the target audience of 99.99% of the commercial/content internet. The web is no longer static, and websites are now essentially applications. This is a generalisation, but it mostly holds true I think.
As for bookmarking - any dynamic single page content site and many applications will support linking directly to a certain content or section of the app via various techniques.
JavaScript is not a nice enhancement. It IS the web.
It's fine to think of JavaScript as something that you depend on for major features but I still think you have to follow progressive enhancement. A small, but potentially growing, number of users have JavaScript disabled completely but a much larger number of people effectively have it disabled for a non-trivial period of time while things download or even, due to errors, until they reload the page.
If you don't degrade well under those circumstances you're at a competitive disadvantage to sites which do something like quickly return a core HTML page which can display immediately while the full app loads.
Just to reply to one point:
> How do you support Bookmarking in a Single Page Application? I think this is an essential feature and not trivial to implement correct.
I'm not sure I've ever seen this be a problem. You make sure the app is served from any route that exists within the app, and the app's router loads the correct content based on the url when it boots up.
You're correct. In modern browsers we have control over the history via the HTML 5 history API. Previously we used the hashtag to deal with state changes, which mostly worked (does allow pages to be bookmarked).
Google and other search engine crawlers view pages much like browsers these days, see e.g. http://searchengineland.com/tested-googlebot-crawls-javascri...
Not sure what the ranking penalty might be. Would guess it's small to none.
I'm surprised even 10% of sites show anything these days. I get a lot of broken sites just by disabling tracking and ads.
I can imagine disabling js would be much like disabling half of the html tags.
In my experience, this isn't really true. Google still can't crawl most non-trivial javascript-powered apps, and if it doesn't work, there's little insight on what you need to tweak to get it working. It hasn't been able to crawl our javascript-powered parts of the site across two major architectures without prerender, and I know a lot of other companies with the same issue.
Most people don't disable JavaScript but beyond that edge case (I consider JS disabled an edge case) I agree that this architecture isn't necessary and overused. A single page app is great on a MacBook Pro with 2 tabs open but run that on most "normal" people's machines and it gets laggy quick.
People always mention disabled JS and SEO as pitfalls but I think performance and practicality are the obvious reasons not to do this that get overlooked. SPA architecture is something I use alongside server rendered pages. When you have one page or a series of pages in a particular user flow that would benefit from no page reloads and are heavy on interactivity then it makes sense but otherwise I can't see the value. I think developers will realize this and take a more balanced approached with a practical mix of pages rendered server side and pages that use XHR and JavaScript to enhance the experience.
> Most people don't disable JavaScript
How, exactly, do you know this?
Sure, it's probably a reasonable guess. I just wonder how many of the people making this claim are simply assuming it to be true or relying on some sort of analytics service. About the only way you could tell is by counting the server logs, which I'm often told are hard/annoying/unavailable by analytics advocates.
Lots of things work fine, and then you go to some new startups page which loads JavaScript from 35 different CDNs and refuses to do anything until they are all whitelisted.
Regarding SEO, your mileage may vary. At JustWatch we had the hypothesis that we can make a static Web App in Angular that uses SEO as the main traffic driver and is both more usable and more search engine compliant than a classic HTML serving backend.
So far, the metrics prove it's possible and we're quite happy with it. Interaction after slightly larger initial loading time (kept low via SPDY / HTTP/2 CDN) is much more snappy than the classic approach. Also, Prod/Dev parity is higher now that we're using exactly the same JS "build" in stage and prod.
Rankings are great, just prerendering took some more engineering to set up reliably than we thought. I can recommend the guys at SEO4AJAX, they've got great engineering and customer support compared to the market leader.
the new 'best practice' is to have a universal app - that renders on the server on first load, and runs as a js app subsequently. This way crawlers and browsers w js disabled still get raw markup. Also, with SPA, you can add the urls to url history, so back button, bookmark etc aren't a problem either.
We support bookmarking via url parameters and hashes. It does take some extra coding to update the hashes in the URL as each action is taken, and to check them and pull in the correct data and application state on reload... but it is definitely a solvable problem.
I have JavaScript disabled by default in my browsers. If the site doesn't load, I usually try finding an alternate source, even if end up loading the cache from Google. I don't like these websites that load JScripts from unrelated places (ie. code.jquery.com, googleapis.com -> filtered), and if it's an e-commerce, I buy elsewhere when I can.
I wish more people would do that :)
The solution to the one problem he mentions is straightforward, isn't it? Embed the data needed for initial page load in the initial HTML delivered by the server. Perhaps as JSON in a <script> tag.
I'm not too familiar with the new front-end frameworks, do any of them support this seamlessly? If not, I'm surprised, it seems like a fairly straightforward thing to architect.
What dismays me more about the rise of the static front-end single-page-app, is it really means the death of the idea of the architecture of the web. It's going in the opposite direction from the 'semantic web' dream, as well as REST.
I do it this way with angular / express / server side templating. You render the title/ meta tags serverside for crawlers (fb, twitter, google), and drop your initial request payloads in a script tag. Everything else is clientside. It took me a long time to set this up and get it right though. However, it's fast as hell, and really quick to develop on.
Working on the assumption that the crawlers will index the JSON in the script tag?
Crawlers indexing is a different problem, and not the one the OP was talking about -- the OP's problem is specifically speed of first page display, and even more specifically speed of first page display due to having to make AJAX requests for data to display the first page.
But crawlers and "single-page" Javascript apps are another potential problem, sure, although not the one the OP discussed.
But wanting actual HTML in the original non-JS delivery for crawlers is I guess why people have followed the 'universal JS' approach instead of what we're talking about here.
Other comments in this post suggest that Google, at least, does fine with Javascript-generated pages these days. I have no idea myself.
I was replying to a comment that specifically mentioned crawlers: https://news.ycombinator.com/item?id=10325666
Just catching up on this reply- yes- google has no problem rendering the json into readable html. Just using server side rendering for meta / title tags is the way to go (at least for now)
yes- and Google does this just fine. The meta tags are more for fb, slack, twitter, etc.
Isn't this more or less what happens in a native app? The only difference is that on the web each view is identified with a URL. If so, history.pushState should make this trivial.
There are SO many cases where just delivering a prebuilt page would work so much better, and yet they don't. It's incredibly frustrating. Generate the HTML once server side and cache the hell out of it. Generating it EVERY PAGE LOAD for EVERYONE is cheaper for you but costs a lot more CPU time for everyone else. It's a waste of energy, it's a waste of battery, and I'd go as far as to say immoral.
I would generalize to say computers are immoral!
Why do I care to scale my front and back end independently? I'll just toss another full stack server on the heap of others and be done with it.
Well, that's sort of missing the point. If you have a fully static front end, you put in S3 and never ever worry about it again. Literally ever. Then, you have a json api that both your website and any mobile apps talk to. Makes websites and apps into the same api consumer model. Takes the number of moving pieces down quite a bit actually.
s/future/past
Nothing about this 'architecture' is new in any way.
Yesterday's post: https://news.ycombinator.com/item?id=10319822
I was under the impression that identical URLs were rejected as dupes?
On HN a post is only a duplicate if the story has had significant attention in the last year or so.
We do reject identical URLs for a few hours to avoid stampedes of popular posts.
I think I mentally crossed wires with Reddit.
Is it OK to regularly submit twice in two days? I see that pattern with OP.
I think we invited eatonphil to repost a couple of stories.
Reposts aren't necessarily a problem if the story hasn't had attention yet. On HN we want to optimize for curiosity, which means getting the best candidate stories in front of the community. Since /newest by itself does a poor job of that, we've been experimenting with other approaches.
Wouldn't easier to give yourself a super-vote of some kind? It'd reduce thinly-veiled grumbling from jealous folks like yours truly.
Thanks for the profound insight, captain obvious.