Re: [whatwg] HTTP status code from JavaScript

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.

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 05:11:06 UTC