Hi Michael, On Sun, May 25, 2014 at 3:10 PM, Michael Heuberger <michael.heuber...@binarykitchen.com> wrote: > Hi David > > Interesting. Yes and no, I agree with some. See my comments below: > > On 25/05/14 06:53, David Bruant wrote: >> Le 23/05/2014 10:04, Michael Heuberger a écrit : >>>>> - Display a beautiful 404 page and hide parts of the navigation >>>>> - Reveal navigation history to give users a better usability >>>>> experience >>>>> during 404s >>>>> - And many more … >>>> I agree with those entirely but couldn’t they also be achieved by >>>> including the correct scripts on the 404 page issued from the server? >>> No, it is a single page app. All the HTML templates are on the client >>> side and loaded once during page load. And everything happens >>> dynamically. In other words: You load everything once, then there is no >>> further interaction with the server unless it's a specific query for >>> data or alters data in the database. >> "single page app" usually means that no interaction in a given page >> will trigger a navigation (as long as there is JavaScript. A good SPA >> will fallback to using links and forms if there is a problem with JS). >> It does not mean that all HTML templates are on the client nor that >> you serve the exact same thing for every URL be they 200s or 404s. >> That's an definitely an option, but it's one you impose upon yourself. > > I understand. Okay we could debate about the definition of SPA. For > fallbacks and special cases I deliver special files from the server when > JS is disabled. But I think the definition of SPA nor its special cases > are the main issue here. > > 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.
If you're creating your JS file on the server and pulling in all resources then, surely you can find out already at that time whether a piece is missing and can't be loaded? That's not a client side issue, but something that you'll need to deal with on the server. Silvia. > Also I mentioned earlier, PhoneGap is getting more popular and exactly > uses the architecture I have described. > > Again, I cannot emphasize how cool it would be to obtain the HTTP status > code from JavaScript! It would save SPAs and PhoneGap projects some > bandwidth. > >> 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. 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. > > This is better than letting the user wait about 700ms until the user > sees something on the screen. > >> 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 :( > >>> 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. > > 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? > > Cheers > 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 >