PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

My take on the MicroPHP manifesto buzz

Note: This article was originally published at Planet PHP on 11 January 2012.
Planet PHP

Ed's recent blog post labeled the The MicroPHP Manifesto got a lot of attention. Personally I feel like Ed's way of expressing himself feels mostly like the rants of an angry person and not really a way of expressing a clear message. That is why I appreciate a much saner formulated follow up by Kris Jordan. In general I totally agree with Ed on the point that we need more decoupled components in the PHP world. The timing seems a bit odd since exactly that seems to be an emerging trend with all the various libraries cropping up since PHP 5.3. Where he looses me is with his seeming obsession with LOC minimization. It sounds to me like he assumes that any 3rd party code he pulls in, he automatically also has to maintain. To me that seems a bit odd. Obviously any 3rd party lib might contain bugs, which one might need to debug. But when choosing a 3rd party lib I focus on seeing if I trust the development team. I apply metrics such as track record, existing tests and documentation (oh and don't forget license). And of course I also browse the code and the response time and attitude in the bug tracker. If I hit an issue I do expect to be able to fix it myself if necessary, but in most cases I will just do my best to file a bug report with steps for how to reproduce the issue. Obviously being somewhat known in the PHP community for doing my share, I might be getting slightly better response times than most devs. But I still do not see how LOC in a 3rd party lib need to be a criteria for how hard it will be to maintain said dependency.

That part aside I would also like to comment a bit on micro vs. full stack frameworks. I don't have a perfect definition of either framework handy but I guess the main difference is that a micro framework aims to keep the number of out of the box supported use cases to an absolute minimum, while a full stack framework aims to cover a very broad sets of use cases. Traditionally micro frameworks also seem to have a much higher code to configuration ratio compared to full stack frameworks. Aka implement a certain behavior with a micro framework one usually needs to write code, while in a full stack framework quite a few things can be achieved by configuration alone. Furthermore full stack frameworks also define much more conventions (f.e. directory structures) and high level extension points (f.e. authentication and permission).

As a result to me the use case of micro frameworks is mostly in cases where I have very little business logic on the server. For example think of an application that basically just provides an API to fetch json data structures that map more or less 1:1 to some externally mapped database using some javascript MVC framework like Backbone.js for the actual business logic. However as soon as I have business logic on the server side I tend to prefer a full stack framework. The main reason is that I work at a web agency usually with team sizes of at least 5 developers but often more. Also the team compositions often change too. Furthermore frequently we integrate additional developers from the client. Here it is absolutely vital we do not waste time figuring out details such as directory structures. Furthermore many projects tend to have a lot of very similar requirements but rarely exactly the same. With the approaches that Ed and Kris seem to be describing, especially using (anonymous) functions I will find myself copy pasting code around to adapt it to specific needs of each project. This will require additional time and will obviously lead to a maintenance nightmare as this way I will end up maintaining more rather than less code.

If I gather things properly for Ed the situation is very different. He works on a set of products for his employer with a more or less fixed team. As such they can make sure that their solutions match exactly the current range of use cases. Furthermore the team will develop a set of implicit conventions and styles that will ensure consistency. They will likely have the chance of incrementally going over older, but still profitable, products to update them to their latest conventions. This way its way more feasible for them to keep the number of required extension points to a bare minimum, because they have much more control over their current and future use cases. If they decide to use an anonymous function as an extension point, we are maybe talking about 2-3 different uses. Where as if I in a web agency design an extension point I expect 10-20 uses at least, by people in different teams. But as a web agency that believes in OSS we also release as much code as our clients let us, so the number of different use cases can grow to 100 or even more. Btw the situation is quite similar for companies that have large development teams spanning multiple offices or companies developing products t

Truncated by Planet PHP, read more at the original (another 604 bytes)