I think for what it is - for its paradigm if you will - ruby on rails is an extremely well-designed platform. But I think things have moved on and what was back then seen as the right way (or just fresh new way) is now seen differently.
For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming).
Or is the article's example of a data model migration really better than a series of alter table sql statements? (Putting OO on top of a relation database using an ORM.)
And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?
My point is rather if you are doing that (a hybrid app) wouldn’t doing a full spa actually be simpler? And allow you to use a less complex framework / a framework which doesn’t have to support that legacy.
You're going to need to define a "full SPA". Every SPA needs a backend, and Rails is as good as any. In fact, Rails + Vue is, by any definition, a "full SPA" as Vue is a SPA front-end framework and SPA only refers to the front-end design. You can launch Rails in API-only mode so there is no "legacy" anything, just a backend framework that has all the benefits of Rails while still giving you the SPA front-end you're looking for.
I wouldn't even call it a hybrid, nor would I say it's any more complex than anything else. Every SPA needs a backend, and Rails is as good as any.
By full spa i meant something where all ui is rendered on the client side and the server only serves static files and a set of web services for whatever business logic that has to run on the server.
> And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?
Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.
The company I'm at right now uses a SPA for both static and interactive things. On the static side, it's comedically slow and complex for what should be an HTML file with resources. On the interactive side, the load time is abysmal (and that's on a corporate network), and it does work well once you try to open a new tab. On the other hand, it makes for cleaner code.
And PS: Everything is relevant today if you are stuck with it. The question is if you would start a new project on it if you didn't already had a lot invested in it?
I am going to do exactly that. Why? Because of all alternatives I personally could use: PHP/Symfony, RoR or Node.js Ruby is the most elegant and pleasant language and Rails is best framework. Other my think differently, of course.
For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming).
Or is the article's example of a data model migration really better than a series of alter table sql statements? (Putting OO on top of a relation database using an ORM.)
And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?