| There was a moment in web development where a single "full-stack framework" was possible, that moment has passed, and that moment was more rare and unique than it seemed at the time. The future seems to be more about lambda functions[1], api gateways, and many native clients. Quoting DHH, the Rails pitch was use Ruby for everything: > The core premise of Rails remains in many ways as controversial today as it was when it premiered. That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity. That premise is irrelevant today. A complete application today isn't just a website. It's a website, a phone app, a car app, a TV, a kiosk, a conversational bot, etc. Choosing even the highest common denominator across all those platforms means eliminating unique opportunities to delight the user. If now the premise of Rails is that it's a great way to generate JSON on the server, sure but that's a fraction of the stack. The selling point for Rails is now simply an aesthetic choice between Javascript and Ruby. DHH admits as much with his closing argument: > Just look at some code. I dare you not to fall in love. Since the core premise of Rails remains full-stack, plugins at best are a cycle behind innovation. Conventions have to be explored elsewhere before they can be formalized, and before choices can be exposed as valueless. At worse, plugins are multiple cycles behind innovation due to pointless infighting. This just seems way too slow, I'd rather get my hands dirty today. [1] or process containers, let's not get bogged down in vendor details. |
> A complete application today isn't just a website. It's a website, a phone app, a car app, a TV, a kiosk, a conversational bot, etc.
I disagree pretty strongly with that. A complete application can be any one of those things. Sure, if you have a need for all of those at once, then Rails isn't going to be your one and only tool. But it could still well be the tool for your complete web application, and at the same time your API server for (some/all) of the other tools.
> DHH admits as much with his closing argument
No, he says that Ruby's beauty is an additional reason to use it. It's hardly an admission that it's all that differentiates Rails from other options.