Devlopr | Jayesh Kitukale's Bold Blog

It’s a good idea to read this before reading further.

Most frameworks rely on the Hollywood principle: Don’t call us, we will call you! This is the root of all the problems. The classic MVC pattern is a great tool, but it is almost always implemented in conjunction with the Hollywood principle (Technically called IOC = Inversion of Control).  This post explains a simple no-framework paradigm.

Based on the theory above, here is what I mean by a no-framework:

1. By all means, follow MVC pattern using either classes or simple file includes. Three different files for M, V and C. (Model, View and Controller) to separate the code into 3 logical parts for easy readability and maintainability (no more separation than this is really required).
2. Include the necessary files in your view file as necessary and call the necessary functions at the top of the view file (this is slightly against MVC pattern because although small amount but some code from controller has crept in the view file) but never mind its simple to understand and teach (The MVC pattern is for us, we are not for the pattern). So it is good to modify a few concepts to fit the needs (Remember we are engineers with limited budgets and unlimited creativity and not scientists with unlimited budgets). Our target is to produce a usable product (forget about reusability – have you ever reused your view/models or controllers?) that is readable and maintainable (and also scalable).
3. Use the “tile pattern” to implement the common parts of the web pages (header, footer, left, right, sidebar, etc.) Put them in separate files and include them where necessary. Most frameworks would not need you to include such things because they hide this from the developers but what is the point in hiding things that are going to ultimately be there? So a framework forces you to “see” what is not visible making it very difficult to understand for a new user. With our no-framework you will not need to imagine things – just keep simple principles in mind.
4. Since there is no Hollywood overhead involved in our no-framework we have a scalable architecture because all we have is the overhead of PHP language itself – no more, no less.
5. Now the advanced questions remain: What about Caching, Multilanguage support and other features that come free with the frameworks? The answer is simple: Learn those things (full stop). Implement them in your code (full stop). Learning these things is good for your health and also inevitable sometime in the future when your framework bites you (and when it is too late and difficult to dig through the framework to fix the weird issues). There is no escape, better face it from the beginning than shying away behind the complicated frameworks that promise great dreams in their feature list.

A few notes: The author is not against the frameworks which have worked great miracles in desktop and mobile applications arena because the interaction between objects is more complicated in those applications and the framework overhead is reasonably acceptable considering the great advantages offered. But this does not hold true in case of the web applications because of the very nature of the way HTTP protocol works. The protocol is simple and so the applications need not be complicated. Show me the most complicated page on the web (a webpage is always simple – it is either a form or a list of records or a simple combination of them). With one web request there is a simple cycle involved from request to the final HTML output delivered to the browser. KISS!

The best frameworks reside in the minds of the developer!