These days, i’m generally a packaged framework-for-the-web curmudgeon. I prefer simple libraries corresponding to simple, common, generic problem sets. It’s one thing to adopt a general-purpose scripting language, or even a general-purpose “hard” programming language, but it’s another thing entirely to download or buy a prepackaged framework on the basis of marketing material or buzz about the shiny new ur-framework for all development. My opinion was arrived at mostly through personal experience, and undoubtedly people will have different opinions based on their own experiences working with such software.

My hypothesis is that frameworks tend to occur naturally out of the needs of specific applications of technology. If you’re using a programming language to build a listing-based website, and you’re building things from scratch, patterns will evolve in your code. If you’re being rigorous about refactoring, you’ll be acutely aware of patterns that may be abstracted away, and it will be very natural to reduce them in some form or another. Eventually, if you add more developers, the lead developer will probably generalize an approach to building features that looks awfully like a framework. It could be lightweight, generator based, MVC based, queue based, or whatever — but this evolved framework, at its essence, is a reduction of noticed patterns about listing data systems to practice. However, why not avoid repeating all this work, and instead skip it by picking up a third party off-the-shelf framework and starting with that off the bat?

A heavily evolved framework is a codification of patterns that work for a specific problem set. This is fundamentally what newcomers to programming languages do not understand when they go reading neato tutorials for the framework du jour. It is also what many framework zealots (and sometimes, evangelists) do not understand when they are aggressively hunting down misguided naysayers who misapply frameworks and complain about it in public.

The risk of having programmers begin their work on top of established frameworks is that they typically do not have the experience necessary to understand what patterns have been adopted, why they have been adopted, and how those patterns would apply to their task at hand. The only people who understand this are usually the most experienced developers of the framework.

Unfortunately, the type of developer most attracted to the marketing claims of frameworks are inexperienced ones. And even more unfortunately, most frameworks’ greatest advocates are experienced developers of the frameworks, whose subtle and nuanced defenses about the proper use of their framework go completely over the heads of most beginners, who only stare googly-eyed at fancy baked demos.

This leads to large, bizarre codebases built on hacks, on top of hacks, on top of frameworks. It also leads to completely unrealistic expectations from businesspeople about the sustainability of development pace for fast, new, framework-based prototypes. It’s par for the course for our industry, and it’ll probably continue for a very long time as the trade of programming grows up in the new century.

Is there a reasonable argument that some “general-purpose” frameworks are good enough for nearly all “straightforward” web applications? Maybe — but this is a tricky subject. Many web applications share the same fundamental characteristics. If you have a general-purpose framework, it may work especially well with the characteristics of web applications. The thing that most web applications have in common is that most of them are dropped far before they get to a very serious type of problem that i’m referring to. So, in the sense that I don’t believe most web applications will get very far, it’s probably fine to use a framework for experimentation or prototyping. But one should be prepared to do the real work at some point, if the project is to be taken seriously.

There is also the annoying fact that when frameworks are popular, they tend to be a big hindrance to prototypes that never got rewritten. The point at which the misapplication of technology becomes a problem too often coincides with surges in popularity of a service. This leaves you open to competition and puts you in a very difficult place, especially if you’ve worked hard to open up a new market.

My advice for anyone starting to get a bad feeling about frameworks: work on real world projects, and start from scratch at least once. Real world projects jolt you out of the 5-minute screencast armchair Internet expert mentality. They have messy requirements, will suddenly strike you with landscape-changing revelations about how you’ve been going about things wrong, and will challenge you to grow more than you thought you ever could. Invest in your frustration up front, and the reward? When you’ve built a mature project, maybe you can generalize it and turn it into a framework… ;P