未来Web应用的前端技术选型畅想

上半年,我写过一篇《2015前端组件化框架之路》,现在大半年过去了,这段时间一直在思考,未来的东西是怎样的。

目前我主导着苏宁的云计算相关的所有前端项目,这些项目以控制台为主,几乎都广泛使用了Angular 1.x,一方面因为个人技能之前有积累,一方面因为产品的开发人员基本都是Java方向转岗,对Angular的接受度较高,上手非常快,开发效率也非常高。

但2015年,前端的世界发生了很多变化,这些变化快得超出我想象。在这个巨变的时代,产品的技术选型是个麻烦的事情,具体来说,有几个方面:

  • 如果2-3年后新开始一个业务项目,可能会有什么样的技术方案?
  • 如果现在立刻开始一个新业务项目,可能会有什么样的技术方案?
  • 如果持续维护老的项目,后面可能会对它们有怎样的迁移方案?是逐步迁移,还是推倒重做?
  • 在PC端项目为主体的业务体系里,如果将来某个时机出现了移动端项目,该如何去选型,并且利用之前的业务代码?

我之前没有预料到的,是ES6的普及之快。在此之前,对于新的语言特性,人们一般会等到支持的浏览器普及之后,才会大量使用,比如ES5,但由于Babel这样转译的工具出现,我们可以渐进使用,所以,开发过程中可以完全使用ES6甚至ES7的特性编写代码,然后通过构建去达到兼容的结果。

有鉴于此,在未来的项目中,使用ES语言新特性进行开发,是一个必然要做的事情。但,这并不能算是整体方案。整体的方案应当包括但不限于:

  • 使用什么基础框架
  • 业务代码如何规划
  • UI组件如何规划
  • 样式和主题如何规划
  • 构建方案怎样
  • 人员如何协作
  • ……

所以,我们面临的,还是基础框架选型这么一个重大问题。照理说,使用Angular 1.x,后续应当选择往2.0版本过渡,但现在这个阶段,乱花迷人眼,谁也不知道未来的事情怎样,在这一层上,我个人觉得还是要再看看。

于是就卡在这里了,这个选不了,后面的事情都没法考虑做了吗?

也不尽然,我考虑了一段时间,觉得虽然每个层面都比较麻烦,但至少可以分层隔离一下。比如说,我们选了某个UI层的组件化框架,并不意味着对下层的数据模型和业务逻辑就有很强约束,至少说,这层还是有很多可选方案。

通常我们在前端,可以对一个Web应用这样分层:

UI层(View) — 业务逻辑层(ViewModel / Controller) — 数据层(Model)

比如说,数据层,有Relay,有GraphQL,有Falcor,但我们还可以继续使用原先的RESTful API啊。我们可以不使用某框架自带的请求库,比如$.get,比如$http,但我们还可以使用super agent这样独立的,框架无关的辅助请求库啊。甚至说,我们不想使用XHR了,还可以使用Fetch啊。

所以,把Web应用的前端先分层一看,发现每个层里面,都有很多独立的可选方案,而这些方案是可以组合的,比如说:

上层用React,下层用Falcor或者RESTful,然后把上层换成Vue,好像也没有什么不对啊?下层完全可以不动,也不需要就把每层代码都改一遍啊?

这样一来,我们可以先不管UI层,直接先把下面两层全部构建出来,这个部分不对DOM产生任何依赖,所以,跟上层框架没有关系,也无需按照上层框架的约定。

我们引入一个框架,对整个系统来说,最大的影响是会产生一些约定。有时候我们需要这些约定来帮我们规范代码,但在现在这种形势下,会尽可能希望框架本身不要产生约定,由我们自己,按照ES自身的一些机制来形成代码规范。

比如说,我们使用module,class之类的语法特性,基于传统的OO方法论进行一些规划,利用各种设计模式。或者,我们也可以基于函数式的理念,进行另外一个方向的规划。总之,这个层面的东西是纯业务的,可测试的,可独立运行的。

在构建模型层和业务逻辑层的过程中,我们可以使用ES6,也可以使用TypeScript。之前我曾经有个断言:如果ES6普及得快,TS的形势就会不太好。这主要是因为考虑到如果一个开发者已经在使用ES6,他去使用TS的可能性并不会很大,而如果他到ES6流行的时候尚未接触TS,后面接触TS的可能性就比较小,直接用ES6的可能性比较多。

不过,当业务逻辑比较复杂的时候,使用TS会有一些优势。即使不使用TS,我也建议把数据模型预先定义出来,在实体类里面做一些事情,尽可能使用实体类来构建数据,而不是直接用字面量来定义。当应用规模变大的时候,“严谨性”变得更加重要。

另外一个角度,如果我们要尽可能构建框架中立的业务逻辑层代码,最好是脱离上层框架的绑定监控机制,自己通过比如getter,setter这样的方式,实现数据模型的内部联动,所以从这个角度,预定义数据模型也是必要的。

在这个基础上,再回到我们的现实来,在文章开头,我提出了几个要考虑的可能,现在可以逐一回答了:

1. 如果2-3年后新开始一个业务项目,可能会有什么样的技术方案?

底层如上所述,上层根据当时情况判断选择

2. 如果现在立刻开始一个新业务项目,可能会有什么样的技术方案?

底层如上所述,上层使用Angular 1.4或者Vue之类的成熟框架,同时,使用ES6开发

3. 如果持续维护老的项目,后面可能会对它们有怎样的迁移方案?是逐步迁移,还是推倒重做?

先逐步重构,维持UI层框架不变,把底层重构成上述那样,然后引入ES6,先搞成方案2这样,后续再考虑迁移上层。

4. 在PC端项目为主体的业务体系里,如果将来某个时机出现了移动端项目,该如何去选型,并且利用之前的业务代码?

先把PC端重构如方案3,然后,PC端可继续使用Angular,移动端上层选用Vue之类性能较好的轻量库,PC端与移动端共用业务逻辑层。

以前有一段时间,我一直觉得Angular的all in one是一种挺好的策略,但最近考虑了很多事情之后,觉得将来这种方案的优势会逐渐削弱,所以,现在我也觉得纯粹做上层视图框架的Vue之类有不少好处。在未来,约束越强的框架很可能越不受欢迎,基于ES自身的语言特性做业务代码约束才是王道。

这篇主要是比较笼统地谈一些想法,后面会写两篇具体细节策略的考虑。

1 2 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部