Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity.
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.
There was a good book out recently from pragmatic bookshelf called "rails angular postgres and bootstrap". Not saying you should necessarily use this stack (I don't), but the idea that you don't need to do everything in rails to use rails is worth listening to.
Generally, you're going to want to go back in time, to use tools that were designed for even older problems. For instance, why reinvent sql in a new language? If it's convenient to use active record and there's no performance hit, ok, use it, but don't go into contortions to avoid sql.
On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven't withstood the test of time, by all means, go for it. But you aren't obligated to write the other 95% of the project in some new framework.
But yeah if you use them judiciously they can remove some drudgery.
Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code.
Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article.
So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT().
I worked with it, but TBH going back to raw SQL in this case would've been much easier.
Pragmatism, the lost art (TM)
ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated.
The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)
There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity.
Overall if you use an form properly I think it can save time and improve clarity.
The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.
But no, fixing stuff is hard. Let's write bitchy blog posts and blame everyone else.
As you say, the actual article is about how Rails has all of yesterday's flaws, which is pretty much the opposite of "reliable and boring".
After 30+ years of coding, my first encounter with Rails, a summer morning I received a ripped draft of a very early book on it remains one of the seminal moments of my career - so many elegant solutions to so many issues I'd grappled with since the mid-90s
As with any tool it's got some quirks and areas I could criticise - but it's got a place in my toolkit and will have for some time
As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...
1. extensive speaker notes included as an addendum
2. all of the content on the slides (which usually makes for a bad presentation)
But srsly, thank you, that's very kind to say.