
The MicroPHP Manifesto - tswicegood
http://funkatron.com/posts/the-microphp-manifesto.html
======
jrockway
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.

~~~
sequoia
"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."

~~~
zfran
>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.

~~~
josegonzalez
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.

~~~
whacker
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.

------
languagehacker
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.

~~~
dmansen
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.

~~~
languagehacker
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.

------
pygorex
"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.

~~~
mark_story
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.

------
sequoia
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.

~~~
OstiaAntica
Check out Symfony2. The developers adopt some of the best elements of RoR
(gems/bundles) and Python (templates) among other things.

~~~
threedaymonk

        some of the best elements of RoR (gems/bundles)
    

I program in Ruby a lot, have done for a long time, and love it, but I've also
lost weeks (months?) of my life to fighting gem interdependency problems and
watching 'bundle install'. It's almost certainly my least favourite part of
the job.

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.

~~~
abszeph
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!

~~~
threedaymonk
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.

------
drumdance
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.

~~~
devuatl
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.

------
rickmb
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.

------
zfran
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.

~~~
mark_story
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.

------
shaunxcode
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.

------
deweller
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.

~~~
mhitza
You mean like composer <http://packagist.org/>?

~~~
deweller
Yes - like this! Now all it needs is the widely adopted part...

~~~
mhitza
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?

------
nickasloan
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...](http://blog.gimmebar.com/post/12793742161/5-days-of-gimme-bar-day-
one)).

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
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.

------
tlack
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.

------
catshirt
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.

~~~
jasonlotito
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.

------
lux
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...](http://packages.zendframework.com/docs/latest/manual/en/zend.mvc.quick-
start.html)) 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
PHP itself tries to emulate Java. Should have stopped at PHP4.

~~~
lux
And badly at that.

------
zzzeek
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.

------
enygmadae
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.

~~~
eropple
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.

------
SeoxyS
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.

------
webcowboy
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.

------
qrush
Why all the Rush hate? Cutesy metaphor, but c'mon!

~~~
pavel_lishin
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.

------
calevans
This is an excellent post. Ed has been able to put into words what I've been
feeling for a while now.

=C=

------
davidu
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.

------
Inori
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"

------
jakejake
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.

------
mcao
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.

------
justindocanto
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. =)

------
FuzzyDunlop
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.

------
perlgeek
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.

------
DavidGrudl
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 ;)

------
zombielifestyle
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.

------
PixelJ
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%.

------
tszming
Laravel is a new PHP framework which focus on clean and expressive syntax,
worth a try. (<http://laravel.com>)

~~~
alwillis
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.

------
tpae
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.

~~~
sschueller
I have been using CI for larger projects and I love it. CakePHP for me has too
much that I don't need.

------
lynxtdc
Thanks Ed, love the manifesto and, more importantly, adopting it. Paul

------
soc88
> I like to make things that solve problems

Then you're probably using the wrong language. :-)

