
Why Frameworks Suck - maxwell
http://term.ie/devdev/why_frameworks_suck
======
Hexstream
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.

~~~
ajross
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.

~~~
Hexstream
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".

------
swombat
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

~~~
asdflkj
<http://ycombinator.com/newsguidelines.html>

------
gnaritas
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.

------
sanswork
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.

------
henning
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.

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

------
kajecounterhack
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?

~~~
ajross
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.

