Re: [whatwg] HTTP status code from JavaScript

Hi Michael,

Le 25/05/2014 07:10, Michael Heuberger a écrit :
> 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.
Look at React.js, it allows to render templates on the server side and 
it's been a selling point for some people (it allows to generate the 
same page whether you are on the client or server-side. It helps for SEO 
sometimes).

> Also I mentioned earlier, PhoneGap is getting more popular and exactly
> uses the architecture I have described.
With application built with PhoneGap, the application (including the 
main HTML file) is downloaded once, so that's different from a webpage 
served from a server.

>> 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).

> This is better than letting the user wait about 700ms until the user
> sees something on the screen.
I'm proposing for the user to wait 0ms (ignoring uncompressible 
networking time of course) until the user sees something useful.

>> 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 :(
I apologize for mistakenly assuming video was a proper format for 
everyone to consume.
You can find the slide deck at 
https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present#slide=id.p19
It should be self-sufficient. I'm happy to answer questions if it isn't.

And credit where it's due, everytime I wrote above "what I'm proposing" 
it is just a reformulation of my understanding of Ilya Grigorik's 
presentation on the critical rendering path (I just add an emphasis on 
content).

>>> 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.
Option b) sounds like a bookmark, so it's a regular web page, so the 
arguments against stand (?)

> 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?
By that argument, an absurd amount of features should go in ;-)

 From a technical standpoint, I see no strong reason to not provide the 
HTTP status code.

 From a more "social" standpoint, it bothers me, because it means people 
serve the exact same content for all URLs, which defeats the very 
purpose of why URLs were invented in the first place.
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.
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.

David

Received on Sunday, 25 May 2014 11:33:43 UTC