I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the s

I'm by no means a fan of PHP, but the author does have a point that it's essentially an ad-hoc templating system which lets you glue your own framework on the spot. Obviously it becomes a mess eventually, but it may be useful for small projects where you want to develop rapidly with minimal dependencies, or as a sort of Mozart coding philosophy. You'd be surprised how un-messy it can be if you remove any arbitrary directory structures and arcane framework code. A big part of making this work for me has been the adoption of "Template Animation"[1] (or DOM templating whatever you'd like to call it) which does away with the need for the server side code to "build" the interface. Once you get rid of that, and provide an easy way for things to be split up and organised into classes, and if you avoid anything too far removed from "pure" PHP, it's really quite easy for anyone to come along and see what's going on. Of course it gets messy if you let it get messy, though ;) I actually think it'd be very refreshing if we got more frameworks that aren't based on MVC, which instead simply give you some APIs and let you use them as you see fit. I know there are some, but they're not widespread. Although you could essentially just grab a bunch of libraries and that'd be equivalent. That's basically where I landed. My applications now are a bit of boilerplate configuration and a bunch of folders with class files in them, that I either write or get from somewhere else. Because the interfaces are built completely in static HTML anyway you don't get all this mess to do with where to store your "assets" and how to structure your views/templates. [1]http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you http://www.workingsoftware.com.au/page/Your_templating_engin...