Re: [whatwg] HTTP status code from JavaScript
Le 26/05/2014 01:52, Michael Heuberger a écrit : 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). I am suggesting that you make a single request, not two. You're focusing on the HTTP status code, but in the end the code isn't important. Showing the relevant information to the user is what's important. The status code (client-side or server-side) is just a means to get there. What I'm proposing is to bypass the which status is it? part to get to the show the relevant information to the user part. 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. I wouldn't consider showing the right content (that the link is broken) to your users a hack. It is absolutely normal that URLs change or become invalid, hence the need for status codes. You know ... 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. My single page app works without the # part and uses absolutely normal-looking URLs to make it easier for search engine to spider it. Then why serving the exact content on every URL? I don't do that :) (I meant exact same) As far as the server is concerned, you're doing that. Otherwise, you wouldn't be needing for the HTTP status on the client-side. 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. Okay, I have a huge sign language video library here for Deaf people. Anyone can add / edit / delete stuff. Each video has an unique URL. When I load a page of a deleted video, a 404 is returned with the whole SPA code and additional stuff is rendered to deal with 404s in a nice way to improve usability. Here you have a real-world example and it is not a misusage of technologies. I still see a misuse of URLs. Why aren't you serving a different page for 404s? The perceived performance would be better for your users. Even if there is a way to read the HTTP status code, the user has to wait for: 1) the HTML + the SPA code to be downloaded 2) the SPA to read the HTTP status code, build the error page 3) display the error page If you serve a different content on 404, the user has to wait: 1) the HTML to be downloaded (which naturally displays the page) 2) (then, you can improve the experience with the JS code which downloads while the user is reading that they're on the wrong
Re: [whatwg] HTTP status code from JavaScript
David, you have very good points here. See below: ... 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). I am suggesting that you make a single request, not two. You're focusing on the HTTP status code, but in the end the code isn't important. Showing the relevant information to the user is what's important. The status code (client-side or server-side) is just a means to get there. What I'm proposing is to bypass the which status is it? part to get to the show the relevant information to the user part. I'd agree 100% with you with this approach if it were not a Single Page App. Showing the relevant information to the user is decided on the client-side of my code! Not on the server. Hence the client-side code aka Javascript needs to know the status code. That's my problem. 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. I wouldn't consider showing the right content (that the link is broken) to your users a hack. With hacks I meant smuggling the HTTP status code inside a meta tag. It is absolutely normal that URLs change or become invalid, hence the need for status codes. You know ... 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. My single page app works without the # part and uses absolutely normal-looking URLs to make it easier for search engine to spider it. Then why serving the exact content on every URL? I don't do that :) (I meant exact same) As far as the server is concerned, you're doing that. Otherwise, you wouldn't be needing for the HTTP status on the client-side. Oh no, I need it badly on the client-side. I raised a couple of examples and reasons in my earlier emails. 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. Okay, I have a huge sign language video library here for Deaf people. Anyone can add / edit / delete stuff. Each video has an unique URL. When I load a page of a deleted video, a 404 is returned with the whole SPA code and additional stuff is rendered to deal with 404s in a nice way to improve usability. Here you have a real-world example and it is not a misusage of technologies. I still see a misuse of URLs. Why aren't you serving a different page for 404s? The perceived performance would be better for your users. Even if there is a way to read the HTTP status code, the user has to wait for: 1) the HTML + the SPA code to be downloaded 2) the SPA to read the HTTP status code, build the error page 3) display the error page If you serve a different content on 404, the user has to wait: 1) the HTML to be downloaded (which naturally displays the page) 2) (then, you can improve the experience with the JS code which downloads while the user is reading that they're on the wrong page) Good summary! I've been thinking about this a lot before myself and tried it myself. I didn't decide for the latter method because I wanted to process / treat all the pages the same way (this is what I called above serving the exact same content on every URL) without exceptions to keep the code on the server side as simple as possible. And it would become too complicated and really bad. When the HTML is downloaded, then it is rendered and as long as the JS code is not ready, you are in an undefined state. Also, think of other things i.E. navigation elements which are totally JS driven. I'd have to add more hacks, bend my framework to make it work for this case and so on. Just too complicated and cost more at the end. I want to treat all the pages the same way with one code. This would work if the HTTP status code is readable from within
Re: [whatwg] HTTP status code from JavaScript
Yeah, something like that Austin. But like I mentioned, why add the status code inside the HTML code when it's already available in the HTTP status header? Hence I raised redundancy multiple times before. I could do that but not thanks. I still believe that JavaScript should be able to parse the HTTP status headers. Cheers Michael On 27/05/14 00:16, Austin France wrote: Hi from Random Observer Just trying to get my head around the requirement:- So we have an app that is served for any URL on the server (and so apart from the small html loader is only loaded for the initial request) and from that the server checks for the presence of the video and either returns a status 200 or 404 plus the app code which the javascript wants to use to display a video not available message or the video itself. The URI of the video presumably being derived from the URI of the page (not by anything passed by the server). The requirement is to be able to indicate to the app that the video does not exist in the initial request without requiring any additional informationt be passed to the client. Having the status code available to javascript though would obviously be ideal in this kind of setup, however as each URI is still returning some html and I think the meta tag or body attribute suggestions previously mentioned a completely acceptable way to solve this issue (or variation of), I see it as a minor overhead. html status=404 sort of thing. Regards Austin On 26 May 2014 12:09, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 26/05/2014 01:52, Michael Heuberger a écrit : 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,
Re: [whatwg] HTTP status code from JavaScript
I like the `window.http` idea mentioned earlier by Michael. Something like:
```js
window.http = {
url: window.location.href,
status: 404,
headers: {
/* ... */
}
};
```
If implemented, this would also be easy to polyfill in older browsers using
the duplicate AJAX request hack that Michael is using today (or a
server-side generated inline script block if you want guaranteed
correctness).
Sincerely,
James Greene
Sent from my [smart?]phone
On May 26, 2014 6:37 PM, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Yeah, something like that Austin.
But like I mentioned, why add the status code inside the HTML code when
it's already available in the HTTP status header? Hence I raised
redundancy multiple times before.
I could do that but not thanks. I still believe that JavaScript should
be able to parse the HTTP status headers.
Cheers
Michael
On 27/05/14 00:16, Austin France wrote:
Hi from Random Observer
Just trying to get my head around the requirement:-
So we have an app that is served for any URL on the server (and so
apart from the small html loader is only loaded for the initial
request) and from that the server checks for the presence of the video
and either returns a status 200 or 404 plus the app code which the
javascript wants to use to display a video not available message or
the video itself. The URI of the video presumably being derived from
the URI of the page (not by anything passed by the server).
The requirement is to be able to indicate to the app that the video
does not exist in the initial request without requiring any additional
informationt be passed to the client.
Having the status code available to javascript though would obviously
be ideal in this kind of setup, however as each URI is still returning
some html and I think the meta tag or body attribute suggestions
previously mentioned a completely acceptable way to solve this issue
(or variation of), I see it as a minor overhead. html status=404
sort of thing.
Regards
Austin
On 26 May 2014 12:09, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 26/05/2014 01:52, Michael Heuberger a écrit :
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.
Re: [whatwg] HTTP status code from JavaScript
Exactly :)
Thanks James!
On 27/05/14 14:06, James Greene wrote:
I like the `window.http` idea mentioned earlier by Michael. Something like:
```js
window.http = {
url: window.location.href,
status: 404,
headers: {
/* ... */
}
};
```
If implemented, this would also be easy to polyfill in older browsers using
the duplicate AJAX request hack that Michael is using today (or a
server-side generated inline script block if you want guaranteed
correctness).
Sincerely,
James Greene
Sent from my [smart?]phone
On May 26, 2014 6:37 PM, Michael Heuberger
michael.heuber...@binarykitchen.com wrote:
Yeah, something like that Austin.
But like I mentioned, why add the status code inside the HTML code when
it's already available in the HTTP status header? Hence I raised
redundancy multiple times before.
I could do that but not thanks. I still believe that JavaScript should
be able to parse the HTTP status headers.
Cheers
Michael
On 27/05/14 00:16, Austin France wrote:
Hi from Random Observer
Just trying to get my head around the requirement:-
So we have an app that is served for any URL on the server (and so
apart from the small html loader is only loaded for the initial
request) and from that the server checks for the presence of the video
and either returns a status 200 or 404 plus the app code which the
javascript wants to use to display a video not available message or
the video itself. The URI of the video presumably being derived from
the URI of the page (not by anything passed by the server).
The requirement is to be able to indicate to the app that the video
does not exist in the initial request without requiring any additional
informationt be passed to the client.
Having the status code available to javascript though would obviously
be ideal in this kind of setup, however as each URI is still returning
some html and I think the meta tag or body attribute suggestions
previously mentioned a completely acceptable way to solve this issue
(or variation of), I see it as a minor overhead. html status=404
sort of thing.
Regards
Austin
On 26 May 2014 12:09, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 26/05/2014 01:52, Michael Heuberger a écrit :
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
Re: [whatwg] I take back my request for this instead. SVG API
On Sat, 24 May 2014, Emanuel Allen wrote: SVG API for the canvas element, simple call svg; var ctx = canvas.getContext(svg); How would this work? Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
