Rails was part of the old paradigm where a webapp runs on the server and sends HTML pages to the client.
The new paradigm, which I would not call single page architecture for historical reasons, sends the app to the client in when they open a page, and then runs on the client and only calls back to the server to get/post data. And maybe load some additional code blocks. These apps are built in Javascript with underscore, backbone, angular, ember and related tools. They are also typically MVVM or MV(something other than C).
His argument is that the "new paradigm" is constantly changing and reinventing itself (usually with old concepts). Meaning in ~2 years, there is going to be a "better" way to do things. I'm not sure I agree with him, but that's his argument for not switching to a front-end MV* framework.
Rails is modular. It is possible, and a frequent use case to utilize portions to persist data, perform business logic for requests from code running in the web browser.
Rails was part of the old paradigm where a webapp runs on the server and sends HTML pages to the client.
The new paradigm, which I would not call single page architecture for historical reasons, sends the app to the client in when they open a page, and then runs on the client and only calls back to the server to get/post data. And maybe load some additional code blocks. These apps are built in Javascript with underscore, backbone, angular, ember and related tools. They are also typically MVVM or MV(something other than C).