Do all frameworks really suck?

Ahem.  So anybody that’s known me for a while has likely heard me say something similar to what is quoted in Cal’s article about OSCON.  I should clarify because I hear jokes about "Tell us what you really think".

Choosing a framework to implement your web app is a trade off like any other design decision.  Let’s focus in on specifics and talk about what the trade off is that you make when you choose a framework.  Specifically, I’m talking about MVC frameworks in PHP.

Good things

  • Frameworks provide a common method of code organization, so developers can both a) get up to speed fast, and b) don’t have to think hard about how to architect an app.  They are effectively a standard for application architecture.  This is particularly useful when working with large dev teams or junior devs.
  • Frameworks encourage the separation of the presentation layer from the business logic, avoiding a frequent PHP worst practice where stuff is all mixed in together.
  • A framework can encourage secure coding through the use of dispatch architectures.
  • In general, frameworks avoid spaghetti coding.

Bad things

  • MVC is a design pattern.  As frequently mentioned by the good ol’ Gang of Four, every implementation of a design pattern is different, depending on the specific viewpoint of the implementor, and the specific application we are trying to produce.  This causes two problems.  One is that the implementor’s viewpoint is not necessarily the same as mine.  The second is that trying to shoehorn every app into the MVC structure isn’t always appropriate.
  • Most MVC frameworks have an intentionally flat design – models, views, controllers – and when codebases grow, you need to modularize for maintainability.  There are different ways to do this, but many frameworks don’t lend themselves well to this.
  • In the world of PHP, as with Perl, there is More Than One Way To Do It.  Specifically with frameworks, I believe Luke has been known to say there are 2.3 frameworks per PHP developer.  They are like content management systems or blogging systems.  We’ve all done it, sad to say.  The downside of this is that you lose a lot of the programmer speedup if programmers have to learn a new framework on every project.
  • Bloat is a problem in a lot of frameworks.  That’s what "makes the magic happen", but typically using a framework means lots of files getting opened (required/included) behind the scenes.  This slows down your app.  See for example Paul M. Jones’ (updated) benchmarks.  (That, by the way, is an excellent, excellent article that displays a good methodology for researching design decisions.)  I’ll also refer here to what I sometimes jokingly call Thomson’s first rule of software design: First, do the simplest thing that could possibly work.
  • It’s virtually impossible to retrofit an MVC framework on to existing code.  A lot of us spend most of our careers dealing with existing applications.

In summary:
Let’s be clear here: I am not recommending people write spaghetti code, or that they embed HTML willy- nilly in their PHP.  My recommendation in making any kind of architectural decision is to know what tradeoffs you are making and make an educated decision.  It’s important to remember that you can follow some of the basic rules of MVC and get a good number of the benefits without the bloat.  It’s equally important to remember that there is more than one way to architect a web app.

I’ll try and blog in future about a couple of other related topics: MVC in Rails compared to MVC frameworks in PHP, and templating systems.  (Unlike frameworks, all templating systems really do suck 😉 )

4 thoughts on “Do all frameworks really suck?”

  1. I have to disagree with a lot of points in this post. For starters, i have integrated MVC on top of existing code successfully and without much difficulty. Since most MVC frameworks in PHP use mod_rewrite rules that include !-f before passing the request to the framework, existing .php files will work just fine.

    We use Fuse as our framework, and while any framework is going to increase the footprint of your code, it’s a small price to pay for the fact that Fuse drops out development time by something in the area of 85% on most projects.

    Finally, I love the templating engine in Fuse and, to a lesser extent, CodeIgniter and Smarty. So, I can’t agree that all templating systems do suck. I can’t stand seeing “templates” that are really just inline spaghetti code called by a controller

    just my opinion – good post either way

  2. All frameworks suck for one, and only one, reason. Have you ever tried profiling a framework based application to improve performance?

  3. Yes, they do.

    What happened to people who can code in the raw language?

    Using any framework, whether it’s CodeCoffin, AppShackler, or Ruby in Chains…is like welding a set of training wheels and aluminum crutches to your code.

    Frameworks are baggage-laden, arbitrary, ephemeral, third-party code-generating tools that remove you from the core language. In fact, they’re usually written in the core language itself. Anything you can do in a framework is something you can also do in the raw language…and usually in fewer lines…and in a location and style that will be consistent with the rest of your application.

    Frameworks don’t help coders improve. They make overly-dependent, unambitious coders who mostly “surf and scratch” code rather than write it.

    Frameworks don’t expand a programming language. They distract from it and hold it back. A community should reinvest in its language – not scatter in dozens of different directions.

  4. In certain way, PHP/JAVA or any language is a framework. It’s like, every human has the simpliest framework – two arms and two legs, only not everyone can be legenary Bruce Lee. So we can just take good shit from learning and using frame work. No need to hang upon any. Sooner or later, we should be able to dismentle our favorite framework (legally if) and make something/anything for our goal.

Leave a Reply

Your email address will not be published. Required fields are marked *