W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] HTTP status code from JavaScript

From: David Bruant <bruant.d@gmail.com>
Date: Sat, 24 May 2014 20:53:49 +0200
Message-ID: <5380EABD.5090502@gmail.com>
To: Michael Heuberger <michael.heuberger@binarykitchen.com>, whatwg@lists.whatwg.org
Le 23/05/2014 10:04, Michael Heuberger a écrit :
>>> - Display a beautiful 404 page and hide parts of the navigation
>>> - Reveal navigation history to give users a better usability experience
>>> during 404s
>>> - And many more …
>> I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server?
> No, it is a single page app. All the HTML templates are on the client
> side and loaded once during page load. And everything happens
> dynamically. In other words: You load everything once, then there is no
> further interaction with the server unless it's a specific query for
> data or alters data in the database.
"single page app" usually means that no interaction in a given page will 
trigger a navigation (as long as there is JavaScript. A good SPA will 
fallback to using links and forms if there is a problem with JS).
It does not mean that all HTML templates are on the client nor that you 
serve the exact same thing for every URL be they 200s or 404s. That's an 
definitely an option, but it's one you impose upon yourself.

Serving different content based on different URLs (and status) actually 
does make a lot of sense when you want your user to see the proper 
content within the first HTTP round-trip (which saves bandwidth). If you 
always serve generic content and figure it all out on the client side, 
then either you always need a second request to get the specific content 
or you're always sending useless data during the first generic response 
which is also wasted bandwidth.

On this topic, I recommend watching [1] which introduces the idea of 
"critical rendering path". Given your focus on performance and 
preventing wasted bandwidth, I think you'll be interested.

> Furthermore you can convert a whole single page app into an iPhone app
> with PhoneGap. All the HTML resides in the app, not on the server.
> That's a very different approach and a good reason why JavaScript has
> the right to know if the HTTP request resulted into a 200 or a 404.
If all the HTML resides in the app, not on the server, then it wasn't 
served via HTTP, so there is no 200 or 404 to inform about (since no 
HTTP request occured).

David

[1] 
http://www.youtube.com/watch?v=PkOBnYxqj3k&list=PLS3jzvALRSe6uP9gVfXLCG6nWo7M0hAJY&feature=share&index=2 
Received on Saturday, 24 May 2014 18:54:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC