My take on the MicroPHP manifesto buzz
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).
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)