Why you should NOT use a web framework
I honestly can't believe I just wrote that. I have been a huge proponent of using frameworks for a long time now and I still think they are valuable. There is great value in frameworks and proponents have written about why you should use them ad nauseum. Every conference you attend will invariably have a session or two on the state of web frameworks, new web frameworks, and how they are fixing all the things that have ever sucked in the whole world when writing web apps.
B. S.
Like I said, I do believe in web frameworks, but many developers start the process of building a new web app with choosing a framework before even evaluating the need for one. You don't need a framework to build a good web application. I find the arguments of "plumbing is done for you" and, "you get reusability" to be unrealized potential and often over-complicate very simple concepts. Before adding complexity to an already complex system, you need to make sure you are actually going to use the features that create that complexity. When is the last time you rewired struts application inside the struts-config.xml so it did something different or reused an action and forwarded somewhere else when you were done? Those kinds of things are just generally not done and if they are it's a lot more painful than advertised.
One reason I like frameworks, and what I see is the most useful reason to have them is that you can throw a whole bunch of developers who come from different backgrounds and different skill levels and, since they have to fit into the framework you choose, you generally get similar output. That said, just because Struts or Seam or Shale or Stripes or Spring help you implement MVC doesn't mean you actually get MVC. I can't tell you the number of applications I've worked on where the entire concept of the separation between view and control layers is just lost. When you tell me it's MVC and it's not, it's almost more confusing than if you just throw up your hands and say, "stuff is everywhere".
One of the major reasons not to use a framework is the amount of overhead required for additions and changes. I know... this is supposed to be one of the benefits, but why is it that a simple change to a theme requires a change to the struts-config.xml, the tiles-defs.xml, the Action class, the ActionBean class and so on? In some web apps, the overhead is reasonable. In others, I can't actually justify it.
For instance, if you are working in a portal, the portal IS the framework. Why do you need to use a framework INSIDE the framework? Then you start matching up spring with struts and the amount of indirection makes it very difficult for a new developer to come into a project and trace through what is actually happening. If it takes more than a couple weeks for a new developer to be productive in your environment it's time to take a look at the complexity of the application and make sure it is warranted. Could a new developer trace through the code or would they be stuck because it's not apparent that you are injecting values with Spring or using some AOP concept because the original developer thought it was pretty cool. This is also a reason I don't endorse the ExpandoMetaClass functionality in Groovy. Its neat that you can override methods but if you can't expect a class to function the same way every time, you are really opening yourself up to a lot of unnecessary issues.
Author and speaker Scott Davis at the 2007 No Fluff, Just Stuff conference said something so ridiculously simple that I almost dismissed it as obvious the first time I heard it. If you are trying to decide what web framework to use, stop deciding and don't use anything. Then if you find that you need it, add it later and do some simple refactoring. If you hit the hardest problems first and you get through them without using a framework, it's likely you won't need it.
The one thing this type of development requires is consistency from your team. If you are a very small team, keeping things under control is easy. If you are more than 5 developers, it will be a little harder to make sure your developers are following good design principles or you're going to end up with a mess. The thing is, I've seen so many web apps that use frameworks and are still a mess, I'm starting to be convinced that they don't actually prevent the mess, they just structure it.
Lastly, if you are going to use a framework go for simplicity over bells and whistles or configurability. Most times, configurability is a very difficult thing to accomplish, it adds a ton of complexity, and the goals are often not realized. By the same token, bells and whistles are often more trouble than they are worth. The more focused your use for a framework, the more value you'll actually see from it. I agree with the idea of deciding how to build your application first, then pick the simplest possible framework that allows you to accomplish your goals where one of those choices is no framework at all.
B. S.
Like I said, I do believe in web frameworks, but many developers start the process of building a new web app with choosing a framework before even evaluating the need for one. You don't need a framework to build a good web application. I find the arguments of "plumbing is done for you" and, "you get reusability" to be unrealized potential and often over-complicate very simple concepts. Before adding complexity to an already complex system, you need to make sure you are actually going to use the features that create that complexity. When is the last time you rewired struts application inside the struts-config.xml so it did something different or reused an action and forwarded somewhere else when you were done? Those kinds of things are just generally not done and if they are it's a lot more painful than advertised.
One reason I like frameworks, and what I see is the most useful reason to have them is that you can throw a whole bunch of developers who come from different backgrounds and different skill levels and, since they have to fit into the framework you choose, you generally get similar output. That said, just because Struts or Seam or Shale or Stripes or Spring help you implement MVC doesn't mean you actually get MVC. I can't tell you the number of applications I've worked on where the entire concept of the separation between view and control layers is just lost. When you tell me it's MVC and it's not, it's almost more confusing than if you just throw up your hands and say, "stuff is everywhere".
One of the major reasons not to use a framework is the amount of overhead required for additions and changes. I know... this is supposed to be one of the benefits, but why is it that a simple change to a theme requires a change to the struts-config.xml, the tiles-defs.xml, the Action class, the ActionBean class and so on? In some web apps, the overhead is reasonable. In others, I can't actually justify it.
For instance, if you are working in a portal, the portal IS the framework. Why do you need to use a framework INSIDE the framework? Then you start matching up spring with struts and the amount of indirection makes it very difficult for a new developer to come into a project and trace through what is actually happening. If it takes more than a couple weeks for a new developer to be productive in your environment it's time to take a look at the complexity of the application and make sure it is warranted. Could a new developer trace through the code or would they be stuck because it's not apparent that you are injecting values with Spring or using some AOP concept because the original developer thought it was pretty cool. This is also a reason I don't endorse the ExpandoMetaClass functionality in Groovy. Its neat that you can override methods but if you can't expect a class to function the same way every time, you are really opening yourself up to a lot of unnecessary issues.
Author and speaker Scott Davis at the 2007 No Fluff, Just Stuff conference said something so ridiculously simple that I almost dismissed it as obvious the first time I heard it. If you are trying to decide what web framework to use, stop deciding and don't use anything. Then if you find that you need it, add it later and do some simple refactoring. If you hit the hardest problems first and you get through them without using a framework, it's likely you won't need it.
The one thing this type of development requires is consistency from your team. If you are a very small team, keeping things under control is easy. If you are more than 5 developers, it will be a little harder to make sure your developers are following good design principles or you're going to end up with a mess. The thing is, I've seen so many web apps that use frameworks and are still a mess, I'm starting to be convinced that they don't actually prevent the mess, they just structure it.
Lastly, if you are going to use a framework go for simplicity over bells and whistles or configurability. Most times, configurability is a very difficult thing to accomplish, it adds a ton of complexity, and the goals are often not realized. By the same token, bells and whistles are often more trouble than they are worth. The more focused your use for a framework, the more value you'll actually see from it. I agree with the idea of deciding how to build your application first, then pick the simplest possible framework that allows you to accomplish your goals where one of those choices is no framework at all.