The MicroPHP Manifesto(funkatron.com)
funkatron.com
The MicroPHP Manifesto
http://funkatron.com/posts/the-microphp-manifesto.html
77 comments
Real-world applications are complicated.
Often, it's because people make them so. Often, it's because people recycle broken solutions instead of really thinking about what they're trying to do. Most code out there solves trivial problems, but is insanely complex. Web frameworks are especially bad at that.
Often, it's because people make them so. Often, it's because people recycle broken solutions instead of really thinking about what they're trying to do. Most code out there solves trivial problems, but is insanely complex. Web frameworks are especially bad at that.
Often, it's because the real world is complex.
"Deliveries are not made on Tuesdays, unless it falls on the 9th day of the month, but not in June for tax purposes in 2013, 2014 and 1998. Our Nowheresville office is excluded from the above rule."
You get rules like this. And there's reasons for most of them. Sometimes very good reasons.
Often, what simplifies a business process on the surface actually doubles (or worse) the underlying code. Because managers don't want you to throw away old data because it doesn't fit the new schema.
The "happy path" is always simple. And it tends to wind up being a fraction of the actual, evolved production code.
Unless you work in large organisations with long-lived systems, this will never be part of your worldview.
"Deliveries are not made on Tuesdays, unless it falls on the 9th day of the month, but not in June for tax purposes in 2013, 2014 and 1998. Our Nowheresville office is excluded from the above rule."
You get rules like this. And there's reasons for most of them. Sometimes very good reasons.
Often, what simplifies a business process on the surface actually doubles (or worse) the underlying code. Because managers don't want you to throw away old data because it doesn't fit the new schema.
The "happy path" is always simple. And it tends to wind up being a fraction of the actual, evolved production code.
Unless you work in large organisations with long-lived systems, this will never be part of your worldview.
Sure, there are complexities like that in the world. However, where programmer A writes an if-else statement or, maybe, a 5-line dynamic dispatch, programmer B installs some "enterprise" framework or a rules engine, instantly making the entire system an order of magnitude more complex.
What programmers like B often doesn't realize is that they push core logic of the application from their source code (Turing complete, expressive, versioned, benefiting from static and dynamic analysis and all the testing/refactoring tools available for the language) into an obscure XML notation or even some proprietary rules database, worked upon by a complicated blob of 3d party code that has nothing to do with the original business problem.
What programmers like B often doesn't realize is that they push core logic of the application from their source code (Turing complete, expressive, versioned, benefiting from static and dynamic analysis and all the testing/refactoring tools available for the language) into an obscure XML notation or even some proprietary rules database, worked upon by a complicated blob of 3d party code that has nothing to do with the original business problem.
Well we're talking about different things, now. Per Brooks, I was talking about essential complexity, you're talking about accidental complexity.
The point is that in web frameworks, the two are often confused or at least blurry. So we need to extend the essential/accidental dichotomy to deal with global versus local views.
Take for example parsing emails. In a universal sense the complexity is accidental, it arose from the technology decisions of the authors of RFC822 (which partly arose from previous decisions).
But locally, for a web programmer, the email address format is an immutable, irreducible fact of reality. I can no more wish away that complexity than I can wish myself a million dollars. To me it is an essential complexity.
Where web frameworks of the entirely-made-out-of-code variety really shine is in facing up to these locally essential complexities. It may seem superfluous now. It may not seem so in six months.
The point is that in web frameworks, the two are often confused or at least blurry. So we need to extend the essential/accidental dichotomy to deal with global versus local views.
Take for example parsing emails. In a universal sense the complexity is accidental, it arose from the technology decisions of the authors of RFC822 (which partly arose from previous decisions).
But locally, for a web programmer, the email address format is an immutable, irreducible fact of reality. I can no more wish away that complexity than I can wish myself a million dollars. To me it is an essential complexity.
Where web frameworks of the entirely-made-out-of-code variety really shine is in facing up to these locally essential complexities. It may seem superfluous now. It may not seem so in six months.
I find that when I work with a framework for a while, I do start to understand it very well. I find myself looking at the implementation more and more as I learn the subtleties about how it is written. After a while I start to feel as familiar with it as code I have written myself, if not more so because I interact with it so often. At that point, it's basically free code. You get the benefit of all those lines of code, but you get to outsource a lot of testing, debugging and development.
In short, after working with the framework a little, I have thousands of lines of code that are better tested than my application, better vetted by more programmers, and many edge cases handled I might not even realize I have. I might only use half the code, but I'm glad it's all there, and I'm glad I can focus on getting down to work instead of writing yet another framework.
In short, after working with the framework a little, I have thousands of lines of code that are better tested than my application, better vetted by more programmers, and many edge cases handled I might not even realize I have. I might only use half the code, but I'm glad it's all there, and I'm glad I can focus on getting down to work instead of writing yet another framework.
I mostly agree with you, but a program that fails on uncommon cases is not a complete failure. I mean, do all your websites work with IE 5.5?
"I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work."
I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework?
I think one of the points that isn't clearly enough articulated in this article, but is very significant for me, is code understandability. Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical. So the idea being suggested is allow people to switch out tools one by one rather than start over with a new, incompatible set if they need some lower level change.
What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP. I don't think anyone's saying "down with frameworks" as much as "hey, let's get some do-one-thing-well tools as well, so the piecemeal/modular option is also there."
I agree that for big jobs, you can't prioritize pretty over featureful, but, respectfully, I think you are overstating your point here: "doesn't ever work." That's simply not true. Have you really never written a working program without a full featured framework?
I think one of the points that isn't clearly enough articulated in this article, but is very significant for me, is code understandability. Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical. So the idea being suggested is allow people to switch out tools one by one rather than start over with a new, incompatible set if they need some lower level change.
What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP. I don't think anyone's saying "down with frameworks" as much as "hey, let's get some do-one-thing-well tools as well, so the piecemeal/modular option is also there."
>Probably my biggest issue with CakePHP (what I use) is that when you step outside the standard use cases you fall down a rabbit hole of complexity and peculiar idioms. The result here is that one becomes a "Cake developer" rather than a "PHP developer"; there is a high degree of lock-in and switching the entire toolset becomes difficult and impractical.
Totally agree. But that's because of poor design in CakePHP (I used it too).
>What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP.
Actually, it's not. Take a look at Zend Framework and you'll see that you have a TON of modules for doing all kind of stuff and if you want you could use just the core ones and ignore the rest. It works so well that I even use components in non-Zend Framework projects.
Totally agree. But that's because of poor design in CakePHP (I used it too).
>What I see in this post that I agree with is the idea that PHP tools should be more modular and decoupled, so you can grab a full stack bundle if you want, but can use modules piecemeal if you don't. Currently, the latter option is lacking in PHP.
Actually, it's not. Take a look at Zend Framework and you'll see that you have a TON of modules for doing all kind of stuff and if you want you could use just the core ones and ignore the rest. It works so well that I even use components in non-Zend Framework projects.
Please explain reasoning behind CakePHP having a poor design. I'm curious as most people that say a framework or tool sucks actually are just using the framework/tool in an incorrect way, and there is frequently an elegant way to tackle their issues. This applies to more than just CakePHP, mind you.
Sure, but you don't always have the time to figure out what that elegant way is. This is the reason people complain about the complexity of frameworks.
symfony2 (which the OP picks on a little bit) has taken exactly this approach, there's much more emphasis on the components than the framework as a whole.
Even better, other PHP projects, like Drupal, are planning to use Symfony2 components. Symfony2, with its "bundle" concept, holds huge promise for the PHP community and eco-system.
The fourth option is to break your problem up. Not all problems should be handled in one pass by one giant program.
Yeah, i vote for that one; i try to code in little modular pieces; and if a connection is needed i try to make it as short and simple as possible.
I don't think the article "suggests that you eschew option three" at all.
The author recommended several microframeworks. He's arguing against large, monolithic frameworks and pointing towards a more pragmatic, YAGNI approach.
Use a small framework that gives you simple things -- URL routing, JSON parsing, etc. Maybe a base application structure to keep things sane.
You can do a lot of very useful things in a small, reusable microframework that don't have the level of complexity of a larger framework like Zend.
edit: I knew your name was familiar. Good work on Catalyst. My choice in framework really depends on the project.
The author recommended several microframeworks. He's arguing against large, monolithic frameworks and pointing towards a more pragmatic, YAGNI approach.
Use a small framework that gives you simple things -- URL routing, JSON parsing, etc. Maybe a base application structure to keep things sane.
You can do a lot of very useful things in a small, reusable microframework that don't have the level of complexity of a larger framework like Zend.
edit: I knew your name was familiar. Good work on Catalyst. My choice in framework really depends on the project.
If it looks like a nail and feels like a nail, don't use
a sledgehammer.
Many of us (including me, at times) have forgotten our primary role as an application architect. We need to take a giant step back to look at the project from a bird's eye view to gain some insight into how to solve the problem(s) in an efficient and timely manner.
This post bothers me a lot, because it misrepresents a very large movement in American music while at the same time decrying the value of community-developed frameworks. Black Flag is a great band, but their "fast and simple" approach to playing music ran into a lot of the same problems that tech startups find when they, too, decide to take a "fast and simple" approach to web development -- those being high employee turnover, extremely low profitability, and a lot of in-fighting.
Black Flag made a lot of junk because they couldn't get the band to cooperate. They had to keep re-doing the same songs over and over because their lead singer kept changing. Talk about a good analogy for unnecessary rewrites! At one point, when the artistic direction and ego situation became especially dire, one side of an album was all spoken word, and the other side was all instrumental. In the end, they just ended up becoming another "metal" band with albums like "Slip it In" towards the end of their discography. Black Flag is a great band, but this post completely misrepresents what they did and what it means, if anything for software development. If it's the story of anything, it's the story of an entrepreneur who kept paying for all the corners he cut.
Rush wanted to write complex albums that dealt with a lot of layered meaning. There was a lot more planning and attention paid to what got laid onto their tracks. In exchange for their hard work, attention to detail, and planning, they were well compensated. They played arenas and sold a ton of albums. Black Flag played VFW halls, and I'll be damned if most of their fans these days didn't just torrent their discography and be done with it. What would you want for your business? There will be no hipsters to fondly nostalgize your unsuccessful web application.
Black Flag made a lot of junk because they couldn't get the band to cooperate. They had to keep re-doing the same songs over and over because their lead singer kept changing. Talk about a good analogy for unnecessary rewrites! At one point, when the artistic direction and ego situation became especially dire, one side of an album was all spoken word, and the other side was all instrumental. In the end, they just ended up becoming another "metal" band with albums like "Slip it In" towards the end of their discography. Black Flag is a great band, but this post completely misrepresents what they did and what it means, if anything for software development. If it's the story of anything, it's the story of an entrepreneur who kept paying for all the corners he cut.
Rush wanted to write complex albums that dealt with a lot of layered meaning. There was a lot more planning and attention paid to what got laid onto their tracks. In exchange for their hard work, attention to detail, and planning, they were well compensated. They played arenas and sold a ton of albums. Black Flag played VFW halls, and I'll be damned if most of their fans these days didn't just torrent their discography and be done with it. What would you want for your business? There will be no hipsters to fondly nostalgize your unsuccessful web application.
Great points. I would also contrast the Black Flag with Ian MacKaye's body of work: start off with fast and simple (Minor Threat), but move on when it becomes trite (Embrace, then Fugazi). Fugazi created some of the most interesting, complex music I've ever heard, but it was borne out of that initial minimalism.
Fugazi is also a good point because their goal as an organization is sustainability. This is exhibited in their $5-or-bust ticket price, among other things. Black Flag's goal, particularly during the Decline of Western Civilization years, was mostly to get drunk and fight cops. Just a bad analogy in general for software intended to make money.
"The MicroPHP Manifesto" is actually "The Lone Programmer Manifesto".
Programming in today's world means working with other people's code. All a framework does is provide a set of design patterns and standards that a group of programmers can adhere to. This encourages code reuse and allows you as a programmer to create "black boxes" - components with a well defined programming interfaces that behave in a consistent & predictable manner.
Real-world example: I'm currently working with a custom-built CMS programmed in PHP. I'm the second man on a what began as a one-man project. The CMS author wrote a bunch of database functions (essentially wrappers for the deprecated mysql_* functions) and dumped them into a file. Now, the author wasn't aware that you can (and should) lazy-load database connections - so every time you need to talk to the database, you have to manually connected using `cms_db_connect()` AND select the database with `cms_db_select(CONST_DATABASE_NAME)`. As pretty much every page initiates a database connection this code is EVERYWHERE.
And this is only the tip of the iceberg. There's also a half-assed MVC implementation, ubiquitous usage of inline CSS, un-encapsulated code, and a butt-load of quirky behavior. Now if the original author had take a little bit of time at the beginning and researched a proper framework or used an existing CMS our project would not be behind schedule - and it would be far easier to add another developer into the mix. All this meaningless complexity because the original author took the "simple" route of not working with a framework authored by third parties.
Programming in today's world means working with other people's code. All a framework does is provide a set of design patterns and standards that a group of programmers can adhere to. This encourages code reuse and allows you as a programmer to create "black boxes" - components with a well defined programming interfaces that behave in a consistent & predictable manner.
Real-world example: I'm currently working with a custom-built CMS programmed in PHP. I'm the second man on a what began as a one-man project. The CMS author wrote a bunch of database functions (essentially wrappers for the deprecated mysql_* functions) and dumped them into a file. Now, the author wasn't aware that you can (and should) lazy-load database connections - so every time you need to talk to the database, you have to manually connected using `cms_db_connect()` AND select the database with `cms_db_select(CONST_DATABASE_NAME)`. As pretty much every page initiates a database connection this code is EVERYWHERE.
And this is only the tip of the iceberg. There's also a half-assed MVC implementation, ubiquitous usage of inline CSS, un-encapsulated code, and a butt-load of quirky behavior. Now if the original author had take a little bit of time at the beginning and researched a proper framework or used an existing CMS our project would not be behind schedule - and it would be far easier to add another developer into the mix. All this meaningless complexity because the original author took the "simple" route of not working with a framework authored by third parties.
This is a similar drawback I see to microframeworks. You end up having to either roll the bits you didn't get from the framework or build a more complete framework out of other components. This can create dependency hell if you're not careful/make the wrong choices as well.
Choosing simple tools for complex jobs can get you in just as bad of a place as choosing complex tools for simple jobs.
Choosing simple tools for complex jobs can get you in just as bad of a place as choosing complex tools for simple jobs.
I am glad this is being discussed. Due at least in part to the to the fact PHP is constantly trashed (rightly or wrongly) in the "hip programmer" community, there is a lot of defensiveness in the PHP community. I understand why: one can only take so much trash talking especially when much of it is overblown or inaccurate, but it's caused many people to become so touchy that even valid, constructive criticism from community members is responded to with unnecessary vitriol.
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.
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.
>As a PHP dev, I look over the fence at python & ruby examples and wonder why my application/framework is so complex and ugly
Why wonder? Have a look at the source of the different frameworks and try to understand how they work. Maybe there's some inherent characteristic of the languages that makes it this way. Maybe it's just that one is better thought-out than what you're using and you could propose or contribute a change.
Unless you're a contributor to a language or framework, it's probably not a great use of your energy to hope that it competes well with others. A better use of your energy might be to learn a few so you can pick the most appropriate tool for a given job.
Why wonder? Have a look at the source of the different frameworks and try to understand how they work. Maybe there's some inherent characteristic of the languages that makes it this way. Maybe it's just that one is better thought-out than what you're using and you could propose or contribute a change.
Unless you're a contributor to a language or framework, it's probably not a great use of your energy to hope that it competes well with others. A better use of your energy might be to learn a few so you can pick the most appropriate tool for a given job.
Check out Symfony2. The developers adopt some of the best elements of RoR (gems/bundles) and Python (templates) among other things.
some of the best elements of RoR (gems/bundles)
That's not to denigrate the efforts that go into RubyGems, Bundler, etc. - they're doing a good job, and they make life much easier than it would be without them, but in some ways they're playing with a lousy hand for historical reasons that are too late to change now.
I'm largely ignorant of Symfony2, but I hope it's learning from the flaws of the RubyGems ecosystem as well as its strengths.
We're considering a switch to RoR (from CakePHP oddly enough) at my job, but this gem dependency nightmare gives me pause. I ran across rvm in my research, and it's supposed to solve these concerns. I'm wondering if you have used rvm and whether or not rvm solves the problems you've run into in the past.
Thanks!
Thanks!
In short, no. I've used it, but I think that the problems that RVM solves are largely orthogonal to those.
I don't use (or need) RVM on servers, and I don't use it on a daily basis, but I find it useful for testing gems across multiple interpreters before I release them.
I don't use (or need) RVM on servers, and I don't use it on a daily basis, but I find it useful for testing gems across multiple interpreters before I release them.
To me the biggest advantage of frameworks is documentation. When you bring on a new developer who has never worked with, say, CakePHP, you can point them to the docs to answer most questions.
When you roll your own, you have to either document it yourself (ha!) or become the point man on all questions about how things work.
My last company underwent a painful conversion from roll-your-own to Zend Framework. It slowed us down in the short term, but there was a huge payoff in developer productivity in the long term.
When you roll your own, you have to either document it yourself (ha!) or become the point man on all questions about how things work.
My last company underwent a painful conversion from roll-your-own to Zend Framework. It slowed us down in the short term, but there was a huge payoff in developer productivity in the long term.
Ha! Couldn't agree more with you!
At my current job we're working with our own framework. I think it has two main downsides for my employers: 1) Employees are difficult to replace - they invested a lot of time in me, to teach me their stack. 2) New employees are difficult to introduce - fresh developers keep asking questions, disrupting the workflow.
For me it's a mixed situation. In short term I know I'm safe - why should they sack me? But in the long run I'll end up with untransferable skillset.
At my current job we're working with our own framework. I think it has two main downsides for my employers: 1) Employees are difficult to replace - they invested a lot of time in me, to teach me their stack. 2) New employees are difficult to introduce - fresh developers keep asking questions, disrupting the workflow.
For me it's a mixed situation. In short term I know I'm safe - why should they sack me? But in the long run I'll end up with untransferable skillset.
Yeah, well, I can sympathize with the sentiment, but here's the problem:
> I want less code, not more
If been coding web apps since the mid-90's, and I've pretty much had it with either re-inventing the wheel or scouring the internet for bits and pieces of libraries. Big fat frameworks allow me to focus on the code I need to do something new.
I have no time to fuck about trying to compensate for all the bits and pieces those lightweight frameworks conveniently left out in order to be lightweight. The end result is inevitably just more code to maintain instead of less.
I get my punk rock kicks from writing shell scripts and the odd quick & dirty hacks, not complex web applications.
> I want less code, not more
If been coding web apps since the mid-90's, and I've pretty much had it with either re-inventing the wheel or scouring the internet for bits and pieces of libraries. Big fat frameworks allow me to focus on the code I need to do something new.
I have no time to fuck about trying to compensate for all the bits and pieces those lightweight frameworks conveniently left out in order to be lightweight. The end result is inevitably just more code to maintain instead of less.
I get my punk rock kicks from writing shell scripts and the odd quick & dirty hacks, not complex web applications.
I think OP is entirely missing the point of these frameworks. Zend Framework is probably the most enterprise-y PHP framework out there (vast amount of OOP patterns used, things copied from Java, heavy using of interfaces, etc) and if you don't like writing that kind of applications you shouldn't use it.
It seems to me that what he is trying to do is something like setting up a simple contact form using Java, Spring and Hibernate, and by this I don't mean that he codes silly stuff at all, but that if he feels this way he's just picking the wrong tools for the job.
I don't know anything about music but I also think that the analogy he used is wrong. Black Flag may do great music with much less equipment, but I doubt that with that drum kit the drummer would be able to do the same sounds or have the same precision as the drummer with the huge kit would.
Does OP know why Neil Peart needs all that stuff? I assume Neil wouldn't be able to play the same things in a minimalistic set up.
If you don't know what all the framework's "boilerplate" is for and you just want to get your application running, why are you using a framework in the first place? A framework is supposed to do stuff for you that you would have to otherwise do manually. If you don't normally do the stuff the framework does for you, don't use it.
There are plenty of quotes in there that I strongly disagree with (the commitment stuff mostly), but I think I can sum it up with saying that just because you can do great things with less it doesn't mean that having more is bad. Just learn to pick the right tool for the job.
edit: jrockway is spot on regarding code quality.
It seems to me that what he is trying to do is something like setting up a simple contact form using Java, Spring and Hibernate, and by this I don't mean that he codes silly stuff at all, but that if he feels this way he's just picking the wrong tools for the job.
I don't know anything about music but I also think that the analogy he used is wrong. Black Flag may do great music with much less equipment, but I doubt that with that drum kit the drummer would be able to do the same sounds or have the same precision as the drummer with the huge kit would.
Does OP know why Neil Peart needs all that stuff? I assume Neil wouldn't be able to play the same things in a minimalistic set up.
If you don't know what all the framework's "boilerplate" is for and you just want to get your application running, why are you using a framework in the first place? A framework is supposed to do stuff for you that you would have to otherwise do manually. If you don't normally do the stuff the framework does for you, don't use it.
There are plenty of quotes in there that I strongly disagree with (the commitment stuff mostly), but I think I can sum it up with saying that just because you can do great things with less it doesn't mean that having more is bad. Just learn to pick the right tool for the job.
edit: jrockway is spot on regarding code quality.
If you've ever seen Rush live, Neil Peart actually plays every piece of kit he has. Its all basically necessary based on the music rush plays.
My resolution regarding php this year: no new php projects. I will continue to support existing projects/clients but from here forward I am done. I have studied other languages extensively and even worked on relatively interesting personal projects in them (racket/node js etc.) but now is the time to draw the line and start using them for new projects. My last argument for using php in which hosting is easier/cheaper w/ php is moot now. So I am left with the realization that I keep reaching for it like a kid who still watches pokemon instead of doing his chemistry homework.
I think this is a great and thought-provoking post.
The movement toward smaller, decoupled and interoperable libraries in the PHP community is in general a good thing.
But without a widely adopted PHP package-management system using many micro libraries becomes more complex to manage than a big all-in-one framework. We need something like NPM for PHP. Maybe PEAR 2 can get us there.
The movement toward smaller, decoupled and interoperable libraries in the PHP community is in general a good thing.
But without a widely adopted PHP package-management system using many micro libraries becomes more complex to manage than a big all-in-one framework. We need something like NPM for PHP. Maybe PEAR 2 can get us there.
You mean like composer http://packagist.org/?
Yes - like this! Now all it needs is the widely adopted part...
That's the part where everybody can contribute. Have an open source library you like, fork and add the composer part.
Indeed it will not always be that easy, because the project has to be structured in a way that the autoloader could work with.
Maybe even merely giving the heads up to library developers would be enough to get them to accept it; worth a shot, right?
Indeed it will not always be that easy, because the project has to be structured in a way that the autoloader could work with.
Maybe even merely giving the heads up to library developers would be enough to get them to accept it; worth a shot, right?
Great post. I'd like to call attention to one point he makes:
"It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure."
Let's face it, the differences among Zend Framework vs Symfony vs Limonade vs Rails vs Django aren't really that big of a deal for most of our projects. In fact, I don't know if I've ever worked on a project that any of those frameworks couldn't solve effectively. The fact is that for the simple database web apps that most of us are writing, these decisions are not very critical.
It seems to me that Ed recognizes something that no one talks about as much as they should. The important consideration is not "Which tool is right for the project?". Most of the time "Which tool is right for the developer?" is the question that the success of a project hangs on.
Ed and his coworkers at http://gimmebar.com recognize this. They have adopted Javascript as the lingua franca that allows their frontend and backend developers to work together harmoniously. Developers working in harmony can achieve great things. The 5 Days of Gimmebar are proof enough of that (http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-ba...).
Ed says that a simple framework with useful single-purpose third-party components is the right choice for him. Maybe it is for you too, maybe it isn't. I think the important takeaway from this post is that we should all strive for the self awareness that allows us to recognize what will let us work most effectively. I know I've been giving that question a lot of thought lately myself.
"It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure."
Let's face it, the differences among Zend Framework vs Symfony vs Limonade vs Rails vs Django aren't really that big of a deal for most of our projects. In fact, I don't know if I've ever worked on a project that any of those frameworks couldn't solve effectively. The fact is that for the simple database web apps that most of us are writing, these decisions are not very critical.
It seems to me that Ed recognizes something that no one talks about as much as they should. The important consideration is not "Which tool is right for the project?". Most of the time "Which tool is right for the developer?" is the question that the success of a project hangs on.
Ed and his coworkers at http://gimmebar.com recognize this. They have adopted Javascript as the lingua franca that allows their frontend and backend developers to work together harmoniously. Developers working in harmony can achieve great things. The 5 Days of Gimmebar are proof enough of that (http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-ba...).
Ed says that a simple framework with useful single-purpose third-party components is the right choice for him. Maybe it is for you too, maybe it isn't. I think the important takeaway from this post is that we should all strive for the self awareness that allows us to recognize what will let us work most effectively. I know I've been giving that question a lot of thought lately myself.
For most projects, if you're using PHP, you probably can't eliminate your dependencies. If you really can afford on a project to go super clean and not need a bunch of other libraries, then maybe this is a really good time to be using something other than PHP. I'm honestly not bagging on PHP here. I really do think it has its place, and I was a PHP developer for many years myself. But just as there's a place and a time for PHP, there is a place and a time for other languages, too. When you have no dependencies on legacy PHP libraries, and the opportunity to go lean and clean and do what you want-- that's the project to not use PHP.
The advancement of logical thought and rational development strategies in PHP has been slowed greatly by this intense shame we all feel to be using such an uncool tool. This article was indeed a breath of fresh air, as others have said. Keep it up.
in all, as a fan of both php and small tools (the rarest of a rare breed), i agree with the author. but if i may play with the analogy...
i'd actually say the Rush vs Black Flag analogy does not do Neil Peart or micro concepts justice. ideally, small tools can be used together, much like a drum kit. each of Neil's drums performs a very specific function, and he uses them as he sees fit. if he only played one song a night, his kit would look very different. extending the analogy, if you give Neil Peart a 5 piece, he can still make great music.
i'd actually say the Rush vs Black Flag analogy does not do Neil Peart or micro concepts justice. ideally, small tools can be used together, much like a drum kit. each of Neil's drums performs a very specific function, and he uses them as he sees fit. if he only played one song a night, his kit would look very different. extending the analogy, if you give Neil Peart a 5 piece, he can still make great music.
That's an interesting look at things. I look at it from something Stephen King wrote in On Writing. Basically, the story was about his father/uncle/grand father who, when he needed to fix something, would bring out his entire tool box, with all his tools, despite only needing a hammer. Stephen would ask him why he didn't just bring the hammer, and his reply was: "Because, I didn't know what else I might need one I got out here." Basically, the story tells us to bring our toolbox with us.
When you look at a large framework like Zend, it's a lot to swallow. There are a lot of parts, and just like the tools in a tool box, each plays a different part. You might just need a hammer today, but tomorrow, you might need a screw driver, and then a saw, and then a sander.
So, I appreciate larger frameworks. Sure, SOAP or XML-RPC might not be fun, but when that's the way you connect to the bank, it being apart of the framework makes it so much easier.
Anyways, the point was I saw your post, and it reminded me of Stephen's story.
When you look at a large framework like Zend, it's a lot to swallow. There are a lot of parts, and just like the tools in a tool box, each plays a different part. You might just need a hammer today, but tomorrow, you might need a screw driver, and then a saw, and then a sander.
So, I appreciate larger frameworks. Sure, SOAP or XML-RPC might not be fun, but when that's the way you connect to the bank, it being apart of the framework makes it so much easier.
Anyways, the point was I saw your post, and it reminded me of Stephen's story.
Amen! I've been railing against this as well for some time (with a minimalist project of my own - elefantcms.com), and wow is there ever resistance in certain parts of the PHP community to ideas like this.
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.
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.
[deleted]
I've played only a four piece since 1990 or so and it will never run out of possibilities for me. A larger kit means things need to be farther away from you, and if things are too far away there's no point in having them, so in any studio I take that second tom off the rack and move the ride cymbal right in, and it feels great.
In that way I guess a four piece kit reminds me of lisp - just some parenthesis and a few other things, but endless possibilities nonetheless. But I've never used lisp for anything really and in software I always like to shoot for a happy medium of scale and pragmatism. Also Neal Peart's setup is part of the entertainment value. EJB or some overgrown PHP thing, on the other hand, not very entertaining.
In that way I guess a four piece kit reminds me of lisp - just some parenthesis and a few other things, but endless possibilities nonetheless. But I've never used lisp for anything really and in software I always like to shoot for a happy medium of scale and pragmatism. Also Neal Peart's setup is part of the entertainment value. EJB or some overgrown PHP thing, on the other hand, not very entertaining.
Agreed...this is a breath of fresh air that, imho, the community needs right now. Clear, concise, well-written code can do wonders for a project...don't jump to a framework just because it's the trend.
The assumption that "use a framework" and "clear, concise, well-written code" are incompatible is the problem.
His "punk movement" is more of a "I don't want to use things I have to learn" complaint. I defy any PHP developer to assert that the majority of development is made faster by spending your days bolting together that which already exists.
His "punk movement" is more of a "I don't want to use things I have to learn" complaint. I defy any PHP developer to assert that the majority of development is made faster by spending your days bolting together that which already exists.
I'm a hundred percent with the author on this—most PHP frameworks and libraries are a ridiculous mess. My requirement for using third-party libraries are that they do a single thing, that they do it well, and that they have little or no dependencies. There's no good reason why most third-party code can't be a single class / file.
Our third-party library stack for the (very complex) chartboost.com architecture is made up of simple, modular parts: Paraglide as micro-MVC (one class, and a handful of folder for the base structure), MongoModel (one class, as MongoDB ORM), etc. Most of our third-party libraries are very simple and manageable, the way all PHP should be.
As for code verbosity: everything is auto-loaded on the fly when needed. Our code has practically no `require` statements. We just follow a simple conventions of where to place files and how to name classes, and everything works smoothly and painlessly.
Most importantly in this setup, none of the libraries depend on the framework of choice or on anything architectural. The framework doesn't even require being run in a web environment. This lets us do powerful and flexible things like use Facebook's `phpsh` library to open up a shell that will have our entire environment available and loaded on the fly. We can also switch between dev, production or local environments on the fly.
Our third-party library stack for the (very complex) chartboost.com architecture is made up of simple, modular parts: Paraglide as micro-MVC (one class, and a handful of folder for the base structure), MongoModel (one class, as MongoDB ORM), etc. Most of our third-party libraries are very simple and manageable, the way all PHP should be.
As for code verbosity: everything is auto-loaded on the fly when needed. Our code has practically no `require` statements. We just follow a simple conventions of where to place files and how to name classes, and everything works smoothly and painlessly.
Most importantly in this setup, none of the libraries depend on the framework of choice or on anything architectural. The framework doesn't even require being run in a web environment. This lets us do powerful and flexible things like use Facebook's `phpsh` library to open up a shell that will have our entire environment available and loaded on the fly. We can also switch between dev, production or local environments on the fly.
While some of this is spot on, there's seems to be two threads to this that make less sense to me.
First, "building small things" isn't what many of us do from day to day. I don't think many of us sit down and try to create bloated, overly complex systems, but oversimplification isn't helpful either. If you're wild-westing it or reinventing wheels for your next web project, I can't help but think you've only got serious pain in your (near) future.
I think there's an important difference between complex and complicated. I wonder if you asked Neil about his set if he'd describe it more as an organized toolset that's evolved over time or a sprawling mess of a ball-and-chain he's involuntarily tied to.
I'm no fan of the verbose, Java-like implementations (ZF and SF, I'm looking at you) you've highlighted, but there are more options out there.
Secondly, I take issue with the abrasive tenor a lot of these posts seem to take. All critique and no solutions, especially no code to show for great ideas. While a good F@$* that S@#% helps everyone see the problem, the lack of action or offering of concrete ideas for improvement leaves me with the feeling that it's just complaining.
I wish more of the leadership in this community was contributing in an open-source, here's-the-code sort of way. At least contributing as much as they critique.
First, "building small things" isn't what many of us do from day to day. I don't think many of us sit down and try to create bloated, overly complex systems, but oversimplification isn't helpful either. If you're wild-westing it or reinventing wheels for your next web project, I can't help but think you've only got serious pain in your (near) future.
I think there's an important difference between complex and complicated. I wonder if you asked Neil about his set if he'd describe it more as an organized toolset that's evolved over time or a sprawling mess of a ball-and-chain he's involuntarily tied to.
I'm no fan of the verbose, Java-like implementations (ZF and SF, I'm looking at you) you've highlighted, but there are more options out there.
Secondly, I take issue with the abrasive tenor a lot of these posts seem to take. All critique and no solutions, especially no code to show for great ideas. While a good F@$* that S@#% helps everyone see the problem, the lack of action or offering of concrete ideas for improvement leaves me with the feeling that it's just complaining.
I wish more of the leadership in this community was contributing in an open-source, here's-the-code sort of way. At least contributing as much as they critique.
Why all the Rush hate? Cutesy metaphor, but c'mon!
Where's the hate? He's simply saying, if I can try to extend this analogy a little further, that if you want to get out there and start a band, it's a lot easier doing it as a punk band than as a Rush cover band, if only because you only need a single van for all of your instruments, instead of one bus per band member.
This is an excellent post. Ed has been able to put into words what I've been feeling for a while now.
=C=
=C=
[deleted]
This is the nature of languages, particularly scripting languages. Fundamentally, the creators of PHP are not representative of the mainstream users of PHP. That's a problem.
Just look at perl6.
Use the parts of PHP that matter most to you.
Just look at perl6.
Use the parts of PHP that matter most to you.
Micro-frameworks are awesome when you're doing that one quick pet-project you always wanted to try. Else you'll just fall into the loop of "okay, now I need to find and install/write from scratch this part that is present as core in x framework"
I don't agree with the OP about frameworks at all. The code example shows about 10 lines of code that are "just to get the app started" but what it doesn't show is all of the places where there will be much, much less code.
Frameworks do require a bit of initialization code, but the whole point is that once initialized they save you tons of writing. They take care of boring stuff like authentication, basic code organization, certain security issues, etc.
There's nothing wrong with deciding not to use any frameworks, but to do so because it seems "cleaner" or "simpler" I think it misguided.
Frameworks do require a bit of initialization code, but the whole point is that once initialized they save you tons of writing. They take care of boring stuff like authentication, basic code organization, certain security issues, etc.
There's nothing wrong with deciding not to use any frameworks, but to do so because it seems "cleaner" or "simpler" I think it misguided.
What I needed in a framework was exactly what the author mentioned, something simple to start but could scale to complexity when needed. I tried a lot of other full stack frameworks and just couldn't get them to do really simple things without extensive customization. They were all very rigid in "how" you do things.
This is the reason I ended up writing my own micro-framework, Flight (http://flightphp.com/). The goal is to be as flexible and extensible as possible, while providing a tiny footprint.
This is the reason I ended up writing my own micro-framework, Flight (http://flightphp.com/). The goal is to be as flexible and extensible as possible, while providing a tiny footprint.
Overcomplicated code is simply poor programming. Not something that requires a clever name or manifesto. I would go as far to say you overcomplicated things by posting such a long drawn-out post about something that could be said in far less words... or maybe even a little satirical code:
Poor_programmer = 'Overcomplicated code'; If (You == programmer) { stop(); }
EDIT: I change die() to stop() because die felt a little too dramatic, even if thats the correct function in php. =)
Poor_programmer = 'Overcomplicated code'; If (You == programmer) { stop(); }
EDIT: I change die() to stop() because die felt a little too dramatic, even if thats the correct function in php. =)
Using the right tool for the job comes to mind here, but half the time you can only see this with hindsight. And the other half the time, I'd guess, PHP is the only tool available. Unless cheap webhosts offer Python, Ruby and Node.js integration to complement the usual feature-set.
If you have more tools in the box, then you can start to consider whether to go full-stack with PHP (I'd no longer consider this route a viable option), or whether to modularise your project. Maybe for a lot of things that's too much and a PHP framework that does it all is totally fine. No point doing something just because you can, but you have the flexibility to think outside of the box when refactoring.
This is exactly what I did when it came to generating an image and manipulating the output. In PHP it was convoluted, buggy, impossible to understand the library it depended upon, and offered no flexibility. It took months of procrastination and avoidance before we had to get the feature working, so I ditched the lot and re-did it in Python, using Cyclone and a couple of lightweight libs. It took a day and a half to implement, with no knowledge beforehand, and it does absolutely everything we wanted (without any hacks).
It was at that point I realised that it was much more beneficial to look beyond the one-size-fits-all solution of a massive framework, which may be appropriate to some, but just as often isn't. And as has been said - very well indeed I must add - I don't want to be a [framework]-developer who knows not so much the language, but an individual or group's abstraction of it; I want to be a developer who knows what to do when that framework doesn't fit.
If you have more tools in the box, then you can start to consider whether to go full-stack with PHP (I'd no longer consider this route a viable option), or whether to modularise your project. Maybe for a lot of things that's too much and a PHP framework that does it all is totally fine. No point doing something just because you can, but you have the flexibility to think outside of the box when refactoring.
This is exactly what I did when it came to generating an image and manipulating the output. In PHP it was convoluted, buggy, impossible to understand the library it depended upon, and offered no flexibility. It took months of procrastination and avoidance before we had to get the feature working, so I ditched the lot and re-did it in Python, using Cyclone and a couple of lightweight libs. It took a day and a half to implement, with no knowledge beforehand, and it does absolutely everything we wanted (without any hacks).
It was at that point I realised that it was much more beneficial to look beyond the one-size-fits-all solution of a massive framework, which may be appropriate to some, but just as often isn't. And as has been said - very well indeed I must add - I don't want to be a [framework]-developer who knows not so much the language, but an individual or group's abstraction of it; I want to be a developer who knows what to do when that framework doesn't fit.
I find it rather amusing that a manifesto that advertises simplicity starts by wandering off to unrelated topics, instead of getting straight to the point.
Check out Nette Framework used as a micro framework for routing, templating (e.g. spliting layout and page template) and debugging/logging on microsite http://davidgrudl.com. See the source codes - just drag upper left corner ;)
I agree with OP, although I think the code example is misleading (but still awful).
Why? Configuration/Bootstrapping is needed, with simple, small and loosely coupled components even more, because you don't want to tie a some configuration monster to it. But it would indeed turn out to be a simpler configuration, usually a nice little array with few keys bootstraps any simple component nicely. On framework level it can be more DRY. Downside, every "framework" solves bootstrapping and configuration on it's own. Which would me make always feel bad about running multiple frameworks side by side.
For components (objects) configuration we could solve a lot of problems if the php community could agree about an plain array configuration protocol to set them up. At least it would be interesting if it's doable.
Why? Configuration/Bootstrapping is needed, with simple, small and loosely coupled components even more, because you don't want to tie a some configuration monster to it. But it would indeed turn out to be a simpler configuration, usually a nice little array with few keys bootstraps any simple component nicely. On framework level it can be more DRY. Downside, every "framework" solves bootstrapping and configuration on it's own. Which would me make always feel bad about running multiple frameworks side by side.
For components (objects) configuration we could solve a lot of problems if the php community could agree about an plain array configuration protocol to set them up. At least it would be interesting if it's doable.
Brilliant! Applies equally to JavaScript, CSS and .NET frameworks, etc.
Most mega-frameworks pat themselves on the back with examples that declare "See, you can write an entire CMS in 10 lines of code!" That's impressive except you can't write anything else and extending the CMS requires that you read and understand 100 pages of framework API entangled with assumptions and design tradeoffs that expertly fit the author's needs and not necessarily yours.
The problem is that the ideal framework requires zero lines of code because it already solves your exact problem. The worse framework requires more lines of code than coding your application from scratch. So, the key is finding a framework that satisfies 80% of your needs easily and doesn't get in your way for solving the other 20%.
Most mega-frameworks pat themselves on the back with examples that declare "See, you can write an entire CMS in 10 lines of code!" That's impressive except you can't write anything else and extending the CMS requires that you read and understand 100 pages of framework API entangled with assumptions and design tradeoffs that expertly fit the author's needs and not necessarily yours.
The problem is that the ideal framework requires zero lines of code because it already solves your exact problem. The worse framework requires more lines of code than coding your application from scratch. So, the key is finding a framework that satisfies 80% of your needs easily and doesn't get in your way for solving the other 20%.
Laravel is a new PHP framework which focus on clean and expressive syntax, worth a try. (http://laravel.com)
When I looked for a PHP framework for a demo I needed to put together quickly, I found Fat-Free Framework (http://fatfree.sourceforge.net/) did everything I needed without the bloat and complexity.
Have you tried CodeIgniter? I've been using it for a while, it's pretty lightweight in comparison with Zend, it's also much faster in speed.
I have been using CI for larger projects and I love it. CakePHP for me has too much that I don't need.
Thanks Ed, love the manifesto and, more importantly, adopting it. Paul
[deleted]
> I like to make things that solve problems
Then you're probably using the wrong language. :-)
Then you're probably using the wrong language. :-)
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.)
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.