Real-world applications are complicated. There are three ways to handle this problem.
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.
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.
"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."
If it looks like a nail and feels like a nail, don't use
a sledgehammer.
We should all be pushing for "the right tool for the right job"; a concept that is both language and framework agnostic. When you start your next project, take a moment to think about all of the core components and modules that will be necessary to complete said project.
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.
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.
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.
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.
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.
"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.
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.
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.
>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.
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.
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 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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
[+] [-] jrockway|14 years ago|reply
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.
[+] [-] Periodic|14 years ago|reply
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.
[+] [-] sequoia|14 years ago|reply
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."
[+] [-] jqueryin|14 years ago|reply
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.
[+] [-] gambler|14 years ago|reply
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.
[+] [-] strmpnk|14 years ago|reply
[+] [-] eli|14 years ago|reply
[+] [-] zbuc|14 years ago|reply
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.
[+] [-] languagehacker|14 years ago|reply
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.
[+] [-] dmansen|14 years ago|reply
[+] [-] pygorex|14 years ago|reply
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.
[+] [-] mark_story|14 years ago|reply
Choosing simple tools for complex jobs can get you in just as bad of a place as choosing complex tools for simple jobs.
[+] [-] sequoia|14 years ago|reply
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.
[+] [-] Zak|14 years ago|reply
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.
[+] [-] OstiaAntica|14 years ago|reply
[+] [-] drumdance|14 years ago|reply
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.
[+] [-] devuatl|14 years ago|reply
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.
[+] [-] rickmb|14 years ago|reply
> 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.
[+] [-] zfran|14 years ago|reply
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.
[+] [-] mark_story|14 years ago|reply
[+] [-] shaunxcode|14 years ago|reply
[+] [-] deweller|14 years ago|reply
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.
[+] [-] mhitza|14 years ago|reply
[+] [-] nickasloan|14 years ago|reply
"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.
[+] [-] unoti|14 years ago|reply
[+] [-] Encryptor|14 years ago|reply
[deleted]
[+] [-] tlack|14 years ago|reply
[+] [-] catshirt|14 years ago|reply
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.
[+] [-] jasonlotito|14 years ago|reply
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.
[+] [-] lux|14 years ago|reply
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.
[+] [-] stesch|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] zzzeek|14 years ago|reply
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.
[+] [-] enygmadae|14 years ago|reply
[+] [-] eropple|14 years ago|reply
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.
[+] [-] SeoxyS|14 years ago|reply
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.
[+] [-] webcowboy|14 years ago|reply
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.
[+] [-] qrush|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply