Concerns about Zend Framework 2, Symfony2 and other major PHP frameworks

van graphics

I recently read an article entitled Why Codeigniter is Dead and it confirmed my fears that the PHP community – particularly the frameworks community – is moving entirely in the wrong direction.  If you are a web developer and you use any of the major PHP frameworks then I’m sure you’ll appreciate what I’m talking about.  Rewrite culture.

Haven’t you seen it?  It’s everywhere!  They’re all talking about it.  They’re all doing it!  They’re all loving it!  ZF has been rewritten, Symfony has been rewritten, Drupal has been rewritten.  Yii is being rewritten as I write.  It seems like just about every major framework is being rewritten!  Have a look on YouTube and you’ll see a wide assortment of conferences and launches.  Every week there seems to be a new ubergeek giving us a slideshow and telling us why they had to rewrite the whole thing from scratch.  Over the past year, we’ve been exposed to all sorts of new phrases and technologies – my favourite of which is “aspect oriented programming”.  I’m still not entirely sure what that actually is but I”ve been assured that it’s the next big thing and to me it all sounds very impressive.

I even saw a presentation on YouTube recently (can’t find the link – aaaargggh!) in which one of the top Drupal guys was claiming that Drupal is like the iPhone.  His claim was that the ongoing relaunches and culling of older versions is precisely what makes Drupal so awesome.

The only major PHP framework which doesn’t seem to have joined the party is Codeigniter.  Unlike the other major PHP frameworks Codeigniter has remained as steady as a rock.  Of course, for some developers this appears to have caused concern.  They want rewrites and they want them now.  They demand rewrites!  So much so in fact that many thousands of CI developers appear to have defected to Laravel – a new PHP framework which I understand was rewritten three times in the course of a year (Source:

Now, I’m all in favour of technological progress and I’m also reluctant to turn this into a technical discussion about the pros and cons of building frameworks in a particular manner.  What I am eager to do, however, is talk about business.  Oh I’m sorry, are we not allowed to talk about business any more?  I didn’t mean to rock the boat.  In any event, here is the challenge that I have:

I have been building and selling commercial websites (in one form or another) since 1996.  I’m not the best developer in the world by a long shot.  Heck, I’m not even the best developer in my home town.  However, I like to think I’m a fast worker and, most importantly, the things that I build work.  They just work.  That’s why – since 1996 – I have given every single person who hires me a two year guarantee.  Over the years – whether I’m fixing a contact us form or building an entire online shop from scratch – my guarantee has been this: “If it breaks or there are any faults over the next two years then I’ll fix those faults immediately and free of charge”.

Folks, when you give your clients a guarantee like that two interesting things happen.  The first thing is,  you quickly learn how to build web applications which are bullet proof.  If you know in the back of your mind that your ass is on the line if it breaks then you can’t afford the luxury of building dodgy applications.  The second interesting thing that happens is that, over the years, people begin to trust you and they come back to you.  They also recommend you to friends and family, from time to time.

That’s the web development business for you right there.  That’s all there is to it!  Build good stuff, make it work, don’t leave them with something that is broken and you’ll be cool.  I have PHP sites out there today which are over eight years old and still going strong.  The reason why I have been able to charge premium prices and stay in business for so many years is not because my stuff is any better or fancier than yours.  It’s because my stuff works.  It just works.  Every single person who has hired me has that two year unconditional guarantee and it has been a win win for everyone involved.

Rewrite culture is now challenging the way that I and others with me do business.  How can you or anyone possibly give any guarantees to your clients whatsoever if the next rewrite is potentially just a few months down the road?  You can’t!

Last year I predicted that thousands of Zend developers are going to be left like abandoned refugees when Zend Framework 2 is released.  I was right.   This rewrite culture is having a devastating effect on businesses and on developers.  Remember folks, we’re talking about rewrites.  Not upgrades.  Not major improvements.  Rewrites.  Complete, ruthless and unyielding.  My visualisation today is that the people behind most of these rewrites are spectacularly talented web developers.  I dare say that I’d probably struggle to even hold a conversation with some of those guys – they’re so far ahead of me in terms of web development knowledge.  They’re incredible and they are brilliant.

However, I’m going to venture a guess that the majority of the people behind this new movement aren’t in the business of being in business.  For the most part, I don’t think they’re part of the marketplace and I don’t think they are sensitive to the needs of clients on the ground.  Here is a presentation from a top Drupal guy who introduces himself as being part of a company who build websites “primarily for not for profits”.  Why does he build primarily not for profits?  Why can’t he be an unashamed commercial web developer?  What’s wrong with that?  I’m not saying that there’s anything dodgy going on but surely these are valid questions to be asked.  If I was one of the top Drupal guys then I’d be selling websites for six figure sums and I’d be proud to do that!  There is nothing immoral or unethical about running an honest business.  If more people did that then perhaps the global economy wouldn’t be in such a mess.

The key word that I was to highlight today is “rewrite”.  A rewrite means starting again from scratch.  A rewrite means most of the stuff that you learned in the past is no longer useful.  A rewrite means no more support for your existing systems.  A rewrite means change or die.  A rewrite means we got it wrong.  A rewrite means go back to square one and do not collect $100 when you pass ‘Go’.

Let’s not mistake a rewrite with an upgrade.  Upgrades can be happy and joyous.  Upgrades can be graceful.  Rewrites, on the other hand, can be devastating for people in business who depend upon their web applications to put food on the table.

To the people who appear to be bashing Codeigniter because it hasn’t joined the rewrite party I’d just like to stay that the things which you guys appears to be criticising are actually the things which I like best about Codeigniter.  I applaud the Codeigniter guardians for not rewriting and for not going with the rest of the herd.  Unlike all of the other major framework makers, they have produced a framework which is stable, tried tested and as durable as a post nuclear war scorpion.

When you build a website application with Codeigniter then you can be pretty sure that they’re not going to turn around in two weeks time and declare another rewrite.  You can depend on Codeigniter and that’s a good thing.  It’s good for your clients and it’s good for you.

I’m particularly concerned for the ZF2 developers.  The people behind Zend Framework have proven themselves to be ruthlessly commercial.  They charge four figure sums for seminars and other wares.  They know that every time they release a new version of ZF then they’ll make a tonne of cash from that.  When ZF3 comes out I for one will be questioning whether that change was inspired by technology or a desire to sell more.

The flagship feature of the new generation PHP frameworks comes in the form of bundles. Bundles are basically self contained modules which contain all the code required to perform a given set of tasks. The idea is that you can easily create and access entire libraries of bundles and quickly ‘bolt’ new features onto your website as and when required. This is all very impressive. However, for those of us who have been using HMVC architecture with frameworks like Codeigniter, Kohana, Fuel, Yii and others – it’s nothing new. We’ve been working like that for years!

In my opinion, the PHP community needs to have a rethink.  I’m not saying that we need to stop rewrites but I think we should make it clear that it’s seriously uncool to do lots of rewrites lots of times.  Instead of demanding rewrites I think we should be encouraging graceful and elegant upgrades.  If we really must do rewrites, then I would like the people behind those rewrites to do the following:

  • Clarify why the old version was flawed
  • Clarify where the demand for a rewrite came from
  • Clarify how the new version remedies the flaws which the older version had
  • Clarify what support is available for people who are depending on older versions
  • Clarify how long that support will last
  • Clarify when we can reasonably expect additional rewrites to occur in the future

Personally speaking, I don’t want it to be the norm for technologies that we depend on to be rewritten every twelve months or every six months.  I’m slightly worried though because I think that’s the way we’re going.  In my opinion this is the most important issue facing the PHP community today.


  1. Completely agree. Phil Sturgeon is great guy and he loves to code, but he is jumping around and preaching that the project he is working on, is the best thing ever, and old projects (like CI) are left with sadness in hart, and no one understands him with his wish to help and improve. That is lame. He speakes more like some PR and less like developer.

    CI is great product, easy to learn, stable and I like concept of framework evolution, not revolution. It’s not the best framework ever, but it works. Imagine Windows API or any Apple product API is changed every 6 months.

  2. parkerandhobbes · · Reply

    Hi, thanks for your comment. I appreciate that. I should stress though that I don’t know much about Phil Sturgeon. I know that he was involved with CI and Fuel but that’s about all I know. So, I just want to stress that he is not my target. I’m sure he’s not your target either and you’ve said nice things about him. Rather than single out particular people I think I’m trying to highlight a concern that I have for the general PHP community. I insist that rewrite culture is uncool and it’s about time a few of us stood up and said that. Cheers dude!

    1. I just spotted this while googling for some old article I couldn’t remember. I figured I’d come by and answer your comments, because I feel like they are a little unfair.

      I was involved with CodeIgniter for about two years. It was great for all the reasons you have suggested, by the jump to Fuel was largely political. EllisLab had CodeIgniter in a death-grip and did not allow change AT ALL. It wasnt on GitHub, or BitBucket, and features had to be sent in via hoping that a core team member noticed the code on a forum:

      That blog post kicked off some political change, and we were allowed to send in PRs.

      I was involved with FuelPHP already by the time that happened, and I spent a lot of time explaining that CodeIgniter and FuelPHP were great, but at different tasks and for different PHP versions. Obviously FuelPHP could cut the legacy, learn from the mistakes, and start afresh. Anything that does this has a potential advantage, but you’re right, but you can only do that one big rewrite for v1.0 then you have legacy and have to slow it down.

      CodeIgniter was NOT allowed to rewrite. We made v3.0 with literally thousands of improvements but were not allowed to change the API at all – because politics. Still.

      So CodeIgniter had problems. Lots of them. I highlighted most of them here:

      It desperately needed a rewrite. Not because rewrite culture is cool, but because it literally had not changed or drastically improved in about 4 years at that point and even now it’s exactly the same.

      FuelPHP made huge progress on all of the areas that CodeIgniter lacked in, but we were limited by how much time we could dedicate to the project and sadly picked up a few legacy probelms of our own.

      Getting from 1.x to 2.x is STILL ongoing for FuelPHP and its a really difficult task, especially as backwards compatibility was a major interest for Fuel and we needed to make migration packages and all sorts of complex tasks.

      Laravel popped up and was VERY similar to FuelPHP 1.x. Then they recoded again for 4.x and took care of most of the problems FuelPHP 1.x was suffering from by totally recoding and offering no upgrade path for their users other than “FU start again”. It was fine, because Laravel was a small community (even smaller than FuelPHP at the time, but growing fast) and their code was so popular and successful that since then it has vastly eclipsed many of its competitors.

      Two months before this article was written I got a new job, and decided to quit a bunch of stuff so I could focus on that:

      I cut out CodeIgniter and FuelPHP, and decided to just use Laravel for a few projects, as it had already taken care of what I wanted entirely. Building a framework (or trying to improve one) is a thankless task, and if you can let somebody else do all the hard work then happy days.

      I point out what I think is good, and highlight what I think is bad. I ALWAYS provide reasoning, so suggesting I am just a PR mouthpiece is a little unreasonable. 🙂

      1. parkerandhobbes · ·

        Well, quite clearly I haven’t said one solitary word in criticism of you nor have I implied any bad vibes at all. I didn’t have you in mind when I wrote the article and I’m not aware of any reason why you should be a focal point of what I was saying.

        As far as I can tell it looks like you’ve been involved in some very exciting projects. Long may that continue and may you reach ever higher heights.


  3. Thanks for response. I understand what did you mean, but Phil started with FUEL as answer to slow development of CI, and blogs were full of stories about FUEL as next best thing on the web, and after that he started to work on Laravel. Now everybody talk about Laravel. Phil just continues to talk bad about CI, and that looks like talking trash about ex girlfriend who dumped you, to boost your ego 🙂 Simply it is not fair. It is obvious that CI community needs something more in CI (ie. official auth/acl, or PSR-0 – PSR-2 support, at least for third party libs) but that is part of evolution, no need for code rewrite. Framework is not a browser, with 6 weeks or 6 months release cycle, it is foundation for much bigger things so it should be changed more carefully.

    1. I did not start FuelPHP, it was already going when I offered to help out. I do not and have not ever “worked on” Laravel. I do not and have not ever badmouthed CodeIgniter unfairly, or without reason.

      Here is an example of a completely fair and object list of complaints I have about CodeIgniter:

      The rest are political.

  4. parkerandhobbes · · Reply

    Alright. I wasn’t aware of any of the history behind these things. Thanks for that.

  5. Hello. I do not comment much on blogposts unless I have a feeling I should. Which is this case as You’re reading it 🙂 I highly agree with everything said in that post! For me the “framework rewrite culture” means loosing trust to the framework – “Why was it rewritten? Was the previous version that bad? Did it contain so many bugs or holes? Was the completely new version neccessary? Oh, hey, You did completely rewrite the framework, now I have to learn it from the beginning! Aha, OK, now here comes the completely new version – OK, I will learn that, but I hope there won’t be another rewrite for at least next few years.” – after asking these questions and saying these thoughts I’d rather look around for some other stable or new framework that at least pretends it won’t be rewritten so soon.

    And to the question why did they rewrite ZF? I guess the money is the best bet! ZF was here for too long and probably they didn’t receive as much money as in the first 5-10 years… Now ZF2 is out ther that means new seminars, new books, new certificates, new everything. New money!

    I’d like to find some good framework these days but it is like finding a needle in a haystack. many of “should be good bet” frameworks are too strict (and I hate strictness, I love making things done the way I like and noone telling me where should I put a paranthesis or where should or shouldn’t I put a space, etc.) or has kinda big learning curve or I get totaly disgusted after trying some (or trying to learn some). So I am getting to the conclusion – do I need a framework? Sure, I do always the same tasks or steps but everytime I need it I still go back to any project I worked on and copy-paste that piece of work. Hmm, I’m still less and less convinced to use a framework…

  6. parkerandhobbes · · Reply

    Absolutely! You said it better than me!

    What’s really interesting is that EVERY SINGLE PERSON who chose Zend all said the same thing – “The reason I chose the Zend Framework is because I know it will be around for a long time”.

    Well, they were all wrong.

    These people have been looking down their noses at the rest of the PHP community for years. Now I don’t think they look quite so clever. If you’re into Zend then it’s time to pay up and go back to square one. Same goes for Symfony.

    Remember folks, seminars cost money. Shadyyx, you’re right. Rewrites mean more book sales, certification courses, seminars and an entire cavalcade of new products and services that we don’t need. So, maybe it’s time we talked about the real explanations behind all these rewrites.

  7. shawnmccool · · Reply

    I find it hard to understand where you’re coming from. I’m a professional software developer and I have a responsibility to my clients to make the best software that I can. This requires constantly learning and improving upon what I have done before. It worries me that so many people in the PHP community avoid progress and genuinely believe that the opportunity to learn more reduces their overall product stability.

    It seems that the cornerstone of your argument is that in using a new framework we’re somehow forced to relearn our entire occupation and start as fledglings. This is simply not the case. The more that we learn the more thoroughly we understand what we’re doing, not less. By learning a half-dozen PHP frameworks you’re not weakening your products, you’re strengthening each and every additional product that you make. The suggestion that by utilizing technological advancements you’re “playing with toys at the expense of your clients” is not only unreasonable but it’s irresponsible.

    It is our jobs to identify paths of growth. It is necessary to have a plan for forward progress and constantly walk that path. The plan can absolutely change to accomodate new information and the goal is ALWAYS to improve your skills and to make yourself and your products more valuable. It is our job to handle this responsibly and I think that many people find the assumption that we as professionals cannot handle this as quite insulting.

    The most dangerous situation that we can be in is to have developers utilizing the same tools and algorithms for long periods of time. Our needs are constantly changing and unless our current tools can keep up, we are required to acquire new tools. Additionally, developers become unmotivated and disinterested as they are required to utilize deprecated algorithms to accomplish goals with ever-decreasing levels of efficiency and potency. The quality of the work generated by depressed developers is very low.

    If a web-developer is not constantly working to improve their algorithms then they are increasingly becoming liabilities to our entire industry. Our industry (especially PHP developers) already suffer a well-deserved bad reputation. Instead of perpetuating an idealogy of stagnation, enabling it through a misleading and misguided argument for stability, we should instead be urging PHP developers to learn more frameworks, learn more design-patterns, and focus on tactics such as automated testing.

    I think that it’s irresponsible to ignore the opportunities that we have to improve our industry. Our clients deserve to have developers who are ready to handle modern problems with modern solutions.

  8. parkerandhobbes · · Reply

    Hi Shawn,

    I’m sure I’ve followed some of your tutorials in the past and I’m a fan. Thanks for being here.

    Here’s how I see things:

    In the cases that I have in mind – particularly Zend2, Drupal and Symfony, all the evidence that I’m seeing suggests that they are actually starting from scratch. That’s just the point! I have a close friend who’s a professional ZF developer. The effect that the switch to ZF2 has had on his career has been devastating. This change, for him, came at a time when he’d just finished working on a large scale ZF site which took him a full year to build! Now, I don’t think he knows what to do with himself! I know that he’s spent good money on seminars (surprise surprise) but his earning ability has been seriously damaged by all of this. I was reading yesterday on the Yii site that their new framework (version 2) will not be compatible with the old version.

    So, what we’re talking about here is rewrites. These are not to be mistaken with upgrades.

    The last guy who commented here hit upon something that I couldn’t really put into words myself at the time. He suggested that the motivations for some of these rewrites are commercial, not technical.

    Now, in writing my little blog post above I realise that I’m putting my neck on the line and making myself an easy target for people who want to say things like, “You don’t want to learn”. I consider that to be a bit of a cheap shot and I’m sure that’s not what you were getting at. However, in anticipation of that kind of response I’d say two things:

    Firstly, you said something about me not having my clients’ best interests at heart. In response I’d have to say that you can’t guarantee shit for your clients because for all you know your framework will be getting rewritten in three months (let me stress, when I say “you”, I don’t literally mean you Shawn – I’m referring to an imaginary group of people who have been seduced by rewrite culture).

    I’ve been in this game long enough to spot patterns. So have you. Remember Kohana? Remember Fuel? Now we’ve got Laravel. They’ve all been declared ‘the next big thing’ and I’ve been watching them coming and going for years. I’m not impressed by any of it. I’m not saying they’re all rubbish frameworks but the people who backed Kohana backed a losing team. I think there’s a lot to be said for sticking with a framework which is popular, tried, tested and solid as a rock – even if that comes at the expense of losing a few bells and whistles.

    Secondly, I’d be eager to go through the particulars of some of these rewrites and for someone to explain how the old versions weren’t up to the job. This is not so much a conversation about writing economical PHP code as it is a conversation about commercial website development. Which features of a practical online shop (for example) depend upon the assortment of new features on Yii2? Can anyone answer that?

    Anyway, in answer to your question Shawn, the thing that I’m driving at is simply this. I am concerned that it’s becoming the norm for PHP frameworks to be rewritten frequently, completely, ruthlessly and without good reason. I think there IS a new rewrite culture within the PHP community. I question the motivations behind the new rewrite culture. Based on the comments I’ve received above, it seems I’m not the only person who has those concerns.

    Thanks again for being here. I’m grateful.

    1. shawnmccool · · Reply

      In response to a comment:

      I may write an application with Laravel 3. Then, Laravel 4 comes out and revolutionizes the way PHP apps are developed (fixing dozens of major problems with modern PHP development). That doesn’t decrease the value of my Laravel 3 application. If I or anyone else who uses Laravel 3 finds a bug, we can update the repository. We can pull from the repository. This is a beautiful part of being involved in the open-source culture that GitHub so elegantly promotes.

      I don’t have to upgrade my Laravel 3 application. And the documentation is always available. The API is always available. We can just look at any aspect of the source to quickly figure out how it works. We have created an application using a standardized set of code for which there are many forum posts, tutorials, screencasts, and many developers who are familiar with it from which we can gain help.

      Why would your friend’s Zend Framework site be a lost cause? The logic here doesn’t compute. Capable ZF developers are not hard to find. The framework version he used is no doubt more battle tested than newer versions.

      I’m not trying to be aggressive. But, I do feel like differentiating a rewrite with any other kind of “upgrade” is dishonest. It’s relative to each individual project how much the API actually changes.

      I want to be clear that if a framework goes through a major version change and is simultaneously backward-compatible then there is no reason for that number to have a changed. A minor version change is appropriate in this case.

      “Firstly, you said something about me not having my clients’ best interests at heart. In response I’d have to say that you can’t guarantee shit for your clients because for all you know your framework will be getting rewritten in three months (let me stress, when I say “you”, I don’t literally mean you Shawn – I’m referring to an imaginary group of people who have been seduced by rewrite culture).”

      I don’t even know what you’re talking about here. I have delivered a number of solid production sites with Laravel 3 that I’m very proud of. Laravel 4 is around the corner and I’ll be using it in production soon. In no way are my clients that have Laravel 3 sites in a bad way. They have solid systems that will continue to be solid for years to come. I stand by the quality of my work. The code base on which those sites have been built has NOTHING to do with Laravel 4 and Laravel 4 has nothing to do with me standing by the quality of my Laravel 3 sites. When my clients come to me they know that they’re gaining the best that I can offer them at the time that they contract me.

      “Remember Kohana?” Yea, the framework that was basically better than CodeIgniter in every way.. Except that the community made a number of terrible decisions which prevented any real adoption. The community believed that it was OK to allow their framework to be inaccessible (through terrible documentation and very little outreach to new developers). You can go look on their forums now and they’re basically like, “Why isn’t Kohana listed amongst top frameworks?” The first reply will be basically dead on. The rest of the replies are like.. “We don’t want newbies around here anyway asking their newbie questions.” Yea, it’s too bad Kohana didn’t catch on because it was a pretty solid framework in its time (a time which has obviously past).

      “Remember Fuel?” People didn’t like what fuel had to offer. What’s the point here? People didn’t feel like it provided advantages over other options. An interesting point about Fuel is that when Fuel was starting to be usable MANY solid PHP developers were completely leaving PHP. We’ve suffered incredibly “brain drain” in this community due to the lack of the long-time coming features that finally starting showing in 5.3 and the lack of frameworks that provided functionality that reduced development time (aka cost) and increased testability and maintainability. PHP has seriously lagged in these ways and that’s been a real problem for our sector of the industry.

      I think that you absolutely should pursue one of your last questions with diligence. What about the new features are people excited about and why? We’re not talking about a new shopping cart class or something ridiculous like that. The new framework versions provide dependency injection, heavy usage of ioc, and component decoupling. Why do we care about these things?

      The answer is that we do not just create websites. We create applications. We create living breathing software systems. What you see when you go to is not what was engineered. It’s just the face. Experienced software engineers create systems that are designed to change every day and to resist code rot.

      These features that we’re all excited to FINALLY get in the world of PHP reduce the lifetime cost of our products for our client, improve testability, and provide far more opportunity for developers to design an architecture that is a proper fit for our clients rather than have to work within a rigid system designed 6 years ago (which without any level of exaggeration) has not significantly improved the developer’s experience since.

      There is no difference between a rewrite and an upgrade of any other kind. The distinction is irrelevant as I believe that what you’re actually talking about is an API change. APIs must change in order for architectures to change. Use of solid software design is not new. It’s just new to PHP because PHP is only recently able to support it. Most PHP frameworks are laughably behind software that was written 20 years ago. I’m not hating on PHP, I really like what it’s becoming. I’m just saying that what it WAS should no longer be considered good enough because now a solid stack that can support good design and we should not be dealing with as much resistance in the transition as we have been dealing with as a community.

      This isn’t about selling seminar tickets or playing with toys. This is about business and business needs change and it may not be fun for everyone but it’s our job. The work that is behind us isn’t invalidated just because we’ve found better ways to do the work that lies ahead.

      1. parkerandhobbes · ·

        You’re clearly a very talented web developer. You’re clearly very passionate about web development. You’re clearly a person who is committed to ongoing learning and improvement.

        Where our opinions differ is on the issue of business. I can give you the names and addresses of businesses which have gone under because of ‘Entrepreneur Held Hostage‘ scenarios. This basically means that business owners are being left with esoteric web applications which hardly anybody can understand.

        I read your blog today and you were saying that you’d applaud a developer who decided to use Kohana to build a commercial site for a client. Shawn, that might be a good web development decision but it would be a TERRIBLE business decision.

        Do you not appreciate that while people like you are dancing around between different versions of new and obscure PHP frameworks, you’re creating hostage situations for your clients? More than that, you’re creating a prison cell for yourself. Do you get that?

      2. shawnmccool · ·

        I’ll just say that I know from experience that finding a PHP developer that can handle taking over a reasonably application written in a standard MVC framework like Kohana is not difficult. This is a straw-man argument.

        The problem is when developers go rogue and make (like you said) a ridiculous esoteric codebase and nobody here is advocating that. When you are in a discussion about “frameworks” you are specifically AVOIDING that entire aspect of the conversation. The only thing that is left is the chance that some terrible developer can make terrible code with a framework and that’s never going to change and no framework is safe.

  9. parkerandhobbes · · Reply

    You’ve certainly got that right!

    This is the point where I switch from being debater to student. Let me run one thing past you while I have your attention:

    We both agree that people writing duff code is a problem. I actually think that we’ll always have people writing code differently. Everyone has their own way of doing things and we’ll never code in precisely the same way. Even with the best intentions in the world, there will always be subtle differences between how you code and how other people code.

    As far as I can tell the only solution to this is going modular and for most frameworks that means using HMVC. If we can break things down into modules then we can all work together with a degree of harmony, without tripping up over each other and without having to write precisely the same code as each other. If you agree with that then surely it’s not Codeigniter that’s dead, but MVC itself! Do you agree?

    1. shawnmccool · · Reply

      Right now we’re in the middle of a PHP Renaissance. Laravel 4 is the first framework to really do this, but it won’t be the last. Laravel 3 has been refactored and decoupled and improved upon into a suite of components called Illuminate.

      These are available via Composer. You can use any of these components in any application that you want. If you want Laravel’s database layer in CodeIgniter? Can do. It’s like an a la carte menu.

      Laravel 4 is the framework that results from combining all of these components together. The power here is that it uses Composer very well. You can add any Composer packages that you want and the classes will be autoloaded through the Composer autoloader.

      Want Blade templating in a Kohana app? Great. Want to build a base framework off of a handful of Illuminate components and then take it from there? No problem.

      Similarly you can use the Illuminate routing component with Doctrine for your DB interactions, and some other composer package for templating your views.

      Interoperability is the future for PHP developers. Laravel 4 is a great example of it but it definitely won’t be the last.

      It’s truly a GREAT time to be a PHP developer. We have incredible chances to grow that literally were not an option before.

      I advocated CodeIgniter for a long time. And any time I wanted to improve upon my algorithms I would have had to hack the core. Everyone knows that is not good. I got tired of having to decide between which bad practices to take in order to implement good practices. I almost left PHP entirely. But, it’s the new tools that have been showing up that give us a chance to do GOOD software design and not just GOOD ENOUGH software design.

      I 100% agree with your point that we have to be careful about the trade-offs of new tech. And no, using the latest tech on every project is NOT the right solution. You’re very right there as well.

      It can be difficult for a lot of developers to know where to draw the line. But, to any who may be reading all I can suggest is to find a developer that you trust and follow them until you understand the ramifications of the various solutions that you have to choose from. There are no hard and fast rules, there are only solutions that have pros and cons. Unless you know the pros and cons thoroughly you can’t make a great decision on those alone and you should follow what is typically considered best-practices. But, once you gain enough experience you’ll find that rules are made to be broken. It just seriously requires the right mindset and the right experience to make that call responsibly.

      1. shawnmccool · ·

        By the way, when I say “you” i mean “one” as in someone.

      2. parkerandhobbes · ·

        This is one of those very rare occasions where I’ve gone back, done some more research and have now changed my mind. So I’m back again with a brand new point of view.

        I’ve now had a chance to look more closely at Laravel and I think I probably got it wrong. I can see how there are indeed significant leaps forward with that particular framework. I’m beginning to think that I got it wrong with this entire article. At the time of writing I was paranoid about the prospect of there being a new rewrite culture taking over the PHP community. I felt that this rewrite culture was driven primarily by commercial interests and I felt a need to voice those concerns.

        One of the nice things about being a human being is that we can always learn from our experiences and evolve into even more spectacular creatures! So, I’m quite happy to hold my hand up and admit when I got the wrong end of the stick.

        I’m tempted to delete this whole article but I’ll leave it up because I think there is still a valid concern about frameworks being written frequently and without good reason. That voice of decent should be heard and I hope the people behind the new rewrite culture (I’m hanging onto that phrase) will take that on board. I do not want to waste six months of my life learning some new framework only to discover that it has been ditched and rewritten.

        Shawn, if you read this, I think I’m also beginning to agree with you that CI is dead. However, I think that the explanations behind the downfall of CI are more to do with politics than code.

  10. Hi,

    Thanks for such a great information. In these days its hard to find a honest blog about zend framework developer

    This is sooo exciting! I love your blog and check it every day.the blog has grown so much. Wish you & the blog more success!

    God bless 🙂

  11. The comments have made the article more illuminating. Thanks David and Shawn. I found this article at a very crucial juncture when I’m choosing a framework, and it did help a lot! 🙂

  12. How much of this rewrite ethic is motivated by fundamental improvements to PHP itself? Does, for example, the addition of namespacing present an opportunity for improvement that cannot be realized without a fundamental rewrite of the framework?

  13. Worked with Ruby on Rails for a while. Same thing. Those guys had more rewrites than documentation pages 😀 Insane indeed.

  14. One of the reasons CodeIgniter “is dead” is perhaps the legacy support is so hard advocates. While it does not support new PHP features, and relies on PHP <= 5.1.6 (!)( that was release on 4 Aug 2006, clearly shows that the leadership has no plans to make it anything more than what it is. Every language that wants to evolve deprecates features and implements new ones, so why shouldnt frameworks take advantage of these features? I think that this is just a norm in the development game, and personally, i love to research new ways to solve problems we, the developers come across in the most elegant way.

  15. Agree 100%

  16. Dragan Krstic · · Reply

    There is one, and just, one crucial flaw in any rewrite – stability. As much we tried to do all the good stuff with the code, there’s those part of code that adds stability – a patch that handles quirky header from IE, an utility class that leverages Oracle data types and some strange lines of codes that prevents application to fall apart and wipe all data.
    Each rewrites removes “patina of experience”. Moreover, rewrites adds on complexity. One of motives usually are enforcing of conceptual clarity and it is very hard to not to over-abstract things. Everything this days are iterators, factories and that stuff… Then, somewhere in the process application’s/framework’s interfaces are changed, as old one is hard to implement or doesn’t satisfy ‘concept’.
    So, truth is somewhere in between. There is bunch of CI 1.5 and 1.7 application I’m maintaining. People still uses Joomla!1.x at the large… Rewrites doesn’t mean that programmer should leave framework that works for him, yet, programmer should strive to widen and polish his skills. Framework authors should have that in mind. Their job is to make our life easier.
    As Linus once said: “Userspace should not be broken”

  17. Symfony2 showed the way, the others followed.

  18. Over the years I have built my own framework. I will say I do use a lot of other people classes, and code snippets, but at least I don’t have to worry about major re-writes and steep learning curves (ZF2).

    I am currently looking at different frameworks to see what I might be missing. I started looking at ZF again, (last time was about 4-5 years ago I guess) and I am still not very excited to jump on that bandwagon. I can’t believe the overhead would minimal with it.

    At the moment I am looking at Symfony2. I like it better, but still I am wondering if I should not just stay with what I know best. My own modules I have built over the years.


  19. I think most of this rewrite on Zend2 and Symfony2 is simply due to php 5.x and the use of namespaces and new things that previous php versions did not have.

  20. I use Drupal 7 but i’m not developping in Drupal. I’m quite anxious of the upcoming move from D7 to D8… So as a user, i understand the argumentation about the rewriting thing threatening working application… In the other hand, i’m only talking about a blog here :p

    In the other hand, i’m working with Zend Framework. It costs me a lot of time learning the Framework but for my part, it takes more time learning OOP than the actual framework API. It does not cost a penny though because there’s a lot of helpful blogs and tutorials online for that.

    I just want to propose an explanation to the rewriting of the Zend Framework. At the time of ZF1, there were a lot of discussions and argumentations about the framework lacks (such as the ability to build modular applications for example).
    The refactoring (or rewriting) introduces the modular management, the service management, the event management…
    As Shawn explained it, we, as developpers, should consider ZF1 and ZF2 as two differents frameworks. Your web app was coded with ZF1. So be it. It won’t be deprecated from one day to another. Your next web app can be – should be – coded with ZF2… And that’s it. ZF2 introduces new concepts and new way to build your web app. And that can only be a good thing.

    1. Joefresco · · Reply

      “Your web app was coded with ZF1. So be it. It won’t be deprecated from one day to another. Your next web app can be – should be – coded with ZF2… And that’s it.”

      The question is… how long will ZF1 be maintained and get security update support? The answer isn’t forever. So at what point are you exposed to security issues that won’t get fixed? Whatever that date is, you want to be gone by the time that happens.

      I have a large commercial ZF1 app that is about to begin its transition for the above reason. The symfony2 roadmap page is exactly what I’m looking for to make my business long term plans. The ZF crew has been very nebulous with what their plans are for ZF2, and I don’t want to go through a second major upgrade. With the other frameworks, it seems they are more like ZF (or worse) where they may start with major breaking changes at any time with no clear roadmap or security support timeline. All Yii says is that they will provide security updates for Yii 1.x for 1 year after Yii2 comes out. The others don’t say anything I can find.

      Software needs to both change and be stable to make business sense.

  21. […] The entire Python community appears to be pushing in the same direction.  They’ve got an abundance of learning resources, they’re not all constantly at each other’s throats, they’re not suffering from an identity crisis and – unlike PHP – they’re not part of some insane rewrite culture. […]

  22. Rodrigo · · Reply

    I’m not the best programmer either, but I have several years of experience in web development, especially with ZF 1.X. And since that version, I think It is fine rewritting the framework.
    Modules in ZF 1.X were a nice try, but not enough. Have you seen how python manages packages? It’s really cool. Now with ZF 2 and composer you have something similar to that.

    Big changes are always hard to learn, but the y are required, you just cant expect having support for a framework for so many years ( ZF 1 was released in 2007, 7 years ago!!!!) World of web development is growing and changing very fast, php has a lot of good “rivals” such as ruby, django, node, java, etc and if We dont move quickly, php and its frameworks will become in a old way to make Web Page.

  23. […] the last few years, the PHP community has been taken over by rewrite culture.  Personally speaking, I think I was the first person in the web development community to write […]

Leave a Reply to paat4 Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: