Larry Garfield commented on a post on Blogger.
I suspect much of the issue has to do with variable use cases.  For the canonical "personal blog" example, the Rails-style pseudo-MVC does actually work fairly well.  (It's not MVC, as you said and as I've said before (, but it does get the job done.)  It also can mostly work for the "easy" parts of a semi-REST app.  (I say semi-REST for a reason.)

In short, pseudo-MVC demos really well. :-)

For some applications, that IS enough.  Any other parts of the application can be squeezed in without too much cognitive dissonance.  If all you're doing is CRUD on blogs and an index page, then you're fine.

But different types of application require a different architecture.  (I know this will come as a shock to a lot of people...)

Too, the language makes a difference.  PHP, for instance, is a shared nothing language design (at least when using mod_php), so the "rebuild on each load' cost is fairly high.  That means state is very CPU expensive.

If, however, you're using a persistent PHP process (via React PHP or similar) or a naturally persistent language like Go or Java, the performance characteristics are quite different.  It's OK to have more expensive-to-load objects and services because they can stay memory resident.

Really, the answer to "what architecture should I use / is best?" is always, always "it depends".  Architecture can vary widely, as long as it's deliberate.  The architectural monoculture that has gripped the web dev world since Ruby on Rails came on the scene is quite harmful.
Shared publiclyView activity