TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The MicroPHP Manifesto

165 pointsby tswicegoodover 13 years ago

34 comments

jrockwayover 13 years ago
Real-world applications are complicated. There are three ways to handle this problem.<p>The first is to not handle the problem. Implement something "simple" that doesn't work in uncommon cases. This seems nice because there isn't much code and there isn't much complexity. But that's because your program doesn't actually work, which is usually considered a bad thing. (This program right here -&#62; "" &#60;- is the easiest way to solve problem X. It only fails in 100% of the cases, that's all.)<p>The second way is to "refuse complicated frameworks" and write an application with a framework inside. This is what most people do, but believe that they aren't using a framework because they didn't download one. But, the same problems come up again and again: rendering data, handling AJAX requests, building database queries, managing users and passwords, the list goes on forever. When you do a half-assed job of handling this stuff right in your application code, you're using a framework. It's just a bad one. You had to write it from scratch, it's not well-tested, and you can't reuse it.<p>A third option is to use well-written libraries (or frameworks) to manage the implementation complexity, leaving your application as a concise shell around the core components. This means your application code only describes the problem that your application is trying to solve. The dirty work of dealing with the real world (HTML, JSON, SQL, etc.), is all handled in other code. (You can write this yourself, of course; you just have to understand that JSON parsing is not what your application <i>does</i>, and when you want to write that code, you need to "switch gears" and implement it outside of your application du jour. And sometimes, "you" is not you, it's someone else on the Internet.)<p>This article suggests that you eschew option three in favor of option one or two, because the code is "less beautiful". I say that, beautiful or not, these two options are the best way to write unmaintainable code that doesn't ever work.<p>The third strategy may feel unclean because you did not get to fully control every aspect of the interface and implementation. But most of the time, that doesn't matter. Yes, you'll have to do some configuration. Configuration is easier to test and maintain than the logic that you're configuring, and that means your application is actually simpler. The world is complicated. Your software doesn't have to make it more complicated.
评论 #3420415 未加载
评论 #3420549 未加载
评论 #3420757 未加载
评论 #3422015 未加载
评论 #3420608 未加载
评论 #3420430 未加载
评论 #3420644 未加载
languagehackerover 13 years ago
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.<p>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 <i>anything</i> 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.<p>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.
评论 #3421220 未加载
pygorexover 13 years ago
"The MicroPHP Manifesto" is actually "The Lone Programmer Manifesto".<p>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 &#38; predictable manner.<p>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.<p>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.
评论 #3421376 未加载
sequoiaover 13 years ago
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.<p>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 &#38; 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?<p>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.
评论 #3422226 未加载
评论 #3421944 未加载
drumdanceover 13 years ago
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.<p>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.<p>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.
评论 #3420900 未加载
rickmbover 13 years ago
Yeah, well, I can sympathize with the sentiment, but here's the problem:<p>&#62; I want less code, not more<p>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.<p>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 <i>more code</i> to maintain instead of less.<p>I get my punk rock kicks from writing shell scripts and the odd quick &#38; dirty hacks, not complex web applications.
zfranover 13 years ago
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>edit: jrockway is spot on regarding code quality.
评论 #3421439 未加载
shaunxcodeover 13 years ago
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.
dewellerover 13 years ago
I think this is a great and thought-provoking post.<p>The movement toward smaller, decoupled and interoperable libraries in the PHP community is in general a good thing.<p>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.
评论 #3421634 未加载
nickasloanover 13 years ago
Great post. I'd like to call attention to one point he makes:<p>"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."<p>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.<p>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.<p>Ed and his coworkers at <a href="http://gimmebar.com" rel="nofollow">http://gimmebar.com</a> 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 (<a href="http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-bar-day-one" rel="nofollow">http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-ba...</a>).<p>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.
unotiover 13 years ago
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.
评论 #3420972 未加载
tlackover 13 years ago
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.
catshirtover 13 years ago
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...<p>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.
评论 #3422385 未加载
luxover 13 years ago
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.<p>Reading "quick" start tutorials like this (<a href="http://packages.zendframework.com/docs/latest/manual/en/zend.mvc.quick-start.html" rel="nofollow">http://packages.zendframework.com/docs/latest/manual/en/zend...</a>) 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.<p>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...<p>Thank you for writing this.
评论 #3421756 未加载
zzzeekover 13 years ago
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.<p>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.
enygmadaeover 13 years ago
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.
评论 #3421896 未加载
SeoxySover 13 years ago
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.<p>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.<p>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.<p>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.
webcowboyover 13 years ago
While some of this is spot on, there's seems to be two threads to this that make less sense to me.<p>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.<p>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.<p>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.<p>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.<p>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.
qrushover 13 years ago
Why all the Rush hate? Cutesy metaphor, but c'mon!
评论 #3420530 未加载
calevansover 13 years ago
This is an excellent post. Ed has been able to put into words what I've been feeling for a while now.<p>=C=
daviduover 13 years ago
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.<p>Just look at perl6.<p>Use the parts of PHP that matter most to you.
Inoriover 13 years ago
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"
jakejakeover 13 years ago
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.<p>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.<p>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.
mcaoover 13 years ago
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.<p>This is the reason I ended up writing my own micro-framework, Flight (<a href="http://flightphp.com/" rel="nofollow">http://flightphp.com/</a>). The goal is to be as flexible and extensible as possible, while providing a tiny footprint.
justindocantoover 13 years ago
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:<p>Poor_programmer = 'Overcomplicated code'; If (You == programmer) { stop(); }<p>EDIT: I change die() to stop() because die felt a little too dramatic, even if thats the correct function in php. =)
FuzzyDunlopover 13 years ago
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.<p>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.<p>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).<p>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.
perlgeekover 13 years ago
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.
DavidGrudlover 13 years ago
Check out Nette Framework used as a micro framework for routing, templating (e.g. spliting layout and page template) and debugging/logging on microsite <a href="http://davidgrudl.com" rel="nofollow">http://davidgrudl.com</a>. See the source codes - just drag upper left corner ;)
zombielifestyleover 13 years ago
I agree with OP, although I think the code example is misleading (but still awful).<p>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.<p>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.
PixelJover 13 years ago
Brilliant! Applies equally to JavaScript, CSS and .NET frameworks, etc.<p>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.<p>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%.
tszmingover 13 years ago
Laravel is a new PHP framework which focus on clean and expressive syntax, worth a try. (<a href="http://laravel.com" rel="nofollow">http://laravel.com</a>)
评论 #3423350 未加载
tpaeover 13 years ago
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.
评论 #3423245 未加载
lynxtdcover 13 years ago
Thanks Ed, love the manifesto and, more importantly, adopting it. Paul
soc88over 13 years ago
&#62; I like to make things that solve problems<p>Then you're probably using the wrong language. :-)