This looks very interesting, but I have a few comments from the introduction:
- Single-page apps offer a more native-app-like experience, but there's no reason they must throw away the advantages of web over app. Almost any conceivable app is going to have different top-level states, and many apps are going to let you access different pieces of content. Support URLs to go directly to those states and to those pieces of content for two reasons: ability to be linked / indexed from outside, and navigability via the browser history. I believe the correct way to look at this is to explicitly think of these top-level states/content, and then look at supporting them in a URL, not the other way around that you suggest ("we probably need to reduce the level of detail that we support in URLs somewhat").
- The MVC pattern predates web apps, web sites and the www itself. The thing I always found shocking was that server side apps, not client, used the pattern at all. That said, getting rid of controllers altogether due to the myriad approaches and variants that exist out in the wild is a sensible idea.
Many thanks for taking the time to write this book!
I completely agree with the MVC thing. It always felt forced and unnatural for page-based web applications, so it was disconcerting to see controllers getting railed on as inappropriate to single-page apps because they were dragged down to the client from the server world.
However, while I think the incorrect history should be ripped out of the book (if for no other reason than there are people who will write off the book because of the inaccuracy), I've always felt that the controller part of MVC wasn't defined explicitly so much as surveyed to see what was left after the model and view, so I'm ok with the book not liking it.
It has surprised me for many years that we haven't found an architecture better than MVC for apps, because I've never been comfortable with any controller code in any app I've worked on.
Nice one. I printed it to a pdf file to be read later. I would like to know what are other resources to learn about single page web app development? I'm looking for a book/tutorial that can explain it through some example projects. Are there any good books that uses angular.js/backbone.js/ember.js etc to teach single page app development?
You can, but you will only be able to show the ads that load on the first page. Google prohibits you from refreshing the ads without performing a full page refresh.
This made sense before AJAX, because people were simply refreshing ads every few seconds to increase impressions/clicks. But now with AJAX, there's no good way to get new ads.
Google has/had an "Adsense for AJAX" project...but no one has heard anything about it in ages. [1]
I've vaguely read that DFP Small Business from Google may let you refresh ads through AJAX, but I'm not certain. Would be an avenue to check into. [2]
Alternatively, you could just say "screw you google" and run something like Adzerk [3] on your site (which allows AJAX refreshing), but the problem is that you have to find and manage your own ad inventory.
I don't have any links, sorry. I just remember this from the time I looked into using Adsense for my own AJAX site. From what I recall, Google doesn't care if you load and display one set of ads, but as soon as you start refreshing the adsense snippet (via an iframe, or removing the divs and recalling the snippet), Google brings the banhammer down quickly.
The problem is you get bad first-page load times (double-latency), but you get better second-page load times (no waiting for templates, just data requests).
My side project is a single page JS application. It uses hashbangs because I want to support legacy browsers, but a lot of fancy new apps will just use HTML5 push-state to control the URL.
What this means is that your browser loads a single page (e.g. index.html) which loads a big chunk of javascript. That JS then handles all the state changes, content refreshing, URL changing, etc. So instead of querying the server for new pages as you navigate, the JS asks the server for you.
The advantage is that you (can) have lightening fast user interface and minimal data transfer between browser and server.
The URL is unique and lands on a unique "product", but all the code is generated from a single PHP page and a single chunk of JS. Despite that, Google has most of my product pages in it's index, just like any normal website.
I'm using Sammy.js (http://www.sammyjs.org/) which supports auto-fallback to hashbangs if HTML5 push-state isn't supported...I just haven't bothered to turn it on. Frankly, the hashbang doesn't really bother me at all, my URLs have a bunch of random parameters anyway (because it's a search engine) and Google is incapable of indexing either push-state or hashbangs without extra help.
So all it really does is remove two characters from the URL at the expense of more complexity and fragility.
Just because an app is single-page doesn't mean there's only a single URL. A single-page app can appear to have as-deep a set of URLs as any other site using HTML5 Pushstate or an alternate solution ... something essential to allowing the bookmarking distinct page-states, or indexing of your site's content.
I think you are mistaken cowsaysoik. You can have your single page app load any content requested by the URL. Single page doesn't mean landing page, it is used to refer to sites that work like apps. The page is only loaded once,a nd then portions of the page are changed based on the users request.
I'm not confused I use newsblur like an app but it is behind a landing page when not logged in (https://newsblur.com/). There are plenty of other examples, otherwise it would be quite hard to get new users to your service as they can't find what your app is about.
- Single-page apps offer a more native-app-like experience, but there's no reason they must throw away the advantages of web over app. Almost any conceivable app is going to have different top-level states, and many apps are going to let you access different pieces of content. Support URLs to go directly to those states and to those pieces of content for two reasons: ability to be linked / indexed from outside, and navigability via the browser history. I believe the correct way to look at this is to explicitly think of these top-level states/content, and then look at supporting them in a URL, not the other way around that you suggest ("we probably need to reduce the level of detail that we support in URLs somewhat").
- The MVC pattern predates web apps, web sites and the www itself. The thing I always found shocking was that server side apps, not client, used the pattern at all. That said, getting rid of controllers altogether due to the myriad approaches and variants that exist out in the wild is a sensible idea.
Many thanks for taking the time to write this book!