Hacker News Reader

Comment by lmm | Hacker News Reader

A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to).

Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.

View on HN

To be fair, Rails now makes it much easier to swap libraries if you need to, compared to how it was at the beginning. I agree that that's something useful, but personally I still think that having a sane reference combination to start from is much better than having to choose everything yourself.

Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.

> I still think that having a sane reference combination to start from is much better than having to choose everything yourself.

That's why I'm such a fan of TurboGears - it's an easy starting point, but as soon as you want to step up to making your own library choices it's trivial to do so. I think the key insight is that no-one ever wants to go back to upgrading all of their different libraries in lockstep; a "platform" of libraries that are versioned together is a good starting point but at a certain point in the project lifecycle you want to unlock from that and after that trying to go back to the platform is only ever going to be pain.

You know that Rails is a collection of libraries that can pretty much all be replaced with the alternative of your choice, right?

Up to a point. In my experience there is limited support for e.g. using "mismatched" versions of different parts of it.

Isn't that the same with any collection of libraries? If you don't use a framework and just pick your libraries, you'll still need to ensure that their versions work fine together.

If you pick a bunch of standalone libraries you can be fairly confident they're not going to interfere with each other - which version of your web templating engine you use has nothing to do with which version of your ORM you use, and you can upgrade each independently. When they're both part of a big overarching framework it's more likely that a subtle interaction has slipped in and not been noticed.

Can you give an example of a collection of libraries that you would consider would compete with Rails?

On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.

Reply on news.ycombinator.com