The MicroPHP Manifesto
Real-world applications are complicated.  There are three ways to handle this problem.<p>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 -> "" <- is the easiest way to solve problem X.  It only fails in 100% of the cases, that's all.)<p>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.<p>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 <i>does</i>, 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.)<p>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.<p>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.