意义很大,但是你的问题本身认识有偏差。
对于前后端分离,认识上有个误区,那就是很多人自称:我们老早就分离了,全AJAX,使用Angular或者什么什么就可以了。
这个说法是不合适的,打个比方,别人问的是“如何解决家禽把蛋生在水草边的问题?”,但实际上人家养的是鸭子,答题的却是养鸡的,所以回答“不让去水边就行了”,这显然不在点子上。
这两年业界说的前后端分离,是限于偏展示类的系统(用A代替),而不是应用、管控类Web项目(用B代替),在B类项目里,前后端是天然分离的,对此,除了少部分后端开发人员,基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目,在B类项目里,前后端分离是共识,不需要讨论。
那么,剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢,在于模板的与数据结合的位置,以及,模板的控制权在谁手里。经过这两年的讨论,基本上我们可以达成的共识就是:模板应当由前端人员去控制,主要原因有两方面:
- 性能优化(尤其是外部资源的管理与发布,请求合并等等)
- 协作的顺畅性(已形成模板的界面片段的返工等问题)
那么,模板到底应该在什么地方跟数据结合?
这个问题就比较折腾了,有部分人尝试像B类项目那样,使用js模板,然后在浏览器端执行,这是存在一些问题的,比如说seo不友好,首屏性能不够,尤其对于首页DOM量很大的电商类网站,差距很明显。
所以我们还是得把主要的模板放在服务端来执行。在这个过程中,阿里作了一些尝试,那就是引入Node层,在这一层把模板与数据进行合成,然后浏览器拿到的就是生成好的HTML了,但也不是所有HTML都是这么生成好的,还是会有一些内容等到了浏览器之后,再用js去加载和生成。
所以这一定会是一个混合方案,同一个系统中存在两种模板,一种在服务端执行,一种在浏览器中执行,互为补充。
至于说这个方案中,是否中间层一定要是node,我觉得无所谓,只要是能正常做web项目的东西都可以,这个还是要看所在企业的技术积累方向,当然node做这块是有一些优势的,比如对前端人员的语言友好性,前后端模板的通用性等等,但这些都是细节,重点还是整体方案和流程。
这时候回头看你问题中的这句:
> 前后端分离的意思是,前后端只通过 JSON 来交流,组件化、工程化不需要依赖后端去实现。
我相信你这里对前后端的限定是以浏览器为准的,但事实上,A类项目中,前后端的分界一定要延伸到服务器端的模板层,也就是在这一层里,把各种来源的数据整合到模板中,这个数据未必是JSON格式的,会存在有JSON,XML,特定的二进制等等。
组件化这个话题就更复杂了,在刚才组织形式中,很难说出究竟什么才是组件。是某个商品的模板吗?是数据吗?是数据和模板的结合体吗?没法回答。在此,我说一句自己的看法:像电商这种项目的前端部分,基本不存在组件的概念,甚至不存在组件化的价值,因为这里面可复用的东西太少了,也不易提取,大多数东西都是不带逻辑的界面模板。
最近因为ReactJS的流行,带来了一个Isomorphic的概念,这是一种很有意义的探索,但是否能解决这类问题,尚不得而知,根据我的理解,它对B类项目是较好的补充方案,但对A类项目暂时还缺乏可用性,因为A类项目中,运行期的DOM变更并不多,多是整片的改变,用这个方案去解决的话,有些牛刀杀鸡的感觉。
关于B类项目的组件化,我之前那个没写完的系列是关于它的,但经过最近一年多的思考,我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我,这就写。