I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django.
My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.
It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better.
All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.
There are a couple of reasons you want a “quickly spun up” framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you’ll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down.
So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.
Or you don't really know the problem space quit yet and an application that helps you get up and running quickly allows you to figure it out in a short amount of time. Maybe you find out that your preferred tech stack is not adequate, at which time you can change it.
> My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.
You can view the source code of Devise any time you want on its github repo - it's not hiding anywhere.
I think that having authentication code vetted by 100s, if not 1000s of different developers is much better than rolling your own authentication code.
For me it's more nuanced, and I wish I saw more of it.
You make your prototype or fit your product with a rapid dev framework, Rails is pretty much built for that, it doesn't intend to scale beyond it (see Basecamp: they don't pile onto a monolith, they make fresh new versions).
One you get that product fit, your codebase should still be small enough to rebuild it quickly in a more stable language. Java, C#, Go, Rust, whatever... something that gives you better runtime guarantees without requiring bonkers amounts of language hacks so you can spend less time writing unit tests and stubs and mocks.
My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.