浅谈 IBU 酒店大前端

在当今互联网+高速崛起的时候，也许大前端这个概念已经成为前端技术老生常谈的话题，但是正正去做好“大前端”，显然并不容易。

为什么不容易呢？我觉得最关键的是人才匮乏，虽然互联网发展10多年了。前端技术人员依然稀缺。导致这样问题原因之一是我们教育环境。大家都知道在我们大学里不仅没有前端主修课程，而且我们的师资力量跟不上日新月异前端技术，才会导致人才稀缺，所以大部分毕业生都不会选择做前端技术，在这里，我呼吁我们教育能和社会需求接轨。

什么是大前端

这个问题其实学术上没有明确领域划分。我考虑了下，大致可以分为横向和纵向2个维度去划分。

从纵向上来看，可以理解为浏览器端和Node服务端的。在过去的几年里，NodeJs 的兴起，让前端不再局限于浏览器端，给前端人员有一种从前端到后包打天下之喜悦。不过细细分析下来，由于受限于本身特性，所以无法得到大范围运行，不过node确实为前后端分离指向明确的方向。

从横向上来看，可以理解为泛UI，比如PC、移动H5、ReactNative、Weex、hybrid、小程序等等，凡是由JavaScript 构成的视图层都可以理解为泛UI。当然更广义的可以算上iOS 与 Android，包括flash、silverlight等等。

无论是横向理解还是纵向认知，随着互联发展，大前端势必会成为越来越受到关注。

为什么要做大前端

谈起这个话题，就需要明确一个问题，大前端为我们带来了什么？最为关键的，我觉得降低成本。

1）降低沟通成本，如果说产品一个需求H5上做讲一遍，势必也需要在其他平台上讲一遍，而我们测试又需要在多个平台去测试一遍业务逻辑（我这里讲的不是兼容性问题）

2）降低研发成本，就如我文章开头所说的，前端资源稀缺，成本高。如果我们可以用统一技术去实现“write once run anywhere”，那么就可以最大程度上降低研发成本。

由此可以想到，我们做大前端是为了提高工作效率，解决产品、测试痛点，更好为用户服务，提升用户体验为核心导向

如何去做大前端

1）技术选型

前端技术很多，可以说市面上前端框架少说也有几十种了。比较主流MVVM架构就有Vue、React、Angular 三大体系，除MVVM思想以外，Jquery等也经久不衰。到底使用哪个最为合适？不少人会去选择最为主流，使用最多。当然这没错，用的人多了。框架出错情况越少，错误的解决方案就越多。但是，往往今天主流的未必明天仍旧主流。就好比曾经AMD与CMD之争，sea.js弃用是一回事情的。

那么我考虑的是什么呢？我会考虑当前产线最大痛点是什么，我们需求是什么，我们要解决什么样的问题。从这个角度出发去定型我们技术框架。

首先，我们需要使用MVVM架构，这样不仅提高开发效率，而且能吸引人才加盟。

其次，我们需要在online上支持MVVM架构，哪怕是在IE7上，而且不需要太大成本去支持，有人会问，现在PC端浏览器的占比不是很少了么，为什么还是考虑PC端，甚至于要考虑低版本浏览器呢。那是由于我们是在做海外产品，不少国家仍旧在使用低版本浏览器。为了不抛弃哪怕百分之一的用户，在技术上我们尽量去满足，去support。

再次，我们需要seo，也就需要考虑到服务端渲染。

再次，我们需要spa（单页设计）

最后，我们需要size压缩到最小。

我是以要求为导向反向推技术选型。按照这个标准，三大主流框架全部淘汰。有的无法满足这个，有的无法满足那个。最后选择来选择去。我们定型于React。有的人看到这里会觉得你不是前言不搭后语么。我这里指的react并非标准react，而是react语法。我在PC端采用reactIE，我在H5采用preact，我在ios或Android中用reactnative。同时搭配node+koa2做SSR服务端渲染，满足我上述提出的所有要求

2）架构设计

首先，我们需要考虑的是前端职责是什么？前端需要考虑的用户交互行为，浏览器兼容性，代码扩展性，而不是大批量数据运算与转换。对于前端而言，最好能做到“所见即所得” 。所以我们的目的是要把前端做轻做薄。把复杂业务逻辑，数据转换逻辑推向后处理。

其次，我们需要考虑的是结构上剥离，让业务层和框架结构更加清晰

再次，我们需要考虑的是前端监控，最好能把所有错误都统计起来。包括而不限于前端window.onerror.此外我们最好能把前端用户轨迹能记录下来，以方便数据分析及排障。

最后，我们还需要考虑的是我们node层如何来处理爬虫。

带着以上几个点简单分享下我们设计的架构图

a）代码仓库划分

我们采用的4git仓库，分别存放online、h5独有代码，Ares DB存放前端共用业务组件和框架组件，Node+Koa存放共用node框架。这样好处在于通过npm包的方式共享代码，让业务和框架代码分离，职责更加明确。

b) node架构设计

大致可以分为从服务启动注册、用户访问流程管控、React服务端渲染html三大模块。 很显然，哪怕在node层也不会去做运算逻辑。除了监控日志外，就是做好服务端渲染。这里每一步流程，我就不一一展开了

c) 前端组件架构设计

3）收益和效果

我们能在online和h5 上共享组件，带来开发成本减少，能做到改动一处逻辑2端收益效果。

拿已经上线的订单完成页来举例，与之前size和请求数相比，我们少了将近50%左右。domready速度快了1倍多。同时采用服务端渲染，也减少白屏时间

老版本

新版本

总结

大前端目前确实比较火，但是还是有很多路需要去走，去探索。个人觉得我们应该是多多思考，从痛点出发，来解决问题，而不不应该人云亦云。这里浅谈一下我们大前端之路，欢迎各位给出不同意见和见解。