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