前后端分离一直是web工程师讨论的热点，这几天看了不少论坛和文章，思考整理一下形成了自己的理解，初步记录在此，以便日后反思进步。
目前认为前后端分离是一种软件工程开发思想，是一种web开发的经验方法，可以说是接近行业principle的程度，但不是truth。前后端分离不是任何web项目都适用的，比如Facebook在开发中就不分前后端。前后端分离是工程学方法，自然就有适应的项目体系，是因时而化的。Facebook之所以不太在意前后端分离，是因为他们的开发体系是product+infrastructure。product通常是全栈，而infrastructure通常是某一领域的专家，精通开发中的一部分工作，于是后者负责给前者有力的技术支持，提供实现技术细节的api供其调用，product就拿着这些api构建项目，完成开发工作。所以，在一个团队拥有足够的full stackers和specialists的情况下，前后端分离就没有那么重要了，毕竟不再是分层开发而是由全栈负责整个项目，局部技术由技术专家提供*。当然，这需要良好的企业文化和积淀，要有丰富的内部api可供调用，开发效率才卓越，而且全栈不可能洋洋精通，最终的成品可能存在某些专业高度不够，正如Facebook的前端界面交互就令人不太适应，不够人性化（也许这就是没有专门前端工程师的弊端）。
术业有专攻，排开对接上的大量成本，前后端分离能使前后端的专业性达到极致，并且在各自负责的部分开发效率高。然而恰恰存在这样的对接成本，导致总体效率不够理想。
于是，各种前后端分离的具体方式应运而生——后端渲染和前端渲染。因为前后端分离的成本源于两端的数据交互，页面需要展示后端数据，就要用到模板引擎进行渲染。后端渲染将数据在服务器填充进模板文件生成html，直接传给浏览器展示，浏览器相当于直接展示了静态html，对seo十分友好，首屏性能（服务器已经启动，浏览器端随开随用）和利用缓存率也好，但是由于前端（这里排除全栈）不通后端技术栈，所以就深深陷入交流成本中，常常需要先写好静态html然后有后端改写成模板文件，而且模板文件耦合度太高（html文件中嵌入后端语言QAQ），出了问题两端踢皮球，谁也不愿也解决，甚至会撕逼，令人头皮发麻。前端渲染则不同，使用前端模板（就是js模板，总有人玩弄名词），服务器将数据和模板文件一同传输给浏览器，浏览器可以识别js模板（有js引擎），然后将数据填充，生成html页面展示。如此这般，前后端分离的交流成本就几乎消除了，模板文件直接交给前端负责（会js就能编写），但是失去了后端渲染的优势，首屏性能堪忧，不利于seo，缓存率低等，最经典的就是SPA。于是有人思考能否将两者结合起来兼顾？有一个办法：引入node层，模板和数据在node服务器上渲染好再传到浏览器。当然，也不是全部模板都在node层渲染，只要关键的影响seo和网页效率部分的接口即可。
还有一个思想境界在此提醒自己：不要因为一门技术的火热而强行使用之，也不要因为自己是前端而排斥后端技术的积累，毕竟前面也提到了full stacker的作用。在项目中选取技术栈时，要善于取材而非硬套，比如Vue适合spa，在传统web page套用Vue并不明智，相对的，web page也并非不能使用Vue，Vue作为一个渐进渐强的框架，也拥有很多支持传统web的功能可供选用，一切都以实际项目需要为准，对新技术不刻意也不逃避。