Personal Bytes

Claudio Franco recently wrote a post (in Portuguese) wondering why people use a framework, even to concoct simple jobs. He raised some specific points and questions, namely if it’s really necessary to use a framework, if it’s the way of keeping things simple and if it compensates for the fact of having to include tons of extra files (ie, the framework).

I was about to write a comment on his blog, answering to his concerns by pinpointing ad-hoc benefits to using frameworks, but the comment would probably go off Wordpress limits and frameworks actually deserve some careful thinking and not ad-hoc insights. So here it goes, a post on Why Frameworks are A Good Thing.

Definition of Framework

There are several definitions of framework. Regardless of which one you pick, they followed the definition of a software component. Software components were created with the intuit of encapsulating functionality so it could be reused in a easy way. For instance, a component handling the authentication of your application could also be used in the future, as the basic idea behind the authentication system ought not to change that much from application to application.
Frameworks brought this concept to a whole new level. Wikipedia’s definition of framework is short but concise: a reusable design for a software system. Notice the emphasis on design.

So a framework can be seen as the underlaying foundations of a piece of software. This means portraying a particular design and architecture and, optionally, including handy libraries for helping you on the go. Ultimately, providing you with a working system that you can use to build upon, leveraging your work.

Framework as a Design

Explaining why a framework is a design concept gets us to one of its biggest advantages. A framework is a design because it inverts the control flow from you to the framework and imposes a way of doing things. MVC (Model View Controller) frameworks dictate that you should use, well, the MVC pattern. Imposing such a thing is good for two reasons. First, stops a lot of programmers from developing over-engineered solutions to simple problems. Think of this as forcing you to use a design pattern.

Secondly, it’s kind of an habitat. If a bunch of developers get together and everyone has experience of one particular framework it will be a lot easier for them to collaborate and work together. Compare this to the hard and painful task of understanding a third party code developed by one of the developers.

Hence, by imposing a design you’re creating an environment common to all developers and, on the other hand, stopping you from over engineering your problems.

Frameworks promote reusability

Frameworks usually come with extensive libraries that provide you with handy functionality. If the framework is popular enough, these have been tested and audited by tons of developers, sparing you some precious time. Even if you’re a very talented developer and you’re absolutely sure your code is bug-free, let me tell you something: you’re plain wrong. Your code will have bugs. Having it seen by tons of developers that will be using exactly the same code will help reducing the number of bugs. Granted.

By reusing the framework code you’re only doing yourself a favor: hardening the concrete you’re standing upon. The concrete is, of course, the building blocks for your application. The framework.

Moreover, you’ll have an unique chance to extend the framework’s capabilities and, hence, contributing to more reusable code.

What about the tons of extra and probably useless files?

Fortunately, a gigabyte is infinitely cheaper than it was 10 years ago. This means that wasting a couple of megabytes storing the framework along with your code will be the least of your problems.

If the framework is properly engineered, it won’t make use of files that it doesn’t need. For instance, Ruby on Rails comes with the hugely popular ActiveRecord, mapping database tables and records to classes in Ruby (models in Rails). But if you don’t use a database in your project, ActiveRecord will not be called even a single time, meaning that you won’t have any  performance penalties.

So, in conclusion, the size of the framework is irrelevant. What really counts is what you do with it.

Keep It Simple

It’s kind of obvious by now that you won’t be using a framework for a single page to display the current date by calling a PHP function. Granted.

But you never know about the day of tomorrow. The project might evolve, might grow. The team might get a few more elements meaning they’d have to get acquainted with the system.

Using a framework not only makes the task of integrating new people a lot easier, but also serves as the underpinnings for a much solid growth. Even if they don’t have knowledge of the framework, it probably has better documentation than the one you could ever write alone.
If we consider heterogeneous teams this claim holds even stronger. If you have web designers on your team the last thing you want to do is give them a file crippled with lines of code (basically, incomprehensible rubbish to them) mixed with HTML. You’ll want to give them a “view” with as less non-HTML code as possible so they can work freely and without worries. Even if we consider reputable projects like Wikipedia’s Mediawiki, you’ll see a lot of shameless PHP code containing logic mixed with HTML. So, if you actually managed to decouple the views and the logic, congratulations to you. You’ve just reinvented the wheel and built yet another web framework.

Are frameworks a silver bullet?

Of course not. You wouldn’t run a framework to generate Google’s front page. Frameworks do add an overhead to the running process so there might not be suitable for performance sensitive scenarios. Google probably has a C program waiting for a stream on port 80 over HTTP. Probably no complex Web Server sitting in between (I’m just speculating, I don’t know the fine-details of Google’s architecture. Just trying to make a point).

The point being that probably 99% of your application is not that performance sensitive that you’d have to discard the usage of a framework.

Bottom line

Frameworks are not, unfortunately, the holy grail. There is no such thing. But they’re a very important ingredient to building scalable and reliable software, leveraging not only your work but the amount of code you’ll have to write today or in the future. It’s not suitable for single web pages but it’s definitely something to consider if you want to keep your application steady and ready to grow.

And, above all, it’s always cool to welcome the upcoming newcomer with “Go RTM at http://rubyonrails.com” instead of “Checkout the latest version from the trunk, run through all the source code to understand the architecture of the application and then send me an email if you have any doubts. But I’ll be on vacations for the next two weeks, so as the Portuguese would say, desenmerda-te“.