This article craves for a global search & replace operation:

"framework" --> "monolithic framework"

I think a good framework should be developed as librairies each solving a particular problem, glued together. Of course, at first you'll probably have many things in core that don't really belong there but there must come a time where you refactor to separate functionnality into distinct librairies (that you can use without the framework!). The "vertical" integration is done by glueing the librairies that were developed alongside it in a coherent whole.

And I think frameworks should recommend approaches, not dictate them. For example, I'm fine with a framework that provides an authentication system out of the box, but it should be integrated as a normal plugin so that anyone can write a competing, alternative authentication system.

In other words, explode your framework in tiny pieces and then glue those together.

edit: I think that would be a boon for the adoption of a framework. People first start using some of your librairies, and over time they use more and more of your librairies and at some point they simply adopt the whole framework.

That's mostly a semantic game you're playing. What you term "monolithic framework" is what the author (and, IMHO, most developers) mean by the term "framework". The rest of your post describes what most people are happy to call a "library" or "toolkit", or "utility".

Frameworks, as understood by common industry terminology, are defined by providing the vertical integration you are talking about.

But look at the difference between Rails and Merb.

If you want, you can treat Merb as better Rails (e.g., multi-threaded, less magic) and use AR + erb. All very familiar.

Or you can see it as a pluggable framework, and use Haml instead of erb and Sequel in place of AR.

Typically, I think of a framework as something that calls your code, where a library is code that you call.

The line gets blurry, of course, because just about any framework is going to include some libraries, and you may use some libraries by registering callbacks. But, something that gives you a bunch of blanks to fill in with your code would be a framework.

Now, some frameworks include a set of libraries for the most common tasks you'd want to do when using that framework. E.g., a web framework that provides some sort of ORM. Usually, you can substitute other libraries for those purposes, but doing so has some cost (you feel like you're "fighting the framework", or, you need to deal with configuration overhead for those libraries you're not using). Ruby on Rails is an example of this. This is what I think the grandparent meant by "monolithic framework".

Other frameworks have a more narrow focus and expect you to select and provide libraries for common tasks. Ramaze (an alternative Ruby web framework) is an example of this.

Obviously, the line can get blurry, but most frameworks do seem to have a philosophy of "provide everything a developer needs to get started" or "allow developers to choose the most appropriate tools".

If when people talk about "frameworks" they're really talking about "monolithic frameworks", then maybe most frameworks indeed suck, because they're all guilty of the accusations made in the article (which amounts to: monolithism).

Imagine some monolithic framework. Now, a Super Magical Refactoring(tm) takes place and the public interface doesn't barely change at all, everything is the same except that the core is made tiny and almost all the functionnality is implemented as libraries that were extracted from the previous core but obviously fit perfectly well with the core and eachother.

You're telling me the framework is no longer a "framework" but just a "library"?! I think you're playing semantic games.

I say modularity doesn't preclude "verticalisation".

On the contrary, I've found that picking up an application written in Rails by someone else is quite easy. Far from building walls between developers, I think a good framework like Rails encourages communication.

Daniel

This is one of the reasons I'm developing my current application in Rails, rather than just rolling my own framework. I'd probably have more fun building my own system, and there are certainly frustrating bits about Rails, but I like the fact that I can, in fact, work with other people.

Frameworks built by communities of passionate coders are, I think, fundamentally good, because they enable sharing, which is essential to any long-term project.

Absolutely, when project is in progress it's easier for new developers to join the team. Takes less time to understand the system.

I can understand his point, but that only applies to other people's frameworks. There's nothing quite like working in a framework you designed for yourself.

For web development once a site gets beyond the basics I find working without a framework to lead to a confusing and unruly codebase that is often a frustration to work with.

Your framework need not be rails, django, or cake for it to be useful.

Many people don't want the full blank canvas to start with. They like having specific direction as to what parts of the application go where. For then, frameworks work well.

Judging from what people did with Flash and are doing with Flex, I think with many people a blank canvas is an invitation to do really stupid stuff.

So as always it's a people issue and not a technology issue.

Coming next: why some other stuff I don't use is really sucky, and everyone who uses it isn't a Real Programmer.

Obviously, frameworks have some measure of utility, being that so many people use them. Though you give multiple reasons why a person might not use a framework, you neglect the good points that are obviously making people use them.

"Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library."

Please answer this: why DO people use frameworks?

Because it's easier at the beginning. Doing a big application from scratch requires doing stuff like requirements analysis, which means you need to understand the universe of tools available to make good decisions. Then you need to prototype for a while before settling on the final design (i.e. your custom framework).

With rails (or whatever) you get something that works immediately, which feels safer to a lot of folks who don't have the deep toolkit expertise required above. The problem is that while the framework works, you don't actually understand it any better than you do the toolkits, it's just handling stuff for you with (what you understand as) voodoo. So when it comes time to make big design changes in the future, the toolkit folks know exactly where to start, while the framework people are completely lost.

I'm not completely against frameworks, but I've seen so many misused that I'm very wary. A stupidly-applied library is usually a point-source bug that can be fixed in one place. A stupidly-applied framework infects the whole application with its mess.