前端重构之路(技术选型篇)

ThinkJS WebComponent 前端重构

多年以后,你再也不是那个切图仔,而前端也不再是简单的拼页面。从最初我们高举规范化大旗,什么语意化命名,统一规范。到今天,我们对工程化的信仰。每个前端团队也都在为自己的业务不断探索,追求更加完善的工程化解决方案。

注:以下文中提到的技术方案每个点均可长篇大论,这里仅做概述。日后根据重构进度逐步更新。

业务背景

HIGO前端团队组建稍晚一些,在前端业务层继承了服务端开发带来的著名的PHP框架YII。主要用于微信签名,静态资源上CDN,还有一些简单的服务端逻辑处理。

纯前端方面,并没有特别框架。大部分业务依赖Zepto,使用RequireJS来处理依赖。整个业务依赖YII发布,但其实大多只是用到了view层而已。

在很长一段时间里,这个方案并没有特别大的问题。随着前端开发人员的不断加入,以及业务复杂度的逐步增长,基于YII+RequireJS的这种整体方案也逐步暴漏出很多缺陷。

  • YII并没有发挥其真正的作用。
  • 由于业务复杂度不断增长,代码维护变得很困难。
  • 单纯的RequireJS没有完善的工程化。
  • PHP是有成本的,不是所有的前端都熟悉PHP。

重构契机

电商的重头是活动,在之前的活动中,每月的大促活动都需要我们前端去手动开发,这显然是有问题的。

为了改变这种现状,我们先是开发了一批组件,运营人员可以根据需要选择组件来创建一个活动页面。

很快,我们便发现了新的问题。运营会配上百个组件,因为我们的YII没有完全发挥作用,所以,在组件渲染上,我们只有拿到了数据(异步接口取数据),才能知道哪些组件会被用到,进而去加载组件。带来的结果是,加载异常缓慢。

当然这里还有一些其他问题,组件的逻辑太重,服务端不能按照前端要求的格式给数据(不必深究,给不了就是给不了,哈哈)。我们只能在前端先去判断,再进行渲染。

虽然经历了多次由于历史原因,因为时间问题,但是考虑到一个长期健康的发展,重构势在必行!!!

针对业务选技术

改变必然是痛苦的,只有改变才能成长,所以成长也是痛苦的!

服务端

结合种种原因,YII这一层是不能放弃的,当然YII是要放弃的。那这就没得考虑了,NodeJS当仁不让啊。那我们先看一下要解决的问题。

  • 充当Logic层,处理服务端数据。
  • 微信签名等强依赖服务端需求。
  • 页面前置渲染,静态化等。
  • 承担高并发(优于YII)。
  • 必要的缓存机制。
  • 其他服务端干的活。

NodeJS社区欣欣向荣,各种框架眼花缭乱。著名的有ExpressKoa,还有数不清的非著名框架。

在尝试了具有代表性的几个框架之后发现,结合业务,这些框架似乎都没那么完美。不完美是什么意思呢?以Express为例,我需求很多加工才能将其使用到业务中。而且存在一个模块的风险,使用的第三方模块越多,风险就越大。本着稳定为主的目的,暂且先pass掉Express

这里要提到一个国产著名NodeJS框架 ThinkJS。这个框架从1.x的时候就曾有过接触,上手简单,功能强大,稳定性好。目前已经是2.x版本,不仅继承了1.x各种优势,而且支持直接使用ES6/ES7来开发,对于前端来讲,这无疑是一大诱惑。当然选择一个框架,最最重要的是功能,性能,稳定性。ThinkJS在以上几点均有优秀的表现。经过调研及动手实践,ThinkJS在我们业务基础上有出色的表现。

这里还要提到另外一个原因:博主有幸曾和ThinkJS作者共事,售后服务五星好评。当然对所有用户来讲,作者都是一视同仁的。感兴趣的也可以加入ThinkJS官方交流群(339337680)

前端

前端方面,这次重构主要服务业务是组件建站。那首先要从组件入手了。如果说服务端框架的选择经历了一番择决。前端框架/库的选择简直日了dog了,先列一下吧。

  • React
  • AngularJS
  • Polymer
  • vue
  • backbone
  • novajs(Polymer mini)

先不要奇怪列举了这么多相关不相关的,简单过一下。暂且忽略各个库/框架的大小,先从功能看。

React

单向数据流,优秀的dom diff算法,可惜这些我们都用不到,pass。

AngularJS

SPA(单页应用)中的王者,我们不是单页应用,pass。

Polymer

Google出品,代表组件化未来的 web component。这差不多就是我们需要的了,可惜兼容性不怎么好。

Vue

vue提供的组件正是我们所需要的,可是其他功能又多余了。而且有一个问题,vue似乎没有考虑过组件动态加载,开发模式中全量打包让我接受不了,如果选择vue,意味着,我需要自己再给他配一套独特的编译系统。然后再增加一个动态打包。暂且搁置一下,没有其他方案的话再回头看。

Backbone

backbone不做评价了。这都是MVC类型的,本不该进入候选,你懂的。

Novajs

小巧的web component框架,奇舞团女神瓜瓜出品。novajs只做了一件事,就是web component。当然提供的一些双向绑定之类的功能,暂时可能用不到了。不过没关系,核心功能有90%以上是有用的。当然novajs也不是没有缺点。开发和部署差异太大,官方没有提供一套完善的开发部署流程方案。不过这个不重要了。配合我们业务可以自己完善,相比vue,这个成本低很多。

写在最后

目前为止,服务端使用ThinkJS已经可以确定了,一些配套模块也都写差不多了。前端还在VueNovajs,还是手动实现中徘徊。因为组件建站是一个相对独立的业务,可以单独考虑其前端框架,但重构是一个全量的迭代,多考虑一些总没有坏处。

技术选型,除了上述提到的客观因素,还要考虑团队情况。学习成本,上手速度都是很必要的因素,这里就不展开说了。重构进行时…

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。