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 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 JavaScript.
That's the heart of the problem I believe. You trapped yourself into
some framework design choices and wish a change in the platform to
accomodate your current architecture; have the platform pay for your
technical debt in a way :-/
David
