Sorry, but I've really got no idea what you're saying here. What's the connection between users having many devices and the monolithic architecture bit?
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.
Your first quotation is something you're seriously misreading, I think. It's not about using Ruby for everything. It's about not spending time on minor decisions that don't affect the outcomes you're pursuing. And that's what that quote says – nothing about Ruby; everything about pruning down the pointless decisions you need to make as a developer.
> 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.
Ok but then we are talking about Java, .NET and JavaScript.
They all more or less work on many more devices than Ruby but at some points are so huge and complex and do not perform the same on all of these devices that you still kinda want to pick a specific technology.
Hell Ruby has RubyMotion that allows you to write native apps.
If he really believed that, then the thing todo would be to re-write rails to run on top of node. Then he'd have a runtime that spanned nearly every possible use case and device.
Sticking with Ruby betrays that aesthetics are really the core premise of Rails, rather than aspirations of being the one framework to link all run times and in the darkness bind them.
Why on earth is Node considered the default for concurrency with its shitty single-threaded callback execution model? Anyone switching from Rails for improved concurrency would surely be better advised to choose Elixir?
Was referencing the run-time's viability on devices as small as a Beagle Bone micro controller, a mobile app, up to a backend service, etc.
There's an attractive opportunity for code reuse.
Have a preference for process pools over thread pools so don't mind the execution model. Would not be surprised that some applications are better served by other backends like akka etc. Elixir is on my list to learn.
That does of course play into the position that a great "full stack" framework is a thing of the past.
We use a distributed architecture in clojure and python where I work, but it has its own downsides, and for a lot of people monoliths are a much better solution.
There's a separate argument to be had about single process vs multi process backends, but that gets away from the core premise of Rails. Part of that premise included opinions and defaults about client-side development.
Rails was unique in its time in that it shipped with solid client-side DOM manipulation (prototype.js). It supplied a "full-stack" framework that made it easy to build a dynamic, AJAX Ux.
But lately the "best practices" in the node ecosystem move so fast that any default may soon be outdated. What would today's javascript Ux best practice be? Vue.js? React? Angular? Which state management solution is "best" ? Which CSS framework is "best" ?
Any choice you make will be out of date by the time you ship. There's a ton of activity. It's a decision that belongs on the project, not the framework.