Tiffany B. Brown

a mish-mosh of stuff

Frameworks: Yay! Nay! How do you decide?

Frameworks in web development have been the hotness for a few years now. But not everyone is “frameworks! yay!” A few high profile developers have questioned their use.

The goal of frameworks — be they server side, JavaScript-based, or CSS-based — is to decrease development time. With server-side frameworks, I also find that they force some organization and structure to my code that it might not otherwise have. But every framework has a learning curve.

They also come with a performance cost. More code means more processing time and/or effort, longer download times and — this is particularly important when talking about client-side code for mobile devices — more energy consumption.

There’s a trade off with frameworks, then, between development ease and optimized code.

I personally think CSS frameworks are overkill. Even using a reset style sheet is often more code than necessary. With JavaScript frameworks, my opinion is more balanced. JavaScript frameworks are wonderful for quickly creating animated effects. But if the task is just to toggle the visibility of an element or clear a search box, surely, custom code is the lighter weight option.

The one area where I am most in favor of using frameworks is application development. Applications have a lot of little pieces to worry about. I kind of like the reassurances that frameworks offer. That said, I agree with Rasmus Lerdorf that a good framework should be lightweight and speedy (his favorite, if you can call it that, is CodeIgniter).

But what about you? How do you decide whether to develop something yourself or use a framework / library? Do you prefer frameworks for developing server-side applications? What about for client-side development? When, where, and why do you use frameworks?

  • http://jasontoney.com/ Jason

    That Rasmus piece about PHP is interesting for me. We often have vendors who want to use PHP when building sites for the Mouse. We decline because they almost always fail load test. Rasmus talks about it not being able to scale to “yahoo” levels and while our traffic isn’t “yahoo” levels we test and optimize at about a tier or two lower than that. Anything that can’t handle over 100,000 simultaneous connections or well over a million hits/actions over a 24 hour period of time won’t launch with us.

    That’s not to say we wouldn’t accept it if it could but I think most developers do go the framework route because they don’t really have the time to build exactly what they need for the job and frameworks make it easier to get something that will work quickly.

  • http://jasontoney.com/ Jason

    That Rasmus piece about PHP is interesting for me. We often have vendors who want to use PHP when building sites for the Mouse. We decline because they almost always fail load test. Rasmus talks about it not being able to scale to “yahoo” levels and while our traffic isn’t “yahoo” levels we test and optimize at about a tier or two lower than that. Anything that can’t handle over 100,000 simultaneous connections or well over a million hits/actions over a 24 hour period of time won’t launch with us.

    That’s not to say we wouldn’t accept it if it could but I think most developers do go the framework route because they don’t really have the time to build exactly what they need for the job and frameworks make it easier to get something that will work quickly.

  • http://www.rashidmuhammad.com/ Rashid Z. Muhammad

    Speaking for the server side.

    I’m of the thinking that the logical progression of development in any shop that maintains more than one application is to build or implement a framework. It only makes sense, one of the biggest axioms of software engineering is to “do it once” and that’s pretty much the purpose of a framework.

    How the framework is implemented goes a long way to deal with the answers to your questions on dev time vs. speed (and I would add flexibility). I’ve found that you don’t necessarily have to compromise if your framework is driven by process instead of excessive abstraction – some people just want to configure applications into existence instead of writing them, and if that’s the case they need to change professions.

    I use my framework to handle the central plumbing of my applications. If I’m writing multiple applications for my organization, it makes no sense to reimplement the logging, data access, authentication and authorization for each one. The framework allows me to concentrate on the things that make the application unique and not worry about the drudge work over and over. Most importantly, having that core logic implemented once means that you only have to modify it in one place when it needs to be fixed.

  • http://www.rashidmuhammad.com Rashid Z. Muhammad

    Speaking for the server side.

    I’m of the thinking that the logical progression of development in any shop that maintains more than one application is to build or implement a framework. It only makes sense, one of the biggest axioms of software engineering is to “do it once” and that’s pretty much the purpose of a framework.

    How the framework is implemented goes a long way to deal with the answers to your questions on dev time vs. speed (and I would add flexibility). I’ve found that you don’t necessarily have to compromise if your framework is driven by process instead of excessive abstraction – some people just want to configure applications into existence instead of writing them, and if that’s the case they need to change professions.

    I use my framework to handle the central plumbing of my applications. If I’m writing multiple applications for my organization, it makes no sense to reimplement the logging, data access, authentication and authorization for each one. The framework allows me to concentrate on the things that make the application unique and not worry about the drudge work over and over. Most importantly, having that core logic implemented once means that you only have to modify it in one place when it needs to be fixed.

  • tiffany

    That surprised me too Jason. Yahoo! uses PHP extensively, but I don’t know how much they use it for database connectivity and heavy-duty crunching. But as Lerdorf said: PHP wasn’t designed for that. That said, there are plenty of sites using PHP that can handle loads of traffic (like Friendster and Facebook). And many sites running PHP wisely make wise use of caching (creating static files to serve if there haven’t been changes to the content — always faster than a DB call).

    Rashid: If you’re using a personal framework or library, then yes, you’ve probably built it once, hopefully optimized it, and it works pretty well. I guess my issue is with developers using frameworks without thinking about whether it’s the best option.

  • tiffany

    That surprised me too Jason. Yahoo! uses PHP extensively, but I don’t know how much they use it for database connectivity and heavy-duty crunching. But as Lerdorf said: PHP wasn’t designed for that. That said, there are plenty of sites using PHP that can handle loads of traffic (like Friendster and Facebook). And many sites running PHP wisely make wise use of caching (creating static files to serve if there haven’t been changes to the content — always faster than a DB call).

    Rashid: If you’re using a personal framework or library, then yes, you’ve probably built it once, hopefully optimized it, and it works pretty well. I guess my issue is with developers using frameworks without thinking about whether it’s the best option.