[Millennium]

It depends on what you're trying to do. The server-side breaks down into MVC readily: you have a database or set of files or some more exotic data store as a model, the HTML/CSS/JS/whatever that gets sent to the client as a view, and your middleware as the controller.

When you do this, then by the time you get to the browser, you're already working in the view. But does it make sense to break the view down into its own model, view, and controller? If you're dealing with a page as a monolithic blob of text, then probably not, and there are cases where it makes sense to do that.

But not all content can be treated as monolithic blobs of text. You mention journalism, but it is not at all uncommon in journalism to have to present some form of raw data to the user -charts, tables, and such- even if that data is just a summary of some other data. MVC is well-suited to that task, perhaps as a series of data presentation widgets within the site. But even blobs of text are not always monolithic. One example that comes readily to mind is also pertinent to news sites: comments. If you need to manipulate comments on a page, then that's another case where MVC could come in handy.

The bottom line is that it depends on what you want to do to the site. Monolithic blobs of text don't require MVC, if that's really all you're handling, but is that all you're handling? Maybe, but maybe not.

[bladedev]

I think that is exactly it, content heavy websites are no longer just pulling blobs of text out of the database and dumping them on a static page. Even traditional content websites are becoming 'applications'. The lines are blurring and therefore choosing the right tool for the job becomes more challenging.