I'm actually kind of tired of sites that just give a stream of data.<p>That's why on all my projects going forward, I'm going to try to take the next step and design the page itself to be attractive as to the placement of the content---more like a magazine, than like a Reddit.
This post seems a little naive. yes, people spend a lot of time on things like Facebook, Twitter, Google+ etc. However, that's only half the story. People also use search engines to find information. Information that is organised in pages, e.g. Wikipedia or Amazon. Streams are fluid. Information is there and gone the next. Pages and streams serve two different purposes and one does not exclude the other.
It's interesting that in a "blog about making culture" that he doesn't address the issue of archival. While a CMS can produce a nice snapshot for archive.org or another mirror to capture, streams are trickier, especially if they rely on the app that produced the stream(s) to work.
Streams are not always the best solution. How do you get an item at the end of the stream? By scrolling for minutes and hoping your browser doesn't crash...<p>It's a model very well-suited to social publishing, immediate content, not so for articles/timeless information.
There is no doubt in my mind that streams will be a much bigger part of the future than they are now. (They won't completely replace page-based content where that is more appropriate.) Currently streams seem to be the domain of the big 'platform' players (Twitter, Facebook, Instagram, maybe a feedreader for those so inclined) so I am only really have to 'keep tabs' on a couple of streams.
I think our current tools for creating and consuming streams are still relatively basic and for 'streams' to break free from these strongholds requires a lot more innovation in how we can create them, interact with them, manipulate them and transition in and of of them seamlessly.
Streams are more an attitude shift to match how people consume content than a substantial functional shift. They still allow for permalinks; it's possible to link to any tweet directly. Stream-oriented content is about acknowledging that pages and destination sites are the wrong units of content. Content needs to respond to platforms — more than just screen sizes. Content Management Systems need to be treated as true <i>content</i> management systems, not <i>page</i> management systems. Content == data. See: John Borthwick's comments on content as information; Substance.io and Prose; Medium; NPR's API; &c. Pages are a legacy format.
Streams allow people to find/stumble across information they may not have known existed. A visitor could enter (site) with a permalink to the content and then find a zillion spinoff conversations/articles - rather than forcing them to search or use poor navigation by the site owners, they could now spin themselves around the web based on streams of content... Love the idea!
Related reading: "Streams vs. documents" -- <a href="http://web.archive.org/web/20100108034547/http://software-libre.rudd-o.com/Streams_vs._documents" rel="nofollow">http://web.archive.org/web/20100108034547/http://software-li...</a>
The OP took a reasonable idea: stop shoehorning content systems into producing static HTML <i>pages</i> (and instead, produce an API)...and jumps somewhat illogically to "make it all a stream!"<p>Why isn't it possible to create an API which you dogfood to produce static pages (because permalinks are nice) AND content for streams?