evolution.md

Web 前端项目的演进过程

在经历了很多的 Web 项目之后, 我们在不同的项目中尝试了不同的解决方案.

在尝试的过程中, 前端的技术也在不停的进化, 影响着我们的技术选型.

为了给以后的技术选型做参考, 我们总结出关于一般 Web 项目的演进历程, 也可以看做是前端技术架构的演进.

演进的过程中主要伴随着

• 从简单到复杂
• 从多页到单页
• 前后端的分离
• 前端模块化/组件化
• 前端工程化/构建

具体的演进过程如下

• 多页
  • 后端直接输出 Web 内容, 没有异步请求后端接口数据
• 多页 + Ajax + 拼字符串输出 HTML
  • 静态页面变成"动态"页面, 需要调用后端接口获取数据, 在前端渲染出页面的内容
• 多页 + Ajax + 前端模版引擎(artTemplate)
  • 拼字符串难以维护, 引入前端模版引擎来实现数据层与展现层的分离
• 多页 + Ajax + 前端 MVVM 框架(Vue)
  • 引入前端 MVVM 框架来取代前端模版引擎, 数据与视图同步更新, 更彻底的分离出展现层
• 多页 + Ajax + 前端 MVVM 框架(Vue) + (模块化)依赖管理(RequireJS)
  • 前端的依赖混乱难以管理一直是前端的毒瘤, 项目变大后团队的协作是个问题, 很容易就发生 JS(全局) 和 CSS(全局) 的冲突
  • JS 和 CSS 本身在语言层次上没有提供模块化解决方案
  • JS 一般通过闭包导出命名空间到全局来规避冲突, 实现简易的模块化
  • CSS 一般通过命名规范来规避冲突, 例如 BEM 命名规范
  • 如果只是简单的项目, 可以引入历史技术 AMD 来实现模块化和依赖管理
  • 一旦有了模块化管理, 势必会慢慢涉及到前端构建方案(Grunt/Gulp), 来做前端的打包和发布
• 单页 + Ajax + 前端 MVVM 框架(Vue) + (模块化)依赖管理(webpack/ES2015) + 前端路由(vue-router)
  • 单页的复杂度是前端的一个转折点, 你会遇到越来越多前端工程化方面的问题, 首先需要了解的就是前端路由的实现原理(hashchange/HistoryAPI)
  • 因为实现单页的基础就是引入前端路由来模拟出"多个页面视图"的逻辑切换
  • 模块化之后, 为了模块的重用, 一般会定义出公共模块和各个页面视图模块, 模块的数量会越来越多, 首次需要加载的文件也就会越来越多, 你肯定不想浏览器首次加载的时候需要发送几十个请求吧, 因此我们需要前端构建工具来打包我们的模块
  • 然而你肯定也不想所有的模块都打包成一个文件(all in one), 这样肯定会拖慢页面首屏加载的速度, 因此迫切的需要代码分隔和模块懒加载(一般是根据路由的懒加载)
  • 那么既然已经引入了前端工程化构建的过程, 那么前端一些最新的规范(例如 ES2015), 我们也就可以用起来了, 让我们面向未来编程
• 单页 + Ajax + 前端 MVVM 框架(Vue) + (模块化)依赖管理(webpack/ES2015) + 前端路由(vue-router) + 状态管理(vuex)
  • 页面视图上需要控制的状态越来越多, 多个页面视图的状态又有依赖共享, 到底是哪里触发了某个状态的改变, 哪个视图又会受到这个状态改变的影响?
  • 你是不是通过全局事件做过组件之间的通信? 你能够预测到状态与视图之间的对应关系吗? 是不是越发地难以控制难以调试了?
  • 引入前端状态管理的架构方案让代码结构标准化可控
  • view = f(state)

所以我们并不是什么项目一上来就先来个 xxx 全家桶, 记住技术栈越长依赖越多, 复杂度越高越难以全全把握.

附

一般的互联网 Web 项目(以电商为例)可能包含的子项目

• 官网(介绍页面)
• 移动 Web 端(店铺移动 Web 端)
• App 端
  • iOS
  • Android
• PC 端
  • PC 用户前台(店铺 PC 端)
  • PC 用户管理后台(店铺后台)
  • PC 系统管理后台(系统后台)
• 微信小程序...
• 其他平台(例如桌面程序)