The problem with Frameworks
Over years, I've developed a dislike for frameworks, especially ORMs and web stacks such as Rails. But aside from complaining about "magic" and a vague icky feeling, I could never eloquently explain why. Meanwhile, all my spare time web projects have been done with Express and, man, I haven't had more fun in years, again not being able to eloquently explain why.
So when it came time to pick a stack for a scala web app, I was staring at a sea of options. Play seemed to be the obvious choice, being part of the TypeSafe stack, but looking at their documentation I got that icky feeling again. I searched for some vs. posts to hear what people like/dislike about the many options available. And that's where I came across a paragraph that was the best explanation of why I stay clear of frameworks when i can:
"[…] frameworks are fine, but it is incumbent upon you to have an intimate understanding of how such frameworks abstract over this infrastructure, as well as the infrastructure itself. Some will disagree with that, arguing that the very reason you want these abstractions is so you don't need this understanding. If you buy that then I wish you luck; you'll surely need it should you decide to develop a non-trivial application."
Frameworks mean you have to know more, not less, about what you are doing
It all comes down to the fallacy that an abstraction alleviates the need to understand what it abstracts. Sure, for the scenarios where what you are trying to do maps 100% to the target scenarios of the framework and you have no bugs, frameworks can really cut down on that boiler plate. This is why scaffolding examples of most frameworks are so magically concise. They excercise exactly what the framework was built to be best at. But the moment you step out of their wheelhouse or need to troubleshoot something (even if the bug is in your own code), you'll have to not only know how the abstracted system should work but also how the abstraction works, giving you two domains to master rather than just one.
The ORM example
I used to be huge proponent of ORMs. I even wrote two and a half of them. My original love for them stemmed from believing that I could curb bad SQL getting into production by providing an abstraction. I was violently disabused of that notion and have since come to accept that badly written code isn't a structural, but rather a cultural problem of developers either not understanding what is bad or not caring because they are insulated from the pain their code causes.
But I was still convinced that ORMs were an inherent win. I went on to evangelize NHibernate, Linq-2-SQL, LLBLGen Pro. Entity Framework never got a chance, since I was already burned out by the time it stopped sucking.
Over time it became obvious ORMs were not saving me time or preventing mistakes. Quite the opposite, setup was increasingly more complex, as you had to design schemas AND write mapping code to get them to work right. Usage went the same way: I knew what SQL I wanted to execute and now had a new dance to tweaking the ORM queries to do what I wanted. I was an abstraction whisperer. And that's not even the hours wasted with bugs. Debugging through the veil of abstraction usually ended up showing not an error in business logic or data structure but simply in usage or configuration of the ORM.
I had resisted it for several years, but finally had to admit that Ted Neward was right: ORM's are the Vietnam of Computer Science.
But… DRY, damnit!
One of the attractions of frameworks is that they drastically cut down on repetitive boilerplate code. I admit that using component libraries, you will likely do more manual wiring in your initial setup than with a framework, but this is generally a one-time setup per project. In my experience that one time cost of explicit wire-up pales in comparison to the benefits of having explicit configuration that you can trace down when problems do occur. So my stance is that wire-up isn't repeated boilerplate but rather explicit specificatgion and so does not violate the spirit of DRY.
For the most part I favor components that simplify working in an infrastructure's domain language over frameworks that try to hide that domain and expose it as a different one. Sooner or later you will have to understand what's happening under the hood and when that time comes, having a collection helpers for working with the native paradigm beats trying to diagnose the interactions of two (or more) domains.
@6pm
Andy says...
I think this post may have something to do with the convo we had at work that day 😉 Sinatra has historically been my favorite go-to web framework, as I am a fan of the ruby language but love the simple pattern of "hook this uri route and execute this function". You can't pay me to touch Rails, or its developer community, and especially its activerecord implementation (though I'm ok with the generally idea of mapping db rows to objects).
@7pm
Larri says...
“And having a user, using a web iftcrnaee, update 10 million rows is also probably not in anyones list of best practices.”Then I guess Google should go out of business. They let you search (not update) billions of pages in a few seconds.Try that with your favorite ORM tool.I’m of the opinion that:1. It costs more2. It confuses people3. That’s considered a good thing by people who want to make money4. When performance REALLY matters, the orm is quickly discardedI think for ages developers have answered the question “where shall I put my code obfuscation?” with “in the data access layer.” You can’t obfuscate the front end easily without messing up the event flow of the application. The database is readily understood by anyone who understands sql, and its level of normalization is easily determined and unnecessary complexity is easy to identify. The DAL sits in the middle–and since it often goes unread, it’s a great place to obfuscate.These efforts at obfuscation eventually grew into a ORM tools that are so WELL obfuscated it appears they actually serve a useful purpose.The poor processer disagrees. It knows it’s doing unnecessary work for no reason at all.