My thinking is that it takes a LOT of text to equal one good size pic. When using CouchDB as a backend, you want to optimize your queries so that you retrieve as much as possible in the fewest number of requests. With my current list of articles, I have this much data being requested in a single request to my map-reduce view: http://pokstad.com/db/_design/blog/_view/posts_chrono?includ...
That's about 33KB for 9 blog posts (not including attachments). So about 4KB per post. I could have a hundred articles and it would still be under half a MB. To put things into perspective, the cover photo of my pup is about 818KB. There are also numerous resource files, like JS, HTML, CSS that needs to be downloaded before the site will even be ready.
I agree. I am building something similar for a client but I am using node+mongo+backbone. I fetch the 'entire' site sans images and navigation is instant except I place loading anims where an image will show. Obviously not an architecture that suits all needs but very useful for a wide range of semi-static sites. In a way I feel this architecture is like the new 'flash': let the users wait for a bit while everything loads and then let them navigate very fast. (I also use require so some views may need adittional async loads like html templates or js but they are soooo small that the extra ms don't matter)
We're going to see this type of architecture more and more. Everyone keeps talking about this C10K problem, but the truth of the matter is that most consumer's computers are idling 99% of the time. The server only needs to be there as central storage and as an authority to authorize certain transactions.
That's about 33KB for 9 blog posts (not including attachments). So about 4KB per post. I could have a hundred articles and it would still be under half a MB. To put things into perspective, the cover photo of my pup is about 818KB. There are also numerous resource files, like JS, HTML, CSS that needs to be downloaded before the site will even be ready.