Link Details

I like the little RoR debunking but hesitate to vote this up. The purpose of a framework IS tight coupling.

I disagree - tight coupling is never a benefit. The purpose of a framework is high _cohesion_. The reason I linked to the Wikipedia entries for coupling and cohesion is that people tend to confuse these.

Tight coupling means that the components expose wide interface towards each other and/or depend on internal details. That is always a disadvantage, as it makes it harder to replace components with other components, even when the other components provide all the needed functionality, as any replacement also need to adhere to a wide set of interfaces or copy the internal architectural choices of the component it replaces.

The problem I have with frameworks is exactly that there are very few frameworks that doesn't achieve high cohesion by sacrificing low coupling. So also with Rails. It's a matter of discussion what the relative importance of high cohesion vs. low coupling is.

My problem with Rails (and most other frameworks) is that for web development I don't see _any_ value in sacrificing low coupling for a typical web app, because there's nothing in the typical model that requires high coupling to achieve high cohesion, meaning you can achieve practically all the benefits without the downside of locking yourself in to a specific set of components.

The purpose of a framework is, well, to provide a 'frame' for a whole (business-, application-) domain. The framework user is supposed to fill his specific implementation into the pre-defined framework 'slots'. Frameworks usually give the user a uniform, coherent, and monolithic view of the domain. This is not a bad thing but simplifies framework usage. Your question is 'framework' versus 'loosely coupled components'. Redefining the meaning of 'framework' doesn't help.

He's arguing that he doesn't need a framework at all. That's not really a Rails issue. Some people would rather have loosely coupled components, and have more control over how they interact. Rack is excellent for that.

For those who do want "cohesion," Rails has it in spades. It does use tight coupling to achieve that cohesion, but if you are happy with AR and ERB, then it is an excellent framework. I've been very happy with it for many web applications. However, there are probably a few things for which I'd consider Rack--I think there's plenty of room for both.

I'm arguing that a framework that sacrifices loose coupling to achieve high cohesion is bad when it's not necessary to sacrifice loose coupling. In the case of web applications it isn't. Sufficient cohesion can be easily achieved with next to no coupling.

I liked the article but disagree to some extent about the coupling being necessarily bad. A closer tie in with the Model layer allows the framework designers and or users to skip the step of creating intermediary constructs that wrap model objects to objects digestible by the Cotroller/View layer. This tighter coupling is certainly not always a good thing, but for many web apps it is the shortest route.

The real question is does Rails or any framework prevent or make it prohibitively hard to use an alternative component when you need it.

I don't have an answer to that. I know it was easy to use HAML instead of ERB, but how hard would it be to use another ORM? I suspect difficult.

I think it bad when people don't understand that tight coupling is going on upfront and then get into a situation where they didn't understand that would hamper their development efforts but, as always, caveat emptor.

I think though that there are more frameworks emerging that take many of the concerns in this article to heart (MERB looks like one from my playing around). It could be in a few years time we'll look at Rails like we (at least I) look at Struts. I think back and say god how did I ever use that? When all I have to do is think back a little farther and remember what I used before it. Rails was a breath of fresh air when it arrived, and I think is quite productive, but that doesn't mean it will be the best thing for ever. Others will take the lessons from Rails, and build something new that works better, making their own mistakes that will later be fixed in a new solution and so on.

On the flip side of the argument, I believe one should be very wary of the approach that was implied out in the article. It seems to suggest that many of the components of Rails could be easily written from scratch, and therefore should be written from scratch. There is alot of folly in that approach. The first being that you're probably reinventing the wheel, which is a waste of time, even if your wheel is slightly more elegant. The second being that if you ever have to hand off your code, now your successor needs to learn not only business logic, but custom plumbing, and thats a huge waste of resources. One huge benefit of a framework is that you deal with plumbing as little as possible.

planetmdc, it depends on perspective. Coupling is always bad in the sense that it limits your choices and makes replacing a component harder. BUT, when increasing the coupling is needed for increasing cohesion it can be worthwhile - in that sense it may not always be bad for the system as a whole.

Part of my argument, which I probably didn't succeed in making as clear as I'd like, is that you don't need a lot of coupling to achieve high cohesion for a web app because of the nature of the components involved.

I agree that Merb looks promising, though I'm - as you can see - quite skeptical to framework in general, because in my experience the moment you call it a framework it tends to be as an excuse for increasing coupling where you rarely have to.

I don't think Rails is bad. Compared to many of the alternatives it's fantastic. There's no doubt it's a step forward for a huge percentage of web developers out there. But there are a lot of alternatives.

I am not arguing for rewriting components of Rails from scratch - I'm arguing you're better off picking independent components. For my own use I'm writing a few tiny little components because it's easier than trying to reuse components that weren't meant to be reused. As I mentioned, things like a flexible router/dispatcher with no external dependencies can be done in 30-40 lines of code, and then save you the significant dependency cost of reusing something from a framework. It's a one time cost. Sometimes it's worth it to rewrite, sometimes not.

It's great they've kept ActiveRecord loosely coupled to Rails so it can be reused and not rewritten though I prefer Sequel, it's a matter of taste not a quality issue. But because I prefer Sequel it's also a great pity that Rails is relatively tightly coupled to ActiveRecord - I can't for my bare life see why, as there's just no good reason in my mind to entangle the two.

As for learning custom plumbing, _Rails_ is custom plumbing for most web developers. It's a tiny fraction of the market still. And it's huge, complex plumbing. High coupling also means there are a ton of pitfalls, because the number of interfaces - explicit or implicit - are huge. I often shake my head over Joel Spolsky, but this is one area where I agree with him: All abstractions are leaky to some extent. A good developer need to understand the underlying plumbing, or those leaky abstractions will come back to haunt you. I'd rather then be able to dig into small, self-contained, easy to understand components than dig into a framework where most things are mashed together.

As I believe I wrote elsewhere: If a framework is loosely coupled, then I don't have a problem with it. But when people call something a framework, it's usually because things have gotten entangled and coupled tighter than they ought to. _Sometimes_ it's worthwhile, but I've yet to see a single good excuse for tightly coupling any parts of a web development framework together.

I'd love to hear people pipe in with specific examples of where they believe tight coupling is needed to achieve high cohesion in a web framework, and we can try deconstructing it.

I think we're largely in agreement. I think where I differ is that I don't view a framework making decisions on internals as a bad thing. The caveat is that I need to be aware of that (and that is my job not the frameworks).

As a developer in a certain segment, I want to be able to focus on business logic and not request routing and don't care that the Rails routing code is not interchangeable (as an hypothetical example, I've no idea if it is or isn't, as I work in a sector that does not have high bandwith). If I need to know something about it, there is documentation I can look at. Even more importantly, a successor can look at it. Now it may be that someone needs to build an application with massive throughput and Rails hypothetical 'noninterchangeable' routing won't work. The developer/s of this application really ought to do investigation up front and make a better decision on the framework (or custom solution).

There is certainly alot in Rails and many do not need all of it, but the part that you don't need, may be the part that I need and the part that neither of us needs is what another colleague needs. The success of a framework is measured by how well it accommodates the most need with the least amount of overhead. At some point things need to be coupled. The question is where/how loosely and the trade off in modularity vs. feature integration.

I take your point where its easy to make it modular, do so. But sometimes modularity can be complex, and in that case, make a decision that will accommodate 80 percent of the cases and build off a solid foundation.

Rails, or any established web framework, is plumbing for web applications, but it is not really custom plumbing. It's a standards based approach to the inner plumbing of web applications. You can argue whether its good/bad/efficient/elegant plumbing, but it is a standard that others can build from and learn about independent of your business domain. Building something like your own request processing module is custom plumbing. That is not to say a custom job may not be needed, but it is silly to do it, when its not.

Choice in components may be very useful, but it can be very limiting as well, depending on circumstances. Try picking a CMS (which is a framework of sorts). It's hard because there are so many, and you can't possibly try them all. There are even sites devoted to just helping you weed the choices down. Limiting the choice allows people to focus on other things. It's not right for all situations, but that needs to be understood. While I have sympathy for people who choose a web application framework that ends up not being what they needed, it's the kind of sympathy I have for people who buy a minivan and then try to drive off-road and get stuck in the mud. I feel bad for them, but what were they thinking? Minivans do lots of things well, but donuts in fields is not one of them.

To be fair I think that there is much in Rails that could be made less tightly coupled as the framework matures. Whether that'll happen or not is not for me to make guesses about, but if it did it would be a good thing. It certainly wouldn't be impossible to do, and even if most people stick to the default components, less coupling also would make it easier to evolve the framework.

It's not that Rails in itself is bad - it has certainly done a lot to raise the profile of Ruby and that's great, and it's done a lot to make web development of certain types of web apps easier and that's great. Rails is much less of a problem than the many newbie developers that thinks Rails is the only solution and don't take the time to verify if it's suitable for them. If/when someone choose Rails after carefully evaluating it, or because they know Rails well and know it'll fit their needs, then fine.

The tighter coupling, though, the more important that upfront choice is, because the cost of changing framework later on is far higher than changing smaller components in a loosely coupled system.

I take your point regarding choice, but your choices becomes less important when coupling is lower, because you can much easier replace just the problematic bits. If I start with a framework and a year down the line need to rewrite all my logic for another framework that is a lot more painful than if I "just" have to replace the ORM or the router or the template system used for the views. The more fine grained the component choices are (even if they are packaged up as a loosely coupled framework), the "cheaper" it becomes to make wrong choices.

It's a great discussion, and I have ideas for entries exploring these ideas further. Thanks for the feedback.