传统MVC
典型的框架例如Rails， 数据层，控制器层，视图层。数据是共享的，所有数据都在一个数据库中，并且在所有controller中可以方便的快速访问，如果想共享数据，还可以将其放置在顶级类中，例如ApplicationController中。
每个controller控制独立的业务逻辑，
加上前端框架以后
组件化带来的复用优势
如果使用Vue.js中的component，复用性将会大幅度提高。HTML、JavaScript和CSS代码存在于同一个文件中，结构清晰，维护方便，复用容易。这样可以直接借用已有的一些组件库，进行快速开发，例如element。
新数据层（前端）带来新的挑战与管理复杂度
其最大的亮点在与组件化提高了js代码和view的清晰度，组织更为合理，更容易复用，但是由于其有自身的数据层，而不再直接使用后端的数据层。
这样就带来一个问题，后端有数据层，这是必须的，前端也出现一个数据层，这样对于一个应用而言，整体上就有2个数据层存在，管理成本就会增加。
成本主要体现在，组件之间的数据传递。在Vue.js中父子组件间的数据双向传递，不同组件间的传递。简单的情况可以使用event bus来实现，复杂的情况可以使用Vuex这个插件来实现，当然Vuex会带来很多的新概念，这也是维护成本和学习成本。
至于具体实现时该使用何种方式传递，就需要权衡了。
视图层可以几乎全部转移到前端浏览器
新架构下，前端和后端通过XHR通信，后端数据库只存储需要持久化的数据。页面渲染、界面交互和部分数据存储功能需要前端来承担。
界面渲染及UI交互逻辑直接通过后端生成并发送至前端，此时UI所需要的数据并没有填充，还需要异步去获取一次，前端逻辑在嵌入填充这些数据。
原来的视图层在后端通过模板语言来处理，就地将模板解释成HTML代码，再嵌入一些数据，发送到前端，前端收到后直接渲染展示。
内置数据绑定带来的便利
传统MVC的方式，可能是用jQuery发送一个xhr请求，然后处理回调，选择要改变的元素，然后再改变元素。
在vue.js中是通过v-model实现这个功能。这是比较大的一个亮点，将组件中的数据直接与view中的展示部分（可以是一个变量，也可以是一个表单input）直接绑定，当数据层变化时，view展示会自动变化更新，当用户在界面上将数据修改后，其变化也会自动传递到内部的数据层。
计算资源消耗分担到前端
原来，模板语言，相当于组件，在后端需要解释一遍，这些解释工作消耗的是后端计算资源，如今，模板解释相当于全由浏览器完成了。
数据交互方式的改变
原来的方式，如果不加特殊处理，可能是页面reload，那就是全量页面的请求，如果数据是局部更新的话，也是全量请求，这里存在的资源浪费和不必要的重加载问题，也会感觉上慢一些。
如果使用了turbolinks的话，则并不会reload，而是turbolinks帮我们在后面发出一个xhr请求，由它来对比返回的数据与当前页面，在发生变化的地方，进行替换。感觉上速度大幅度提升，体验很好。
但turbolinks背后还是全量的请求（请求返回了了整个HTML页面），并不是按需的数据请求，前端框架一般只获取必要的数据，如果是前后端分离的话（例如单页应用），与后端的交互都是数据请求了（xhr），不会有reload。
当然也可以使用jQuery来发送请求实现类似的效果，然后再处理回调，回调中处理界面变化，通知用户等。
路由管理
Vue.js这样的前端框架可以管理路由的切换，后端API依然需要路由，这样的话就需要两套路由管理。原来的结构只需要维护一套后端路由。
鉴权带来的变化
原来的rails，可能是使用cookie来标识一个用户的登录，cookie会在每次请求被自动带到服务器端。在的新的结构下，依然可以使用原来的方式，也可以用新的方式。
首屏加载时间变慢
首屏加载时间相对于纯后端，可能会变慢。有待进一步研究。
搜索引擎难以获取单页应用的内容
如果是单页应用，首页没有很多HTML代码，而是靠JavaScript来加载大部分内容，搜索引擎访问到的首页的时候，只是得到了一堆的JavaScript代码，并没有得到任何页面结构，搜索引擎也不会去解释这些JavaScript，这就导致搜索引擎不能充分得到页面结构及内容。