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.

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.

> starting from scratch or from a minimal base is massively slower

This isn't the better alternative to frameworks.

The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch".

The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work.

Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.

> you tell the libraries how to work together

Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?

With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here.

If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).

Less than you'd think.

The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.

> > starting from scratch or from a minimal base is massively slower > This isn't the better alternative to frameworks.

I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.

I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.

It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team.

I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)

"more error prone and less safe"

right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.

CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default.

XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway.

This was a big reason to use frameworks in past days, though.

Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend.

In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.

> when creating web applications, starting from scratch or from a minimal base is massively slower

Because every web app is the same CRUD app, right?

Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.