Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you.
Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries.
The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database.
Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.
>things. That's the kind of thing that should contain
>absolutely zero magic, the logic should be upfront and visible
No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?
Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?
Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.
This attitude is really pervasive in web development, and I think it's kind of bizarre. If you're building something as a developer, you need to understand what it's doing, because at some point something will break and you will have to debug it.
When you get to the point you have to debug it, are you going to want to figure out some sort of insane meta-object protocol where you can't figure out where or why a method is dispatched, at what point inputs get santized, etc., or do you want to walk down a simple function chain?
Keep in mind I'm not advocating rolling everything yourself, I'm saying if you use a library it shouldn't be treated as a black box. I'm advocating avoiding abstractions that obscure your ability to understand what's happening (what I call magic). Use a library for user authentication, for sure, but if you can't explain how it works well enough that you could replace it, you shouldn't use it.
"Magic" is good for beginners, because there's just too much they don't know.
Not thinking about all these things because the community of thousands should have done it better I did, is just lazy.
This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.
Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems?
As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.
It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy".
https://www.infoq.com/presentations/Simple-Made-Easy
If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software.
Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.
I was referring to absolute beginners with little prior background. To them, technical documentation is a bunch of gobbly gook. For these people it's usually better to be somewhat opinionated and just tell them "there are other ways, but this is the tried and tested way and it works". A nice side effect is that they don't suffer analysis paralysis and panic attacks.
They don't know what they don't know, so it's sometimes useful to just tell them "this is the syntax to do X" (aka "magic") and gloss over the finer details. I've found that the time to unveil the magic is when they poke around under the hood, read up, and start asking questions about how things work.
I think the mention in the article of the User.Create(params[:name]) one liner is really instructive. Creating a user is one of the most important things you're going to do in an application! The business logic rules are incredibly important, the security implications are huge, everything. Trying to make it "easy" is ridiculous, because as a developer, you should be thinking about these things. That's the kind of thing that should contain absolutely zero magic, the logic should be upfront and visible.
I've worked as a web dev, and I've also worked outside of web development, and the number one thing that drove me insane doing web development was never knowing if any one line of code was doing some severe amount of impossible-to-debug magic. I'd rather just write javascript against the browser APIs with a lightweight http server.
As far as I can tell, the vast majority of frameworks aren't really about providing functionality, they're thought experiments in how to write software. That's fine, but they should bill it as such. I'm not going to say web development is easy, there are parts that are legitimately difficult on their own accord, but I think the web development community has made things massively harder on themselves by pretending all these abstractions are actually simplifying the task they've set out to do.