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

Re: [whatwg] HTTP status code from JavaScript

From: Michael Heuberger <michael.heuberger@binarykitchen.com>
Date: Sun, 25 May 2014 18:59:13 +1200
Message-ID: <538194C1.9000706@binarykitchen.com>
To: whatwg@lists.whatwg.org
Thanks Silvia for your comment but I think we turn in circles.

I know you mean it well but this is not the case as I mentioned it over
and over again in my previous emails.

Let me repeat, the whole SPA of mine is always loaded, no matter if it's
a 404 or not so that a nice 404 can be rendered on the client-side. No
piece is missing here. To make this work, Javascript needs to be able to
have access to the HTTP status code of the initial page load. I can
count more reasons or read my previous emails.

Something like `window.http.status` would be really awesome.

On 25/05/14 18:16, Silvia Pfeiffer wrote:
> Hi Michael,
>
> On Sun, May 25, 2014 at 3:10 PM, Michael Heuberger
> <michael.heuberger@binarykitchen.com> wrote:
>> Hi David
>>
>> Interesting. Yes and no, I agree with some. See my comments below:
>>
>> On 25/05/14 06:53, David Bruant wrote:
>>> 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.
>> I understand. Okay we could debate about the definition of SPA. For
>> fallbacks and special cases I deliver special files from the server when
>> JS is disabled. But I think the definition of SPA nor its special cases
>> are the main issue here.
>>
>> Look at Angular, their templates reside on the client side. For
>> production, a grunt task can compress all files into one single, huge JS
>> file that is served to the client, then for any subsequent pages no more
>> resources are loaded from the server. It is a widely used practice.
> If you're creating your JS file on the server and pulling in all
> resources then, surely you can find out already at that time whether a
> piece is missing and can't be loaded? That's not a client side issue,
> but something that you'll need to deal with on the server.
>
> Silvia.
>
>> Also I mentioned earlier, PhoneGap is getting more popular and exactly
>> uses the architecture I have described.
>>
>> Again, I cannot emphasize how cool it would be to obtain the HTTP status
>> code from JavaScript! It would save SPAs and PhoneGap projects some
>> bandwidth.
>>
>>> 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. 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.
>>
>> This is better than letting the user wait about 700ms until the user
>> sees something on the screen.
>>
>>> 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.
>> Thanks for the link but I am Deaf and do not understand what they talk
>> on YouTube :(
>>
>>>> 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).
>> Ah, well spotted. PhoneGap comes with two options:
>> a) You can choose to reside the whole HTML in the app or
>> b) have it served from the server during the first HTTP request.
>>
>> Option a) saved bandwidth but you cannot update pages easily (option b).
>>
>> Option a) wouldn't need to know if it's a 200 or 404, you are right.
>> Still, option b) needs to know the status code.
>>
>> Let me ask you another question:
>> Is there a good reason NOT to give JavaScript a chance to find out the
>> HTTP status code of the current page?
>>
>> Cheers
>> Michael
>>
>> --
>>
>> Binary Kitchen
>> Michael Heuberger
>> 4c Dunbar Road
>> Mt Eden
>> Auckland 1024
>> (New Zealand)
>>
>> Mobile (text only) ...  +64 21 261 89 81
>> Email ................  michael@binarykitchen.com
>> Website ..............  http://www.binarykitchen.com
>>

-- 

Binary Kitchen
Michael Heuberger
4c Dunbar Road
Mt Eden
Auckland 1024
(New Zealand)

Mobile (text only) ...  +64 21 261 89 81
Email ................  michael@binarykitchen.com
Website ..............  http://www.binarykitchen.com
Received on Sunday, 25 May 2014 06:59:55 UTC

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