关于先后端同构，个人一点思路和心得（vue、nodejs、react、模版）

最近1年多，先后端同构慢慢变成一个流行词，也许不少人还停留在先后端分离的最佳实践道路上，但实际上又有一批人已经从简单的服务端渲染走向探索最佳先后端同构方案的路上了。不过，我只是膜拜后者的过客。

 

虽然你们能够去网络搜索一下相关的概念解释，但这里我仍是简单列举一下，我理解的术语。

一、前端渲染：浏览器一侧使用js，借助模版或vue、react、angular等框架作的DOM结构生成。

二、后端渲染：服务器一侧，使用php、nodejs等技术实现DOM结构生成，并在HTTP请求中返回给浏览器。

三、同构：浏览器一侧的JS、HTML和服务器一侧使用的JS、HTML使用一样的开发结构，一样的开发思路，一样的开发模式，尽量实现代码复用。

 

明确一点，做为有追求的前端开发，咱们不该该盲目跟风，一切须要从实际出发。

 

那么，首先，咱们须要了解为何会有同构这个概念出现。

• Web开发的历程是颇有趣的，最初php、asp的年代，一切内容都是服务器渲染的；
• 再后来为了节省服务器资源，也更大限度利用客户端缓存，又出现了先后端分离的模式，从而有了专业的前端开发和后台开发。此时Web的特色是，js和html放到静态目录，也能够CDN扩散，并以ajax方式获取后台的数据，在前端进行DOM组装。这种开发方式沿用至今，这是一个好的工做模式，专业的人作专业的事，确实有利于工做效率提升。
• 再而，随着nodejs的流行，前端jser们又开始蠢蠢欲动，尝试吞并web接入这个后台的前沿地盘，把后台推到更后。大概2014年后，又出现了不少nodejs直出的方案，把页面数据都一次在HTML的请求中返回，无需浏览器端再发起ajax获取数据，并且服务器端把DOM结构都渲染好，浏览器按trunk直接作图形渲染便可。不得不说，这个方案带来了不少好处：首屏速度更快，浏览器更省电。固然，随之而来的，就是更复杂的工做模式，jser须要作服务器端的逻辑，甚至一些代码须要同时用在浏览器和nodejs上。
• 针对前边的问题，同构的探讨就开始了。。。

 

百度搜一下先后端同构，清一色的vue、react。这些确实是同构，但我认为范围太窄，同构不是框架带来的问题，而是由于先后端独立渲染这种架构层面带来的问题。

固然，那些同构探讨也是很是有价值的，但不在本文的讨论范围内，在这里我更想表达一下，如何从实际项目需求的角度来看，找出本身所需的同构之道。

毕竟，要知道，同构不是为了跟风耍酷，也不是为了跳槽面试的时候博点好感。同构，是为了提升用户体验的同时，提升团队的工做效率。

 

接下来，我想根据项目的类型，说说本身的见解。

 

第一种，单页面应用。

这个网站很相似一个APP，确实颇有必要作成单页应用，有助于提升用户体验。

若是第一步选择了单页面应用，这里就衍生了另外的问题——SEO。而react等框架作了服务器渲染，最大目的其实也是解决SEO。

既然浏览器端选择了某个框架，例如React，而同时又考虑nodejs直出提升首屏的速度，那么就没有讨价还价的余地了，固然上react全家桶，先后端都用react。

这一种状况，也就是网上搜索到的各类文章的状况。

 

第二种，多页面纯数据展现，每一页都比较简单，没有分屏的必要。

若是项目是这样的状况，使用nodejs直出，无非就是提升打开速度。而先后端基本八竿子打不着，最多就是一些工具函数（转换一下日期格式，输入框校验）要作复用。

此时，不必大费周折去考虑什么框架，因地制宜，想一想本身须要什么便可。

要解决函数库的先后端复用，能够简单作commonjs/window的兼容。

若是浏览器端的代码比较多，就能够考虑粒度化，使用webpack作浏览器端代码打包，同时commonjs的写法也能够复用到nodejs层。

 

第三种，多页面并且每一页不是那么简单，首屏和次屏有一些HTML片断（模版）须要复用

以前我所在项目组也遇到这样的状况，怎么处理，一时之间为了赶进度也没太多考虑，使用了一些旁门左道，很差理解很差维护的方式，基于art-template作了一套有点奇怪的代码，基本没有同构一说。惟一同构的就是art-template支持浏览器和nodejs。

状况怎么恶心呢？大概是这样：

• html模版，为了复用，拆开为多个小文件，若是先后端都用到，则一方面把这个模版内容不转义不编译地塞到最终HTML中，而另外一方面利用这个模版作nodejs渲染。前端ajax加载数据后渲染次屏时，再读取HTML中某个模版作处理。
• 对于处理数据的js，可封装部分，则利用跟刚才第二种状况相似的方式，作了commonjs/window的方式；很差封装的部分，基本等于写了两份。
• 前端的js，动态塞到http返回中输出的HTML中，可能有若干个js。

回头想一想，当时状况确实很糟，其实能够利用已有的工具作得更优。

art-template是个好东西，这个不必去除。刚说的前两点，代表这个项目有强烈的先后端代码复用的必要，颇有须要使用更全面的同构方案。

如今我以为有更好的方式：

• 用webpack作前端打包，这样前端各类代码和后台代码都是commonjs风格，能够二合一。并且发布前打包为一个大js文件，也省去nodejs每次请求动态合并js的消耗。
• html模版发布前先作预编译，从html+模版语法，转为纯js代码，随着webpack打包到浏览器端大js文件中。
• 后端和前端都用到的代码，基于commonjs，尽量的抽离封装。
• 最终合并的浏览器端大js仍是动态合并到首屏HTML中。

引入了webpack到浏览器端，就能很好的解决了原先html模版传播的尴尬。而模块风格的统一，也有利于先后端代码更好的复用。

至于最终浏览器js是否打包到首屏HTML中，仍是单独的部署CDN，这个其实就不是同构的问题了。不过对于移动端而言，仍是建议合并在一块儿。

 

抽象一下，对于第三种项目状况，跳出我原先的项目。我认为，关键是要把先后端使用的模版统一为一个方式引入。

 

第四种，仍是多页面，浏览器端没有模版拼装的需求，第三种状况的变种。

或者说，这个不是一个单独的项目状况，只是由于用的技术方案不一样。跟第三种状况同样，但次屏的渲染，咱们不在浏览器端执行，而是继续交给nodejs。浏览器端经过ajax把次屏html片断拉取回来，而后直接塞到body中。并且，除此以外，浏览器端没有用户交互会致使已有的DOM发生重绘，或者极少内容重绘，不须要动用到模版。

在这个状况下，浏览器端js更纯粹的只关注事件处理。

我以为这个又回到了第二种状况，只须要简单把一些库函数封装一下，作成先后端共用便可。

第四种状况，由于完全抛弃了浏览器渲染，整个状况就简单多了，不须要考虑模版和不少逻辑js的先后端复用问题。