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: Mon, 26 May 2014 13:09:12 +0200
Message-ID: <538320D8.8040309@gmail.com>
To: Michael Heuberger <michael.heuberger@binarykitchen.com>, whatwg@lists.whatwg.org
Le 26/05/2014 01:52, Michael Heuberger a écrit :
>>>>>> 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.
>>>>> Good point. From that point of view I agree but you forgot one thing:
>>>>> The user experience. We want mobile apps to be very responsive below
>>>>> 300ms.
>>>> Agreed (on UX and responsive applications)
>>>>> Hence the two requests. The first one ensures the SPA to be
>>>>> loaded and the UI to be initialized. You'll see some animation, a text
>>>>> saying "Fetching data" whatever. Then the second request retrieves the
>>>>> specific content.
>>>> What I'm proposing is that all the relevant content is served within
>>>> the *first* request. The URL is used by the client to express to the
>>>> server (with arbitrary granularity, it depends on your app, obviously)
>>>> what the user wants.
>>>> What I'm proposing is not two requests to get the proper content, but
>>>> only one. The user doesn't even have to wait with a useless "Fetching
>>>> data" screen; the useful content is just there within the first
>>>> request (hence server-side rendering with React or Moustache or else
>>>> being useful).
>>> Yeah of course I could do that too. It is psychologically proven that
>>> the subjective waiting time is shorter when you see something as soon as
>>> possible.
>> Yes and what I'm suggesting is providing actual content as soon as
>> possible. The whole idea of the "critical rendering path" is exactly
>> about engineering your webpage so useful content is provided to the
>> user as soon as possible (which is as soon as you're currently capable
>> of showing a "Fetching data" screen).
>> If you're being serious about bandwidth and UX (including percieved
>> performance), it's exactly what you should be doing, I believe.
> I agree totally with you here. But again, I want to know the 404 in one
> request, not within two requests (Ajax).
I am suggesting that you make a single request, not two.
You're focusing on the HTTP status code, but in the end the code isn't 
important. Showing the relevant information to the user is what's 
important. The status code (client-side or server-side) is just a means 
to get there.
What I'm proposing is to bypass the "which status is it?" part to get to 
the "show the relevant information to the user" part.

> Isn't that a performance
> optimization (regardless of your application architecture and critical
> rendering path)?
> Still, the ability to read the HTTP status code from JavaScript would
> prevent me from doing "hacks".
I wouldn't consider showing the right content (that the link is broken) 
to your users a hack.

>>> It is absolutely normal that URLs change or become invalid, hence the
>>> need for status codes. You know ...
>>>> You want to serve the same content regardless of the URL and then have
>>>> client-side code read the URL and change the page state based on the
>>>> URL. We already have a standardized way to express a part of the URL
>>>> that is only interpreted on the client side which is the hash
>>>> (everything after '#'). Format your URLs using # if that's your
>>>> intention.
>>> My single page app works without the # part and uses absolutely
>>> normal-looking URLs to make it easier for search engine to spider it.
>> Then why serving the exact content on every URL?
> I don't do that :)
(I meant "exact same")
As far as the server is concerned, you're doing that. Otherwise, you 
wouldn't be needing for the HTTP status on the client-side.

>>>> Also, given that you always serve the same content and only figure
>>>> things out on the client side, why does your server sometimes answer
>>>> 404? Deciding whether the URL is erroneous should occur on the
>>>> client-side, no?
>>>> Anyway, so far, what you're asking for seems like it's only
>>>> encouraging misusage of existing technologies.
>>> Okay, I have a huge sign language video library here for Deaf people.
>>> Anyone can add / edit / delete stuff. Each video has an unique URL. When
>>> I load a page of a deleted video, a 404 is returned with the whole SPA
>>> code and additional stuff is rendered to deal with 404s in a nice way to
>>> improve usability. Here you have a real-world example and it is not a
>>> misusage of technologies.
>> I still see a misuse of URLs.
>> Why aren't you serving a different page for 404s? The perceived
>> performance would be better for your users.
>> Even if there is a way to read the HTTP status code, the user has to
>> wait for:
>> 1) the HTML + the SPA code to be downloaded
>> 2) the SPA to read the HTTP status code, build the error page
>> 3) display the error page
>> If you serve a different content on 404, the user has to wait:
>> 1) the HTML to be downloaded (which naturally displays the page)
>> 2) (then, you can improve the experience with the JS code which
>> downloads while the user is reading that they're on the wrong page)
> Good summary! I've been thinking about this a lot before myself and
> tried it myself.
> I didn't decide for the latter method because I wanted to process /
> treat all the pages the same way
(this is what I called above "serving the exact same content on every URL")

> without exceptions to keep the code on
> the server side as simple as possible. And it would become too
> complicated and really bad. When the HTML is downloaded, then it is
> rendered and as long as the JS code is not ready, you are in an
> undefined state.
> Also, think of other things i.E. navigation elements which are totally
> JS driven. I'd have to add more hacks, bend my framework to make it work
> for this case and so on. Just too complicated and cost more at the end.
> I want to treat all the pages the same way with "one" code. This would
> work if the HTTP status code is readable from within JavaScript.
That's the heart of the problem I believe. You trapped yourself into 
some framework design choices and wish a change in the platform to 
accomodate your current architecture; have the platform pay for your 
technical debt in a way :-/

Received on Monday, 26 May 2014 11:09:38 UTC

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