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.
Devices like that and/or rolling back the time decay on a post only work while the post is relatively new. Once it's past a few hours old, it looks weird to have it on the front page with only a few points.
> 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.
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.
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/
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:
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
If you do this again, we're going to ban your account. You've broken the HN guidelines so many times, and we've warned you and cajoled you and asked you to stop so many times, that enough is enough.
Edit: you edited out the worst of it, but the comment is still a personal attack.
If you didn't see any of those, I apologize for assuming that you did. Now that you have, though, please just post civil comments from now on. Your comments have routinely violated that rule, and it's the most important one we have.
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.
53 comments
[ 2.3 ms ] story [ 115 ms ] threadI was under the impression that identical URLs were rejected as dupes?
We do reject identical URLs for a few hours to avoid stampedes of popular posts.
https://news.ycombinator.com/newsfaq.html
Is it OK to regularly submit twice in two days? I see that pattern with OP.
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.
More at https://news.ycombinator.com/item?id=10325217 if you're interested. It'd be great to find a better solution and we're open to ideas.
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.
https://github.com/GordyD/3ree/blob/master/server/universalA...
http://rackt.github.io/redux/docs/recipes/ServerRendering.ht...
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.
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.
I wish more people would do that :)
> 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.
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.
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.
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.
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.
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.
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.
Nothing about this 'architecture' is new in any way.
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.
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.
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.
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.
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.
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.
1. https://userify.com
2. https://github.com/userify/shim
Now decide if you want to listen to his opinion of all his 'experience' of these projects.
Edit: you edited out the worst of it, but the comment is still a personal attack.
Are you relying on people to check replies rather than using their email?
That seems pretty flaky as there is no notification system in place to tell people about replies like, for example, reddit.
You're on American time, I'm on UK time, I must be in bed when you send your warnings and this seems pretty unfair to people outside of your hours.
https://news.ycombinator.com/item?id=10094201
https://news.ycombinator.com/item?id=9848716
https://news.ycombinator.com/item?id=9674126
If you didn't see any of those, I apologize for assuming that you did. Now that you have, though, please just post civil comments from now on. Your comments have routinely violated that rule, and it's the most important one we have.