4 ms·

Why Frameworks Suck

17 points by maxwell 19y ago

gnaritas 19y ago
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 19y ago
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.
swombat 19y ago
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
- es 19y ago
  Absolutely, when project is in progress it's easier for new developers to join the team. Takes less time to understand the system.
- donw 19y ago
  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.
- asdflkj 19y ago
  http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
Hexstream 19y ago
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 19y ago
  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.
  - jamesbritt 19y ago
    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.
  - Hexstream 19y ago
    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".
kajecounterhack 19y ago
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 19y ago
  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.
henning 19y ago
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 19y ago
Coming next: why some other stuff I don't use is really sucky, and everyone who uses it isn't a Real Programmer.

17 points by maxwell 19y ago

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 19y ago

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.

swombat 19y ago

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

es 19y ago
Absolutely, when project is in progress it's easier for new developers to join the team. Takes less time to understand the system.
donw 19y ago
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.
asdflkj 19y ago
http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html

Hexstream 19y ago

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 19y ago
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.
- jamesbritt 19y ago
  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.
- Hexstream 19y ago
  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".

kajecounterhack 19y ago

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 19y ago
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.

henning 19y ago

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 19y ago

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