[e12e]

Well, from the url:

http://blog.angularjs.org/2013/11/angularjs-120-timely-deliv...

I was expecting a) a blog post, and b) from the .html-ending a hypertext document, maybe with text and images?

What possible reason could there be for this to be "an app"? It's a blog, it's for reading -- and you already need a reader to access it -- why would you implement a (new) rendering engine?

Ok, I can see an argument for adding comments via javascript and a service, or for posting blog posts and doing admin stuff. But the other reasons (user tracking etc) for having this as "an app" only detracts from the readers experience.

[jessedhillon]

Its Blogger -- doing it this way allows them to cache the viewer across their thousands of blogs, and load only the content.

[e12e]

Well, if they just served html, they'd still only need to serve the content (and the viewer, the web browser, would indeed be cached in the form of an installed application on the end user's system).

[jessedhillon]

The content can be served as a JSON object containing just the post and the metadata. If you scale up to millions of requests, suddenly you're saving a lot of bandwidth by not sending the same header, sidebar, footer etc everytime.

[e12e]

1) You could send the sidebar, footer etc as json, and the content as html. [edit: an by json I mean javascript ;-) or a combination of a script-tag with a fancy-nav.js, and then pull in any additional elements via json/javascript urls]

2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.

[pandeiro]

Just send binary (that next?)