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 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 :-/

I like that and totally agree. But I disagree that I am trapped myself
into a framework problem. I strongly believe that this could happen to
any framework that embraces the single page app architecture.

No, I would never ask the platform to pay for my technical debt.


PS: I am getting a bit tired of these emails. Don't get me wrong, I have
to work elsewhere to make a living - thanks for your understanding if I
sound a little tired but am grateful for your good comments that make me
think a lot.


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

Reply via email to