现在炒作的很厉害啊，我自己其实也是稀里糊涂的 我现在做的项目是ExpressJs + Handlebars(hbs),后台服务还是Java，前端只做路由控制和页面渲染 之前看了一位大大的文章，说根本不存在所谓的前后端分离 所以我就想在此开贴，不讨论什么是前后端分离，我只想问：什么是前后端“不”分离？ 比如说，难道说用JSP做为模板引擎，就是前后端不分离？ 欢迎大家讨论一下这个问题，困扰我蛮久的了！
看前后界限在哪呢。
- 用node.js做前后分离, 路由还是node这边来处理，去相应不同的页面。
- 还有一种前后分离，后端不限语言，只需要提供一个静态 index.html 入口以及 rest api or JSON API, 路由由前端的框架处理。
我的想法比较极端吧大概，我觉得前后端分离应该是后端只提供接口、返回数据（JSON数组、判断用的响应值），前端获取到数据、构建页面。按这个说法的话后端用模板引擎就不算前后端分离了。 然而这样搜索引擎不好爬取或者压根不能爬取啊。
我认为，前后端不应以不能以模板在哪里渲染为依归，而应以工作的职责为界限。 若 node.js 跑在服务端，但也是调用后端提供的 api ，负责用户体验，作基本的数据检测之类，然后渲染 html ，也算是前端。 后端应该是负责数据的处理，包括检测，转化，各种业务逻辑的实现，事务原子性，吞吐，队列，缓存，分布式方面的工作。 也就是前端主要面向用户，而后端主要面向服务器，中间通过API作为桥梁彼此配合工作。 不过现在一般讲前端，多数谈的是在浏览器端作实现。 随着 react 流行，同构也会是很热门的话题，也就在浏览器实现SPA（利用 h5 的 browser history API），然后再在服务端并行地生成 html 以解决 spa 对搜索引擎不友好的问题。但个人认为这种技术听起来美好，做起来必然是很蛋痛的事情！
天下大势，分久必合，合久必分，无谓纠结。
曾记得在php的世界，从最开始在html里写php代码，然后的所谓smarty模板引擎，再然后，又回到在html里写php(php本身就是最后的模板引擎)，再后来，所谓的后端已经不管展示了，只处理业务逻辑。大胆猜想，再后来，后端连业务逻辑都不管了，只管权限验证和数据存取
你可能不懂架构，但你的代码写多了，自然就不自觉的使用了合适的架构。 你可能不懂模式，但你会慢慢发现，你的代码里满满的都是模式。
Web 开发，合久必分，分久必合！
“遥想公瑾当年”，没有框架支撑的时候，什么 JSP，ASP 和 PHP 都是简单的将后端逻辑代码组合成前端 HTML 标签的输出，甚至用后端语言动态生成一些 JavaScript 代码也是经常做的，这也算是前后端融合，只是混乱的融合、牵强的融合、不能自已的融合。前后端代码你中有我，我中有你，生生世世不分离。
后来终于有些人按耐不住了，说这样“缠绵”想离婚，想分财产都做不到呀，结合之前就得把彼此职责分清楚，后端的就干“家务”，前端的就出去“卖脸”，于是前后端终于通过协议彼此联结在一起，通常来说这些协议可以是任何约定好的东西，不过那个时候也就是所谓的 Ajax 啦。这就是所谓的合久必分。
那些年代，有谁会妄想 JavaScript 也能做后台的，估计 15 年前 Gmail 诞生的时候，写 Gmail 的王大锤（大牛）都“万万没想到”，会有个 V8 引擎，之后横空出来一个 Node。JavaScript 能写后台的年代开启以后，自然而然的会令人联想到既然前后端都能用 JS，何必不让同一段代码能兼容不同的 JS 运行时环境：Browser，Node、Java 乃至硬件平台，这样就跟物理学中的大统一理论一样，所有流派都拜倒在 Isomorphic 教下，统一武林，指日可待。这就是分久必合。但明白人都能看出来，这种“合”与十多年前的“合”是大不同的，如果非要选两个词的话，我觉得“组合” VS “融合”可能有些贴切，就像是前后端技术结合以后生出来的小 baby，似像非像，而且还能做同等的事情。
