The other day we had an interesting discussion at work about when the overhead of using a framework is justified. Incorporating a framework into an application has costs in terms of performance and complexity. In this case, we have a few JavaScript features that we wind up using on most Web sites, and the question was whether or not to use jQuery to reimplement those features, or to just use some simple home grown scripts that we already had.
The argument against was that we already have scripts (even though they need some updates), and that the compressed jQuery file is still over 20 kilobytes. Plus it’s an additional dependency that could introduce conflict with other choices we make later on.
In the end, we wound up choosing to include jQuery, for a couple of reasons. The first is that it makes the framework responsible for most of the code that’s likely to require more maintenance due to browser inconsistencies. When Internet Explorer 8 is released or Firefox 3.1 comes out, jQuery contributors are likely to find most of the bugs and inconsistencies and release an update that fixes them. Even if I have to fix some of those bugs, I’ve found that the frameworks still save time. I had to fix an Internet Explorer 5 bug in Prototype once, and I didn’t find it that difficult, even though most of Prototype’s source looks like magic to me.
The second is that incorporating the framework lowers the bar for adding new features to the Web site. If jQuery is already available, the barrier to writing new features is much lower than it is when writing those features from scratch, and I don’t have to revisit the decision whether or not to add a framework at that point. It becomes a tougher decision when you already have non-framework code in place.
I’ve become a fan of using a framework from the start, especially if the framework adds at least some value to even simple tasks. For example, JavaScript frameworks like jQuery make almost everything you do a little bit simpler, from binding events to altering styles on the page. They may not save you much time in your initial efforts because you’re doing something simpler, but you’ll be prepared to reap more efficiency as you add features to the site in the future. And you’re then not forced to make a tougher decision about when to add the framework later (especially if it would require writing non-framework code).
There’s probably an economic argument to be made here about marginal costs. Adding a framework increases the fixed costs of an application in terms of time and complexity, although the simplest frameworks make these fixed costs almost negligible. There’s a cost involved with setting up the framework and learning enough about how it works to employ it effectively. However, the right framework will lower the marginal cost of new features.
My thought is that it’s almost always worth it to eat the fixed costs of using a well-chosen framework to gain the marginal cost benefits when writing new features.
When’s framework overhead justified
The other day we had an interesting discussion at work about when the overhead of using a framework is justified. Incorporating a framework into an application has costs in terms of performance and complexity. In this case, we have a few JavaScript features that we wind up using on most Web sites, and the question was whether or not to use jQuery to reimplement those features, or to just use some simple home grown scripts that we already had.
The argument against was that we already have scripts (even though they need some updates), and that the compressed jQuery file is still over 20 kilobytes. Plus it’s an additional dependency that could introduce conflict with other choices we make later on.
In the end, we wound up choosing to include jQuery, for a couple of reasons. The first is that it makes the framework responsible for most of the code that’s likely to require more maintenance due to browser inconsistencies. When Internet Explorer 8 is released or Firefox 3.1 comes out, jQuery contributors are likely to find most of the bugs and inconsistencies and release an update that fixes them. Even if I have to fix some of those bugs, I’ve found that the frameworks still save time. I had to fix an Internet Explorer 5 bug in Prototype once, and I didn’t find it that difficult, even though most of Prototype’s source looks like magic to me.
The second is that incorporating the framework lowers the bar for adding new features to the Web site. If jQuery is already available, the barrier to writing new features is much lower than it is when writing those features from scratch, and I don’t have to revisit the decision whether or not to add a framework at that point. It becomes a tougher decision when you already have non-framework code in place.
I’ve become a fan of using a framework from the start, especially if the framework adds at least some value to even simple tasks. For example, JavaScript frameworks like jQuery make almost everything you do a little bit simpler, from binding events to altering styles on the page. They may not save you much time in your initial efforts because you’re doing something simpler, but you’ll be prepared to reap more efficiency as you add features to the site in the future. And you’re then not forced to make a tougher decision about when to add the framework later (especially if it would require writing non-framework code).
There’s probably an economic argument to be made here about marginal costs. Adding a framework increases the fixed costs of an application in terms of time and complexity, although the simplest frameworks make these fixed costs almost negligible. There’s a cost involved with setting up the framework and learning enough about how it works to employ it effectively. However, the right framework will lower the marginal cost of new features.
My thought is that it’s almost always worth it to eat the fixed costs of using a well-chosen framework to gain the marginal cost benefits when writing new features.
Commentary
software developmentWeb development
Previous post
Dog whistle politicsNext post
The candidates on evil