ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

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).

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 it is 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 that they expect will be customized by their clients. So imho frameworks such as Lithium and Slim mostly make sense for development teams of 5 or less developers working on in house SaaS applications that tend to have a large chunk of their business logic implemented in the client.

So the key take a way point is that when choosing to go micro or full stack its very important to consider in what kind of company on what kind of products you are working on. Unfortunately I have not seen any of the proponents of the MicroPHP movement discuss this aspect.

Comments



Re: My take on the MicroPHP manifesto buzz

Lukas,

You make an excellent point. The choice of framework really depends on project, client or customer, how many people are working on it and how, and how you are executing the project (lone developer, tightly knit group or corporate structure).

In addition focusing on Lines of Code was a big problem in Java too until frameworks like Spring came along, but even then there are wars on how to handle Inversion of Control and Dependency Injection (use getters/setters or constructor injection).

However I believe this is a sign of the maturity that PHP has attained and the need to attack the problems from the core.

Stephen

Re: My take on the MicroPHP manifesto buzz

I think something you might also be ignoring about the whole LoC subject is that some of the popular PHP frameworks and libraries, including Zend, Symfony and Doctrine, need a lot of code and configuration to get anything done.

At the moment Doctrine is frustrating me for this exact reason; it has no base class to either fake properties from the database using __set/__get and it also does not use __call to fake the setter/getter functions either. I finally went ahead and used the entity generator which created all the 'model' classes but without any stub methods, not even when I specifically told it to.

This to me reeks of the unnecessary and ugly complexity that I see in J2EE with it's redundant proxy classes for exposing beans, etc...

Re: My take on the MicroPHP manifesto buzz

Indeed thats a good point. Though its not mentioned microphp.org. Of course when using Doctrine in the context if a framework (micro or full stack) someone will usually have already gone through the trouble of setting up everything with sensible defaults and making it easy to customize those defaults. But yeah if you are doing your own thing, then indeed some of these tools can become quite a burden to get going.