Myths about Web Application Frameworks

Myths about Frameworks #1
Without a framework, you can't easily use 3rd party libraries.

This is self-evidently false. In fact, using a framework often makes it harder for you to use 3rd party libraries. This is because you are relying on the framework to support the library you want to use. This is on top of the rest of the stack that needs to support the library, Java, and the Application Server. If you are just building directly on your chosen platform, you have the pick of the crop when it comes to 3rd party APIs for that platform.

Myths about Frameworks #2
The only alternative to using a framework is rolling your own framework.

This is wrong. Perhaps people who say this are confusing a framework with a platform. Yes, if you didn't use a ready-made platform such as one implementing the J2EE or the Java Servlet Spec, then you would end up writing your own. That would be bad. However, fortunately we have JBOSS, Tomcat and so on. In most cases, things that are ostensibly provided (or supported) by the framework are in fact also provided by the platform out-of-box. Common examples sited are Security, (Authentication and Permissions) and URL mapping. Other examples mooted as things you would have to write yourself are database access and session management both of which can easily be implemented using either the built in support in your container or a third party library. How you organise your application is up to you. It's called software architecture, and before you argue:

Myths about Frameworks #3
Frameworks provide modularity and encourage layer separation.

No they don't. If you write your code in a language that supports modules (you use Java classes for instance), and you choose to write modular, self-contained code, that's what provides modularity.  No framework can provide any guarantee of modularity. In fact, using a framework often introduces dependencies and assumptions that eat away at the modularity of your code. That's how they can (in theory) speed up development. The techniques that are commonly used by frameworks, code injection, reflection, proxies, reliance on annotations need to make assumptions about your code in order to work and therefore actually create tighter coupling between layers of your code and thus reduce modularity.

This can be seen clearly when you create Domain Objects and let them be used in every layer of the application from the database (using a persistence API), the business layer, and then as a model used by the user interface. This creates a tight coupling between those layers that is not sustainable, since it means you can't change the model on the front end without having implications for the database. In order to change, you must create a new model, and have code that transfers the data from one model to the other.

This is fine to do once, but you might end up doing this many times between various layers of the application. It is best to accept up front that you can't have one model that will work for all layers. Each layer requires a slightly different way of looking at the data, usually combining it from different sources. Having a framework, encourages this 'single model' pattern since this is a way to 'get up and running quickly' which is often a prime stated goal of the web framework.

Myths about Frameworks #4
Frameworks speed up development.

This is probably the biggest myth going. It's also the most difficult to prove either way. There are so many variables: the size of the project, the number and skill-level of the developers and so on. So here I will try to break it down. How might a framework speed up development?

• Less spin-up time for new developers. As long as someone is familiar with the framework, and your project is adheres to the architectural guidelines put in place by the framework, then they should be familiar with the project.

The problem with this is that although it might be true, on all but the most trivial projects, the barriers to understanding a project are related to what the application actually does, rather than where the functionality interfaces with the platform. Also most frameworks don't really help you organise your code, that's why for every framework there are a so many forum posts about best practices for this.

• A lot of functionality is provided out-of-the-box, which saves you time.

This is a variation on myth #2. My response to this is the same: If you build an application to run on Tomcat for instance, you will find there is 'out-of-the-box' support for security, database connection pooling, URL mapping, and a whole bunch of other stuff. The benefit of embracing your platform, is that you are not introducing another layer of abstraction, and you are getting close to how the platform is supposed to work. Java Servlet containers implement the functionality as described by the J2EE or Java Servlet specification and you benefit, no matter who has developed the container. And if you use any functionality provided by your container which is in addition to to the J2EE spec, you are making a similar trade-off as you would by making use of functions provided by a framework. Any gaps can be covered by third-party libraries, which you can make use of in the best way for your application, rather than the way that the writers of the framework decided.

• Established frameworks are less prone to bugs than code you have written yourself and so you save time that you would spend debugging.

Anyone who has made use of a framework and come up against a bug, will know that this is a pipe-dream. Bugs in the framework itself are much harder to debug, and often impossible to fix. Most of the time you will need to implement an ugly work-around until the developers of the framework find the time and inclination to implement a fix. This is true with any code that you didn't write, but an application framework is particularly vulnerable to this. The problem is that the newer frameworks can take advantage of changes in thinking, design, and 3rd-party APIs, but they are the least mature, and most open to bugs. I'm not saying that using the container, your own code and 3rd party APIs is much better, but frameworks certainly don't give you a free ride in this regard.