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.
3 comments:
Potential clients right now seem to be confusing frameworks with content management systems... I had one project that I bid on that he was convinced he needed Drupal, but he could not articulate exactly what functionality was in Drupal that he needed! I think I scared him off when I told him to come up with a requirements document before deciding if he even needed Drupal or not... he didn't sound impressed. He reacted as if not wanting to use Drupal meant not knowing how to use it. I can write almost anything I need myself in PHP, but I can also see the value in using a framework. But it is really vexing at how people are jumping on the framework band-wagon with no educated opinion on exactly why! Thanks for this thoughtful article.
i have been using php frameworks for the past three years and have seen it advantages. But most of the time it interferes with application design and you are stuck with what library do i download or some thing...reducing flexibility. The best framework should only help in having a good structure with super flexibility without interfering with application design... that is why i wud use backbone.js to angular.js....and so on. The problem we should solve is struture... And i think that is why only you can determine that. great article
First thing must be said, Really good article. I am an amateur web app developer. so far i built only one web application, i wrote it without a frame work. I generally prefer writing code without using a framework. I want to start another project i v been looking for a good framework to start with and then i heard about play framework. I decided to go head and try it. I liked it at the beginning but then i started to hate, because it has so many little configurations that need to be setup and as well as lots of shitty compiler errors.
Anyways, my point is within the time i was stuck at many things for simple process. I could have already written half of my application in straight code.
If u see it as your main priority is get that application done rather than how you get it done. I guess in that case i would much rather prefer writing my application in straight code .
Post a Comment