Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Wonderful, great input Karl, thanks! Very true about the sensitiveness
of the servers.

Yes, accessing the HTTP headers directly from DOM would be awesome
(without the need for an additional request!)

On 26/05/14 13:10, Karl Dubost wrote:
> Michael,
>
> A praise for more than HTTP status code.
>
> Le 23 mai 2014 à 12:36, Michael Heuberger 
>  a écrit :
>> There is a need to obtain the HTTP status code for the page itself from
>> JavaScript:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=999886
>
> We could do better. HTTP Code is yet another very specific bit of information.
> A question which is very often asked is how to access the HTTP headers from 
> JavaScript without having to go through a round trip of XMLHttpRequest.
>
> http://stackoverflow.com/questions/220231/accessing-the-web-pages-http-headers-in-javascript
>
> I wish indeed that in the DOM there would be a way to access a JSON object 
> with the full HTTP response headers and status line included.
>
> One of the reasons to record the full response instead of having to create an 
> additional request is that some headers are time sensitive and some servers 
> are very sensitive to the type of requests made. For example, some servers 
> will (wrongly) send a different response for headers and/or status line if 
> the HTTP request is made with a GET or a HEAD.
>
>
>
>

-- 

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

Mobile (text only) ...  +64 21 261 89 81
Email   mich...@binarykitchen.com
Website ..  http://www.binarykitchen.com

Re: [whatwg] HTTP status code from JavaScript

[Karl Dubost]

Michael,

A praise for more than HTTP status code.

Le 23 mai 2014 à 12:36, Michael Heuberger  
a écrit :
> There is a need to obtain the HTTP status code for the page itself from
> JavaScript:
> https://bugzilla.mozilla.org/show_bug.cgi?id=999886


We could do better. HTTP Code is yet another very specific bit of information.
A question which is very often asked is how to access the HTTP headers from 
JavaScript without having to go through a round trip of XMLHttpRequest.

http://stackoverflow.com/questions/220231/accessing-the-web-pages-http-headers-in-javascript

I wish indeed that in the DOM there would be a way to access a JSON object with 
the full HTTP response headers and status line included.

One of the reasons to record the full response instead of having to create an 
additional request is that some headers are time sensitive and some servers are 
very sensitive to the type of requests made. For example, some servers will 
(wrongly) send a different response for headers and/or status line if the HTTP 
request is made with a GET or a HEAD.




-- 
Karl Dubost 🐄
http://www.la-grange.net/karl/

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Thanks heaps!

On 26/05/14 12:29, Silvia Pfeiffer wrote:
> You might want to review http://wiki.whatwg.org/wiki/FAQ .
>
> In particular: 
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
> HTH,
> Silvia.
>
>
> On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger
>  wrote:
>> Hi Jasper
>>
>> On 26/05/14 08:09, Jasper St. Pierre wrote:
>> * It is a redundancy. The browser already knows the status code, just
>> not JavaScript.
> That argument can equally well be used the other way round: it's a
> redundancy to expose in JS something that be easily exposed by the
> server.
 I understand your perspective but you cannot compare two entirely
 different things. Don't forget that most modern web apps are 99% driven
 by JavaScript. If the server returns a 404, JavaScript is still unable
 to read the initial HTTP status code. Think about it :)

>>> The web server sends you back a response. It first sends the response code,
>>> then the response headers, then the response body.
>>>
>>> If you can alter the response code from the server, why can't you alter the
>>> response body?
>> I know that my dear :)
>>
>> Whatever we alter on the server, Javascript on the client-side is still
>> unable to read the HTTP status code.
>>
>> I already mentioned in earlier emails that altering the response body is
>> a redundancy. The information is already in the header.
>>
>> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Silvia Pfeiffer]

You might want to review http://wiki.whatwg.org/wiki/FAQ .

In particular: 
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

HTH,
Silvia.


On Mon, May 26, 2014 at 10:02 AM, Michael Heuberger
 wrote:
> Hi Jasper
>
> On 26/05/14 08:09, Jasper St. Pierre wrote:
>>
>>>
> * It is a redundancy. The browser already knows the status code, just
> not JavaScript.
 That argument can equally well be used the other way round: it's a
 redundancy to expose in JS something that be easily exposed by the
 server.
>>> I understand your perspective but you cannot compare two entirely
>>> different things. Don't forget that most modern web apps are 99% driven
>>> by JavaScript. If the server returns a 404, JavaScript is still unable
>>> to read the initial HTTP status code. Think about it :)
>>>
>> The web server sends you back a response. It first sends the response code,
>> then the response headers, then the response body.
>>
>> If you can alter the response code from the server, why can't you alter the
>> response body?
>
> I know that my dear :)
>
> Whatever we alter on the server, Javascript on the client-side is still
> unable to read the HTTP status code.
>
> I already mentioned in earlier emails that altering the response body is
> a redundancy. The information is already in the header.
>
>>
> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi Jasper

On 26/05/14 08:09, Jasper St. Pierre wrote:
>
>>
 * It is a redundancy. The browser already knows the status code, just
 not JavaScript.
>>> That argument can equally well be used the other way round: it's a
>>> redundancy to expose in JS something that be easily exposed by the
>>> server.
>> I understand your perspective but you cannot compare two entirely
>> different things. Don't forget that most modern web apps are 99% driven
>> by JavaScript. If the server returns a 404, JavaScript is still unable
>> to read the initial HTTP status code. Think about it :)
>>
> The web server sends you back a response. It first sends the response code,
> then the response headers, then the response body.
>
> If you can alter the response code from the server, why can't you alter the
> response body?

I know that my dear :)

Whatever we alter on the server, Javascript on the client-side is still
unable to read the HTTP status code.

I already mentioned in earlier emails that altering the response body is
a redundancy. The information is already in the header.

>
 * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi Qebui

On 26/05/14 05:16, Qebui Nehebkau wrote:
>
>> Tell me a good reason why JavaScript should NOT have access to the
>> status code?
>>
> There's always a good reason not to add new things. Call it inertia; every
> new feature starts at -100 points. Something like this, which gives you
> information you should already know and is only helpful when you've already
> made some seriously questionable design decisions, probably shouldn't ever
> overcome that initial deficit. Of course, that's just my opinion, but I
> have a feeling I'm not the only one.

That's an interesting point of view and I might agree with it for some
issues.

But not this one. Javascript does not have the information, the HTTP
status code, we already know (in the HTTP header). To be correct,
JavaScript is unable to read the HTTP header. The information is already
there, just not "accessible".

The browser scans the HTTP header. Why not pass it along to JavaScript?
IMO this is not really "adding a new thing" but "opening a door".

Michael

-- 

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

Mobile (text only) ...  +64 21 261 89 81
Email   mich...@binarykitchen.com
Website ..  http://www.binarykitchen.com

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi David

>>>
 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).
>> Yeah, each framework has it's own way - nevertheless, Angular is very
>> popular these days.
> "these days" is not an argument. We're discussing an addition to the
> web platform and as we know, things are hard to remove after they've
> been added [1]. Frameworks come and go, the platform stays (so far at
> least)

Exactly. The platform stays. That's why I do not want to hack the HTTP
status code inside the meta tags through my framework.

What I meant with Angular's popularity is that JavaScript and SPAs are
popular.

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

>
>> 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 (?)
>> Yes like a bookmark. And that's a case where it would be great to read
>> the HTTP status code from JavaScript.
> Continuing the argument from above, the bookmark is to a specific URL
> and so, for the sake of bandwidth and UX, you should be serving
> different content for different URLs, so you don't need the HTTP
> status code

Huh? For some you might be right but you probably have missed out the
architecture of my case in 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi Tobie

On 26/05/14 00:51, Tobie Langel wrote:
> On May 25, 2014, at 13:48, Michael Heuberger
>  wrote:
>
 * It is a redundancy. The browser already knows the status code, just
 not JavaScript.
>>> That argument can equally well be used the other way round: it's a
>>> redundancy to expose in JS something that be easily exposed by the
>>> server.
>> I understand your perspective but you cannot compare two entirely
>> different things. Don't forget that most modern web apps are 99% driven
>> by JavaScript.
> That's data's made and far from the truth. :-)

Okay, I do not know the exact percentage but it is definitely a very
high number. All I wanted is to emphasize how important JavaScript is
these days. Getting more and more popular.

>
>> If the server returns a 404, JavaScript is still unable
>> to read the initial HTTP status code. Think about it :)
> How so? What prevents the server from adding a 404 status code in HTML markup?

I already explained this in a previous email. Should I repeat it here?
In short: it's a redundancy when the same information is already sent in
the HTTP header.

>
 * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Jasper St. Pierre]

On Sun, May 25, 2014 at 7:48 AM, Michael Heuberger <
michael.heuber...@binarykitchen.com> wrote:

> Hi Tobie
>
> >> * It is a redundancy. The browser already knows the status code, just
> >> not JavaScript.
> > That argument can equally well be used the other way round: it's a
> > redundancy to expose in JS something that be easily exposed by the
> > server.
>
> I understand your perspective but you cannot compare two entirely
> different things. Don't forget that most modern web apps are 99% driven
> by JavaScript. If the server returns a 404, JavaScript is still unable
> to read the initial HTTP status code. Think about it :)
>

The web server sends you back a response. It first sends the response code,
then the response headers, then the response body.

If you can alter the response code from the server, why can't you alter the
response body?


> >> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Qebui Nehebkau]

On Sun, May 25, 2014 at 8:34 AM, Michael Heuberger <
michael.heuber...@binarykitchen.com> wrote:

> Tell me a good reason why JavaScript should NOT have access to the
> status code?
>

There's always a good reason not to add new things. Call it inertia; every
new feature starts at -100 points. Something like this, which gives you
information you should already know and is only helpful when you've already
made some seriously questionable design decisions, probably shouldn't ever
overcome that initial deficit. Of course, that's just my opinion, but I
have a feeling I'm not the only one.

Re: [whatwg] HTTP status code from JavaScript

[David Bruant]

Le 25/05/2014 14:04, Michael Heuberger a écrit :

Bonjour David

On 25/05/14 23:33, David Bruant wrote:

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

Yeah, each framework has it's own way - nevertheless, Angular is very
popular these days.
"these days" is not an argument. We're discussing an addition to the web 
platform and as we know, things are hard to remove after they've been 
added [1]. Frameworks come and go, the platform stays (so far at least)



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.



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 (?)

Yes like a bookmark. And that's a case where it would be great to read
the HTTP status code from JavaScript.
Continuing the argument from above, the bookmark is to a specific URL 
and so, for the sake of bandwidth and UX, you should be serving 
different content for different URLs, so you don't need the HTTP 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?

By that argument, an absurd amount of features should go in ;-)

Really? How many "absurd amount of features" do you guys get every day?
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296902.html 
? This suggestion is mostly harmless, but doesn't really add value in my 
opinion.
I am less active on standards mailing-lists these days, so I cannot 
count, but others will know better.



 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.

Ummm, I am not sure if I can follow you. What 

Re: [whatwg] HTTP status code from JavaScript

[Tobie Langel]

On May 25, 2014, at 13:48, Michael Heuberger
 wrote:

>>> * It is a redundancy. The browser already knows the status code, just
>>> not JavaScript.
>> That argument can equally well be used the other way round: it's a
>> redundancy to expose in JS something that be easily exposed by the
>> server.
>
> I understand your perspective but you cannot compare two entirely
> different things. Don't forget that most modern web apps are 99% driven
> by JavaScript.

That's data's made and far from the truth. :-)

> If the server returns a 404, JavaScript is still unable
> to read the initial HTTP status code. Think about it :)

How so? What prevents the server from adding a 404 status code in HTML markup?

>>> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Bonjour David

On 25/05/14 23:33, David Bruant wrote:
> 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).

Yeah, each framework has it's own way - nevertheless, Angular is very
popular these days.
>
>> 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).

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.

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

Huh, 0ms? Database queries take some time ...

... but that's not the issue here. Let's stick to the topic please :)

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

No problem, you couldn't know before that I am Deaf. Thanks, will study
these slides tomorrow.

>
> 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 (?)

Yes like a bookmark. And that's a case where it would be great to read
the HTTP status code from JavaScript.
>
>> 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi Tobie

>> * It is a redundancy. The browser already knows the status code, just
>> not JavaScript.
> That argument can equally well be used the other way round: it's a
> redundancy to expose in JS something that be easily exposed by the
> server.

I understand your perspective but you cannot compare two entirely
different things. Don't forget that most modern web apps are 99% driven
by JavaScript. If the server returns a 404, JavaScript is still unable
to read the initial HTTP status code. Think about it :)

>> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[David Bruant]

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 URL

Re: [whatwg] HTTP status code from JavaScript

[Mathias Bynens]

On 25 May 2014, at 09:58, Tobie Langel  wrote:

> 
>> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Tobie Langel]

Hi again,

On May 25, 2014, at 9:35, Michael Heuberger
 wrote:

> * It is a redundancy. The browser already knows the status code, just
> not JavaScript.

That argument can equally well be used the other way round: it's a
redundancy to expose in JS something that be easily exposed by the
server.

> * Adding inline JS 

Re: [whatwg] HTTP status code from JavaScript

[Michael Heuberger]

Hi Tobie

I've been thinking about that too before but IMO this is not clean for a
two reasons:
* It is a redundancy. The browser already knows the status code, just
not JavaScript.
* Adding inline JS  slows down the page load.

Believe me, I have asked many web developers around the globe, tweeted
about my idea and contacted Mozilla. Everyone thinks this would be a
great addition to JavaScript and there were no objections.

Tell me a good reason why JavaScript should NOT have access to the
status code?

On 25/05/14 19:09, Tobie Langel wrote:
> On May 25, 2014, at 8:59, Michael Heuberger
>  wrote:
>
>> 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.
> Why can't you just set that value server-side (e.g. In a meta tag or
> even using a script tag) and retrieve it on the client? E.g. In pseudo
> PHP:
>
>