The MicroPHP Manifesto

The MicroPHP Manifesto
funkatron.com

I am glad Ed/Funkatron is forging ahead and voicing these concerns and suggestions nonetheless. As a PHP dev, I look over the fence at python & ruby examples and wonder why my application/framework is so complex and ugly (obv. examples and production applications are apples and oranges, but the contrast is stark). I hear "PHP is supposed to be ugly." Seriously? This is a selling point?

It's good to hear others call attention to these issues and suggest a path forward that keeps PHP competitive with other languages on the web.

The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -> "" The second way is to "refuse complicated frameworks" and write an application with a framework inside. This is what most people do, but believe that they aren't using a framework because they didn't download one. But, the same problems come up again and again: rendering data, handling AJAX requests, building database queries, managing users and passwords, the list goes on forever. When you do a half-assed job of handling this stuff right in your application code, you're using a framework. It's just a bad one. You had to write it from scratch, it's not well-tested, and you can't reuse it.

A third option is to use well-written libraries (or frameworks) to manage the implementation complexity, leaving your application as a concise shell around the core components. This means your application code only describes the problem that your application is trying to solve. The dirty work of dealing with the real world (HTML, JSON, SQL, etc.), is all handled in other code. (You can write this yourself, of course; you just have to understand that JSON parsing is not what your application does, and when you want to write that code, you need to "switch gears" and implement it outside of your application du jour. And sometimes, "you" is not you, it's someone else on the Internet.)

This article suggests that you eschew option three in favor of option one or two, because the code is "less beautiful". I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work.

The third strategy may feel unclean because you did not get to fully control every aspect of the interface and implementation. But most of the time, that doesn't matter. Yes, you'll have to do some configuration. Configuration is easier to test and maintain than the logic that you're configuring, and that means your application is actually simpler. The world is complicated. Your software doesn't have to make it more complicated.

Reading "quick" start tutorials like this (http://packages.zendframework.com/docs/latest/manual/en/zend...) is just depressing, and it's a big reason why droves of developer continue the exodus to other languages. PHP libs and frameworks should not emulate Java.

Sometimes I think PHP needs a _why to add some whimsy to the community and encourage people to break the mould, but they'd probably be dismissed as someone who "doesn't understand design patterns" or some other BS...

Thank you for writing this.