最近1年多,前后端同构慢慢变成一个流行词,也许很多人还停留在前后端分离的最佳实践道路上,但实际上又有一批人已经从简单的服务端渲染走向探索最佳前后端同构方案的路上了。不过,我只是膜拜后者的过客。 虽然大家可以去网络搜索一下相关的概念解释,但这里我还是简单列举一下,我理解的术语。 1、前端渲染:浏览器一侧使用js,借助模版或vue、react、angular等框架做的DOM结构生成。 2、后端渲染:服务器一侧,使用php、nodejs等技术实现DOM结构生成,并在HTTP请求中返回给浏览器。 3、同构:浏览器一侧的JS、HTML和服务器一侧使用的JS、HTML使用同样的开发结构,同样的开发思路,同样的开发模式,尽可能实现代码复用。 明确一点,作为有追求的前端开发,我们不应该盲目跟风,一切需要从实际出发。 那么,首先,我们需要了解为什么会有同构这个概念出现。
百度搜一下前后端同构,清一色的vue、react。这些确实是同构,但我认为范围太窄,同构不是框架带来的问题,而是因为前后端独立渲染这种架构层面带来的问题。 当然,那些同构探讨也是非常有价值的,但不在本文的讨论范围内,在这里我更想表达一下,如何从实际项目需求的角度来看,找出自己所需的同构之道。 毕竟,要知道,同构不是为了跟风耍酷,也不是为了跳槽面试的时候博点好感。同构,是为了提高用户体验的同时,提高团队的工作效率。 接下来,我想根据项目的类型,说说自己的看法。 第一种,单页面应用。 这个网站很类似一个APP,确实很有必要做成单页应用,有助于提高用户体验。 如果第一步选择了单页面应用,这里就衍生了另外的问题——SEO。而react等框架做了服务器渲染,最大目的其实也是解决SEO。 既然浏览器端选择了某个框架,例如React,而同时又考虑nodejs直出提高首屏的速度,那么就没有讨价还价的余地了,当然上react全家桶,前后端都用react。 这一种情况,也就是网上搜索到的各种文章的情况。 第二种,多页面纯数据展示,每一页都比较简单,没有分屏的必要。 如果项目是这样的情况,使用nodejs直出,无非就是提高打开速度。而前后端基本八竿子打不着,最多就是一些工具函数(转换一下日期格式,输入框校验)要做复用。 此时,没必要大费周折去考虑什么框架,因地制宜,想想自己需要什么即可。 要解决函数库的前后端复用,可以简单做commonjs/window的兼容。 如果浏览器端的代码比较多,就可以考虑粒度化,使用webpack做浏览器端代码打包,同时commonjs的写法也可以复用到nodejs层。 第三种,多页面而且每一页不是那么简单,首屏和次屏有一些HTML片段(模版)需要复用 之前我所在项目组也遇到这样的情况,怎么处理,一时之间为了赶进度也没太多考虑,使用了一些旁门左道,不好理解不好维护的方式,基于art-template做了一套有点奇怪的代码,基本没有同构一说。唯一同构的就是art-template支持浏览器和nodejs。 情况怎么恶心呢?大概是这样:
回头想想,当时情况确实很糟,其实可以利用已有的工具做得更优。 art-template是个好东西,这个没必要去除。刚说的前两点,表明这个项目有强烈的前后端代码复用的必要,很有需要使用更全面的同构方案。 现在我觉得有更好的方式:
引入了webpack到浏览器端,就能很好的解决了原先html模版传播的尴尬。而模块风格的统一,也有利于前后端代码更好的复用。 至于最终浏览器js是否打包到首屏HTML中,还是单独的部署CDN,这个其实就不是同构的问题了。不过对于移动端而言,还是建议合并在一起。 抽象一下,对于第三种项目情况,跳出我原先的项目。我认为,关键是要把前后端使用的模版统一为一个方式引入。 第四种,还是多页面,浏览器端没有模版拼装的需求,第三种情况的变种。 或者说,这个不是一个单独的项目情况,只是因为用的技术方案不同。跟第三种情况一样,但次屏的渲染,我们不在浏览器端执行,而是继续交给nodejs。浏览器端通过ajax把次屏html片段拉取回来,然后直接塞到body中。而且,除此之外,浏览器端没有用户交互会导致已有的DOM发生重绘,或者极少内容重绘,不需要动用到模版。 在这个情况下,浏览器端js更纯粹的只关注事件处理。 我觉得这个又回到了第二种情况,只需要简单把一些库函数封装一下,做成前后端共用即可。 第四种情况,因为彻底抛弃了浏览器渲染,整个情况就简单多了,不需要考虑模版和很多逻辑js的前后端复用问题。 |
|