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.
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.
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.
[+] [-] Jare|13 years ago|reply
- 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!
[+] [-] SoftwareMaven|13 years ago|reply
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.
[+] [-] mixu|13 years ago|reply
[+] [-] anujkk|13 years ago|reply
[+] [-] CWIZO|13 years ago|reply
So does anyone here know how to deal with this (using adsense on single page apps)?
As for the book, I've read the first intro chapter and it looks promising, will definitely read it later.
[+] [-] polyfractal|13 years ago|reply
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.
[1] https://developers.google.com/adsense-for-ajax/ [2] http://www.google.com/dfp/info/sb/faq.html [3] http://www.adzerk.com/
[+] [-] mise|13 years ago|reply
One close to this implementation that caught my eye this week for its design is http://deploybutton.com/
[+] [-] ubershmekel|13 years ago|reply
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).
[+] [-] brador|13 years ago|reply
[+] [-] polyfractal|13 years ago|reply
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.
As an example, this is my project: http://comparerc.com
And here is an example product page within my site: http://comparerc.com/#!/product/84869/pnp-micro-p-51/
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.
[+] [-] uptown|13 years ago|reply
[+] [-] cowsaysoink|13 years ago|reply
[+] [-] lobo_tuerto|13 years ago|reply
http://news.ycombinator.com/item?id=4172837
(How comes it's the same URL and it didn't get detected as a duplicate?)
[+] [-] 2color|13 years ago|reply
I saw that there is a big focus on modularity, how come there is no talk about why use the commonJS and not AMD?
[+] [-] mattrandle|13 years ago|reply