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

Re: [whatwg] HTTP status code from JavaScript

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 25 May 2014 16:16:22 +1000
Message-ID: <CAHp8n2ngGAsTQz0XuTATnDatHuq4dZ7QURjPA0wVxPJKN=X6Gg@mail.gmail.com>
To: Michael Heuberger <michael.heuberger@binarykitchen.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>
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
>
Received on Sunday, 25 May 2014 06:17:33 UTC

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