It is generally accepted that development toolkits and frameworks are a good thing, and assist developer productivity.
A few developers would differ, but to be honest they are quite likely just complaining about the learning curve that must be mounted before seeing the productivity and other gains derived from frameworks.
Once over the curve, there’s no question that significant mileage can be gained by the use of framework and tools. Take JUnit as an example: JUnit is a broadly applicable testing framework. Its learning curve is short—it can be mostly digested in a few hours, and mastered almost entirely in a day or two. It is highly extensible, brings immediate benefit, and is widely adopted—all characteristics of a “good” framework.
JUnit is also a good example of a “lightweight” framework. By lightweight, I mean that there is not a huge amount of code involved in JUnit—its API can be easily understood in a few pages of documentation. Usually, these are the subjective metrics applied to a tool to determine whether it is “light” or “heavy.” The number of dependencies involved is also a good indicator: JUnit is entirely container within a single jar file, and requires no additional jars to do its job. From a perspective of learning curve, JUnit can be adopted with a few hours’ effort at most—although truly mastering all it’s capable of might take a bit longer.
Now, that is not to say that there are not a great many “add ons” for lightweight frameworks—there are, and JUnit is a good example of this—but in the case of a tool such as JUnit, the “core” of the tool is thin indeed.
As in the world of fashion, thin is “in” lately. Lightweight databases, lightweight application servers, lightweight protocols—the Java development world is positively floating away on a feather-like tide of “lightweight.” Why is “light” good? What is it about a “lightweight” solution that makes it superior to a “heavy” solution? Indeed, having defined “lightweight,” what is heavyweight?
Look at the other end of the spectrum somewhat, and examine a toolset most developers would consider “heavier” than JUnit: The JBoss application server. Not that it makes any attempt to service the same niche (JUnit being a testing framework, and JBoss being a full J2EE stack), but JBoss does easily personify a well-known “heavier” tool. J2EE itself, for that matter, has gained a reputation for being a bit stout, although serious efforts to simplify and “lighten up” the API are showing fruit lately. The most obvious difference between these two opposite ends of the weight spectrum however, other than their different functions, is the amount of services and capabilities provided. JUnit does very little: Like a good framework, it provides mostly a skeleton onto which the developer him (or her) self grafts the meat. You write tests to a certain structure, then use tools that run those tests that work because they know the structure to expect. JBoss, on the other hand, provides a great deal of code to do a great many things: Volumes have been written about the J2EE specification, and JBoss application server sorts, washes, and dries in every area of J2EE. However, the comparison is somewhat apples-to-oranges, as JBoss is not precisely a framework in the classical sense.
When comparing application frameworks, the same contrasts can be seen as you saw above, however: Some frameworks take the “thin” approach, and are generally easier to learn and integrate, while others provide more than just a skeleton, and as a result are often a bit more work to get started with. In fact, some frameworks that take the “thick” approach begin to move beyond what is normally described as a framework at all, and into the realm of an “application toolkit,” for lack of a better term. One example of such a contrast is the extremely popular Struts framework and the somewhat less well-known Cocoon framework. Taking very different approaches, both frameworks nonetheless can serve as the basis for building Web applications, and Struts is definitely “lighter” than Cocoon. Most developers would agree that the learning curve also fits the comparison: Struts can be adopted generally more rapidly than Cocoon. Once you get into the task at hand, however, the actually building of applications can proceed much more rapidly in many cases with the “heavier” Cocoon than with its lighter cousin. In a number of projects, especially those with a great many UI “pages” to be handled, Cocoon can bring the power of its highly structured XML/XSL foundations to bear and make short work of producing a rich and complex UI.
On the other hand, simply configuring and setting up Cocoon for deployment may be more than a very small project requires—such a “lightweight” project might be better served with the lighter Struts. Assuming a similar level of expertise in both frameworks, however, it would be very clear to see the difference when attempting to accomplish some development tasks: say, for example, producing a PDF “printable” page for every existing page of a Web application. In Cocoon, this is a matter of creating one stylesheet and a few entries in a configuration file. With Struts, the work would be much more involved, probably requiring a whole new page structure parallel to the existing pages (if basic JSP had been used initially).
To go back to the question—when looking at frameworks or “toolkits” to boost your application development productivity, why is “light” popular? Part of the answer may lie in effective marketing. A “light” tool is easier to get started with. As a result, more people who try it are apt to stick with it long enough to get results. This results (often) in a larger number of users, and therefore more “success stories.” This in turn can boost the popularity of the tool.
“Heavier” tools and frameworks, on the other hand, often (not always) being more difficult to get started with restrict their “audience” a bit more. In many cases, however, the “heavy” tool provides a richer set of functionality than a comparable “light” tool, so although the initial learning curve and rate of adoption is lower, the overall benefit from “sticking with it” and getting the tool working in your environment may be greater. If the additional benefit of the “heavy” tool is worth the longer learning curve, it’s still a better tool. If, on the other hand, your project is small, time-critical, and doesn’t have sophisticated requirements, the “light” tool with the fast learning curve might be all that’s needed.
The important conclusion you can draw, though, is that lighter is not always necessarily better. Ant, for example, is, at first glance considerably “lighter” than its cousin Maven. Maven, however, does so much more in terms of built-in capability that the more extensive learning curve (and it’s not that much more) is probably well worth it for many projects. Many developers apply the “up in five minutes test,” to their own detriment. This is where, when testing a new tool, they expect to be up and running, doing something productive, in a very short period of time. Most developers know that five minutes is a bit unrealistic, but after an hour or two of tinkering with a new tool (and maybe, for the more disciplined, reading the first few pages of the documentation), they’re ready to make a decision. If they don’t already see benefit and productivity gain, they often decide to scrap the tool, rather than digging further into it. Sometimes this can be a costly decision. Think about how much time you spend developing, and think about how much time and effort the tools you use now are saving you. Isn’t it worth a bit more effort to dig into some of the more complex tools and frameworks available to see if they have much more to offer than can be discovered in an hour or two?
One size seldom fits all, and sometimes the right answer really is to use a bigger hammer!
About the Author
Michael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at mnash@jglobal.com.
