对于想要使用`webpacker`的 5.2 的 Rails 新项目，仅仅把 packs 作为一种渲染工具，还是把项目逻辑全写在 packs 里变成一个单页应用比较好，利弊各有哪些？

heroyct #1 2018年06月04日

可以看看这个 https://stackoverflow.com/questions/21862054/single-page-application-advantages-and-disadvantages

ad583255925 #2 2018年06月04日

我想听听各位如果现在新建一个项目，要不要做成单页

teddyinfi #3 2018年06月05日

是不是做成单页取决于你业务有没有做成单页的需求

IChou #4 2018年06月05日

关于这个问题嗯，完全不想说话并向你扔出一篇文章：

http://chloerei.com/2018/01/07/front-end-split/

ad583255925 #5 2018年06月05日

对

IChou 回复

https://github.com/reactjs/react-rails#server-side-rendering 前后分离也在向前走，前端代码 (Vue, React) 服务端渲染解决了首屏加载慢，和搜索引擎爬不到你的网站这两个痛点，这两个大问题解决的情况下，是否能使SSR-SPA在webpacker的加持下成为 2018web 开发的终极方案

IChou #6 2018年06月05日

react 没有太多了解，不过我最近在用 vue

说到这个问题，其实首先应该区分一下服务器端渲染 vs 预渲染 (SSR vs Prerendering)，这是两个不同的概念

如果只是预渲染（Prerendering），那其实还是前后端分离的，没有什么可说的

如果是 SSR，那我就会觉得是兜了一个大圈子，最后还是来解决了一个和 turbolinks 类似的问题，也大概可以算是殊途同归了

为什么是『大概算是』呢？因为这两者导致的结果是不一样的，turbolinks 解决了 SPA 的问题，但是它没有去解决前端代码怎么去架构的问题，虽然也有像 tao_rails 这样的框架，但是它也只是在尝试解决问题，它能迎合偏后端的程序员或者全栈程序员的口味，却很难让偏前端的程序员觉得『干，用这个写起来真的好爽~』

编程使我快乐不只是 ruby 的专利

因此，基于『写起来爽』这个初衷来看，你觉得选什么方案合适呢？

IChou #7 2018年06月05日

顺带吐槽一下 vue 这边目前比较火的 ssr 方案 nuxt，我去，这货完全是在开历史的倒车 (/= _ =)/~┴┴

ad583255925 #8 2018年06月05日

对

IChou 回复

我只是单纯的想知道 SPA 和 SSR 的斗争现在到哪个阶段了，搞得现在还真不知道选哪种好

ad583255925 #9 2018年06月05日

就目前看来，webpacker的用处应该还是拿来替代以前拿jQuery撸的部分，或是大网站里面比较小的子系统，网站的主体还是 simple_form + haml + turbolinks + bootstrap

IChou #10 2018年06月05日

个人建议先拥抱再去考虑融汇贯通

lokyoung #11 2018年06月05日

最近做过 webpacker 搭配 vue 的尝试。可以给点简单的建议。先简单比对下后端渲染和前后端分离。

后端渲染 + 前端框架

优点

前后端代码都在同一个项目中，方便调试。部署也只用部署一套代码。
在 Rails controller 中定义的 variables 可以在 template 中直接使用，省去 JSON API 格式的定义。
没有 SEO 和首屏加载的问题

缺点

开启了 turbolinks 的情况，需要在 turbolinks 相应的 callback 中销毁和重新注册相关组件。但是如果你使用了基于 Vue/React 这些前端框架的第三方 UI 库，某些第三方组件在 turbolinks 开启的情况下会出现一些意想不到的的问题。
表单操作方面，Vue/React 不能直接在 Rails 原生的表单中使用。如果还是使用 ujs 的方式去处理表单，遇到需要 Vue/React 去处理某些数据绑定的操作，也还是不方便。如果使用 Vue/React 去构建 Form，提交表单只能发起异步请求，不会有 Rails 原生表单的行为，一些本来交给 Rails 处理的行为（例如在 controller 中 redirect）需要交给前端处理。而且这样的行为在一个非前后端分离的项目中可能会显得比较怪异。例：如果使用了 Vue 去提交一个表单，想在提交成功之后做 redirect。由于是一个异步请求，Rails 并不能帮助我们进行 redirect，只能在前端使用window.location这样类似的方式进行 redirect。这个行为既不 Rails 也不 SPA。（SPA 中通常使用 Router 进行跳转）
前后端数据命名格式不一致。在 js 中，命名的规范是camelCase，在 Rails 中是下划线的形式。如果你有过 SPA 的开发经验，在写前端逻辑时应该会倾向于camelCase，所以我们还是需要对 Rails 的数据做一道转换。

前后端分离

优点

完全使用前端的解决方案，后端只提供 API，具体操作如何、路由怎么跳转完全由前端控制。
如果使用第三方 UI 库，不用担心一些由于后端渲染和 turbolinks 导致的问题。

缺点

SEO。但是这个问题我们需要根据自己的场景去看待。如果做的是一个内容展示型的网站，SEO 十分重要，这时用单页应用就必须通过 SSR 这样的方式去做处理。但是如果我们做的是一个管理系统（CRM/OA 等），大多数的界面都是在用户登录之后才能访问的，也就是说大多数界面我们并不需要 SEO。这时候我们可以将一些公开的界面（如产品介绍页面）做成后端渲染的，登录之后的做成单页应用。SEO 也不再是问题。
首屏加载。首屏加载是每一个 SPA 都需要面对的问题。也是 SPA 被诟病的众多原因之一。但是现在的主流前端框架在 build production 之前都会做 uglify 之类的操作减少 js 文件大小，除此之外使用 Lazy Loading、server 上开始 gzip 之后最后得到的资源文件大小并不大。
Rails 只是一个 API，我们不能使用 Rails 的很多便利的东西（Helper，Form 等）

结论

可能你看到这里会觉得我更加倾向于 SPA。但事实上我所提到的在使用后端渲染 + 前端框架的这些缺点，都是因为在开始项目之前我不希望使用 SPA，所以还是想像使用 jQuery 一样使用 Vue，所以还是采用了后端渲染的方式之后发现的。我在项目中为了能快速搭建 UI，使用了一个 Vue 的第三方组件库，开始时并没有觉得有什么问题，但是随着项目深入之后便发现了我之前提到的这些问题。为了解决这些问题反而花了更多的时间。

但是这并不代表 SPA 就一定是更好的选择。技术选型不能脱离我们的业务和环境。关于究竟是 SPA 还是后端渲染，我想给出我自己的一些建议：

如果你有很多重前端的场景，一些业务场景重度依赖于 React/Vue，或者说你使用了一些基于 React/Vue 的 UI 库。为了减少你处理一些不必要的麻烦的时间，建议直接上 SPA。
如果你仅仅是用 React/Vue 处理某些交互麻烦的地方，如果 React/Vue 对当前项目来说只是 jQuery 般的存在，后端渲染会是更好的选择。
最最重要的是，选择适合当前团队的方案。如果你现在的团队成员有过 SPA 的经验，并且更适应 SPA 的开发方式，那么前后端分离无论是对于开发效率还是质量来说可能都是更好的方式。反之，如果你的团队更熟悉传统的后端渲染的方式，为什么就一定要为了前后端分离而分离呢？前后端分离只是一种不同的开发方式，前后端分离可以实现的业务使用后端渲染一样可以实现。

关于前后端分离的问题，社区里曾有过不少讨论。其实无论是前后端分离还是后端渲染，我们的目的都是为了解决问题，二者没有孰好孰坏之分。你不必因为现在很多项目都选择了前后端分离就一定要去跟这个潮流，放弃后端渲染。同时，也不必像我一样，在场景过于依赖前端框架的时候硬要上后端渲染（这里也有我个人的原因，最近一年的工作很多是和前端相关，对一些单页应用中的业务场景更加熟悉一些）。找到最适合自己和团队的方式，高效高质量地进行开发才是我们的最终目的。

2 个赞

ad583255925 #12 2018年06月06日

我突然想明白了为什么会在 ssr 和 spa 纠结了半天，因为 simple_form,haml, turbolinks 这些个 rails 组件太好用了啊，如果是其他语言的框架，根本就不用纠结，全上 spa 了