前端 UI 框架发展史

上一小节我们了解了前端 UI 框架的作用和意义，接下来我们再来了解前端 UI 框架的发展历史。

虽然是讲历史，但我不想讲得太复杂，也不打算搞什么编年史记录啥的，毕竟我们不是来学历史的。

我会简单描述一下前端 UI 框架的发展历程，同时在这个过程中，把我自己的一些感受和想法分享给你。

你可以以轻松娱乐的心态来看这篇文章，同时也大概了解一下我们前端开发是怎么发展到现在这样子的。这样可以让你更好地去理解将要学习的前端 UI 框架。

前端行业到底是怎样发展的呢？对于新人的你肯定是不了解的。我说说我的理解。

我认为整个前端行业是围绕着复杂度来发展的，跟很多其他的技术发展差不多。

因此，接下来我会以复杂度这个核心来聊聊前端 UI 框架的发展历程。

无复杂度：JSP & Dreamweaver

在互联网刚开始的阶段，网站的页面是非常简单的。在现在的我们看来，几乎就是纯静态的页面，没什么动效，也不会有多少复杂的交互，最复杂的交互就是填一张表单，然后提交到服务器。

当时最大的瓶颈是带宽。当时的网速贼慢，跟现在是完全没得比的，当时正常的网速搁现在，那就是卡顿，而且是卡得要死。当时有个笑话，当你要打开某个网站，在浏览器输入网址之后，可以先去洗个澡，回来才能看到网站。

在这种情况下，网站要做的就是提供最核心、最具性价比的内容和功能，而不是漂亮、用户体验好的网站。另一方面，程序员行业也没有迎来大发展，在当时，程序员还是个新型职业，从业人数非常少。

这些原因共同造成了一个结果：就是没有前端。那网页谁来开发呢？当然是后端，在当时，没有前端，所以也不叫后端，反正就叫程序员。当时，他们实现网页的方式是使用一种模板技术，不同的语言有自己的模板语言。在当时比较流行用 Java 来做 Web 站点，因此配套的模板语言 JSP 也比较流行。

我们可以看一段 JSP 代码感受一下：

jsp 复制代码

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ page import="java.io.*,java.util.*" %>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>xx 教程</title>
</head>
<body>
<h1>读取所有表单参数</h1>
<table width="100%" border="1" align="center">
<tr bgcolor="#949494">
<th>参数名</th><th>参数值</th>
</tr>
<%
   Enumeration paramNames = request.getParameterNames();

   while(paramNames.hasMoreElements()) {
      String paramName = (String)paramNames.nextElement();
      out.print("<tr><td>" + paramName + "</td>\n");
      String paramValue = request.getParameter(paramName);
      out.println("<td> " + paramValue + "</td></tr>\n");
   }
%>
</table>
</body>
</html>

这是我从网上随便找的，不需要太在意这个网页是干什么的，就单纯感受一下 JSP 的语法。

在后端的角度来看，要展示 Web 站点，就要给浏览器返回一个 HTML 文件，而这个 HTML 文件就是一段包含 HTML 代码的字符串。所以你会看到，上面的 JSP 代码都在处理字符串拼接的事情。有经验的同学应该能想到，这不就是 SSR 么，是的，它就是 SSR，本质是一样的。

你可能会问，那个时候既然没有前端，那谁来做 UI 呢？答案是设计师。当时有种职业叫原型开发。他也算设计师的一个分支，同时也是前端岗位的前身。当时的 UI 偏向纯静态站点，没有复杂交互，因此原型开发主要使用 HTML 和 CSS。

原型开发要么自己设计，要么根据设计师给的设计稿来开发 HTML & CSS 代码，调完了之后，把 HTML 文件发给后端开发，后端开发再把这个 HTML 文件转换成 JSP 代码。这就是原型开发和后端开发之间的协作方式。

当时在原型界非常火的一个框架是 Dreamweaver，严格来讲，它其实是个工具。

之前的图片很难找了，我随便找了一张图片，差不多能展示 Dreamweaver 是个什么工具了。简单地说，原型师可以在 Dreamweaver 中通过拖拽配置的方式来搭建网页，最后输出 HTML & CSS 代码。因此，当时很多原型师都不需要直接写 HTML & CSS 代码，他们只需要了解 HTML & CSS 语法知识就好了，所以说原型师还是更偏向于设计师，而不是开发。实际上，当时的程序员群体也是把原型师看做设计师的。

有经验的同学一下就看出来了，这不就是低代码么，没错，Dreamweaver 本质就是个低代码工具。是不是觉得很神奇，在互联网最开始，SSR 和低代码技术就已经大行其道了，所以现在前端届流行的 SSR 和低代码都不是什么新鲜事了，只是翻炒冷饭而已。

严格意义来说，当时都还没有前端，所以也谈不上前端 UI 框架，但是我觉得既然聊历史，那就不得不聊一下这段时期的事情。我把这一阶段的前端 UI 框架定义为 JSP 模板框架 + Dreamweaver 低代码框架工具。因为当时的网站 UI 主要就是这两个技术搭建出来的。

UI 效果复杂度：前端开发攻城狮

随着互联网的发展，网速上来了，网站可以做更多东西了，设计和交互越来越有创意了，这时网站的 UI 效果复杂度就越来越高了。

这带来的最直接的后果就是后端开发顶不住了。要同时负责前端和后端，如果是简单的小站点还好说，但如果是复杂的电商网站和博客网站就难顶了。术业有专攻，要同时深入研究后端技术，还要钻研前端动效，现在的全栈工程师都顶不住，何况当时。因此，在一些大型网站公司，慢慢地就出现了专门的前端团队，当时最出名的，就是百度、淘宝、QQ 空间几个前端团队了。

在当时，前端开发主要来源于 3 类：

后端程序员转前端，这种算比较少，大部分是被强迫的；
原型师发展为前端，这是最多的，自然而然的事情；
新人程序员，直接上岗就做前端。

慢慢地，就没有原型师这个职业了，要么回到老本行做设计，要么去做前端了，现在几乎听不到原型这个职业了。

这段时期的初期，设计师提供设计稿，原型师实现出 HTML & CSS，然后前端开发 JavaScript 代码，后端再转换成 JSP。

最后随着前端发展壮大，就逐渐地前后端分离了，原型师被淘汰。最后的流程就是现在这样，设计师提供设计稿，前端开发 HTML&CSS&JS，后端开发提供数据接口。

这一时期的前端 UI 框架是什么？我觉得是前端开发攻城狮本人。前端开发通过自己的前端技术知识和程序员知识，把设计稿实现成复杂的、可交互的 UI 界面，这不就是最厉害地前端 UI 框架吗？

浏览器兼容复杂度：jQuery/ExtJs

随着前端技术大发展，标准不断更新，功能不断叠加，各家浏览器厂商为了争夺市场，也不遗余力的支持新标准和扩展功能。最终给前端界带来了新的复杂度：浏览器兼容性复杂度。

这绝对是前端届深恶痛绝的事情。我们在实现繁重地需求功能还有应对老板的奇葩需求的同时，还要处理烦人的浏览器兼容性。这是一段煎熬的日子。

要处理浏览器兼容性，需要安装不同的浏览器，对于同一个浏览器来说，还要安装不同版本。

同一个页面，要在不同的浏览器，不同的版本，把所有功能都测试一遍。

QA 给我们提了一个 bug，用户给我们反馈了一个问题，很多时候都没办法复现。

现在的我回想当初，也是无比煎熬，我认为这是极大的消耗我们前端开发的生命！因为解决浏览器兼容性问题，对我们的职业生涯来说，毫无意义。

那段黑暗的日子就不多说了，我们聊回前端 UI 框架的话题。在当时，jQuery 是当之无愧的前端 UI 框架一哥，它的意义和流行程度比现在的 React/Vue 更有过之。在前端历史中，必有 jQuery 的一席之地。

jQuery 核心就是解决浏览器兼容性，统一了前端代码的写法。使用 jQuery，能避免大部分的 JS 兼容性，极大地提升了前端开发的效率。除此之外，jQuery 还有非常多优秀的设计：

它的语法糖让人爱不释手
deferred 语法，那个时候还没有 Promise 呢
动画队列，至今仍有借鉴意义
...

在 admin 领域，同样也有开箱即用的 UI 组件库，当时比较火的是 ExtJs。就是类似 antd 一样的开箱即用 UI 组件库，还有以此为基础的 admin 基础框架。值得一提的是，不管是 jQuery 还是 ExtJs，当时的前端库大多是用继承的概念来组织前端库的，不像现在，已经流行组合了。

前端工程复杂度：React/Vue

接下来就到了现在这个时代了，React/Vue 作为主流的前端 UI 框架。

互联网的蓬勃发展，对 Web 站点的功能、性能、交互体验等方面都有极大的要求。前端项目的代码量越来越多，页面越来越多，组件也越来越多，这些变化给前端项目的工程化带来极大的复杂度。

而 jQuery 已经越来越力不从心了，jQuery 虽然解决了浏览器兼容性的问题，但它仍然是一个直接操作 DOM 的框架。使用 jQuery，我们不仅需要通过操作 DOM 来处理 UI 界面，还要处理复杂的逻辑。当这两部分的代码交织在一起的时候，就是我们加班改代码的噩梦所在。

jQuery 的自由度很高，但是想要基于 jQuery 把整个前端项目的代码给管理好，需要极高的编码功底，还有严格被执行的规范，才能做到不错的地步，仅仅是不错而已。

于是，React/Vue 应运而生，它们做了高度的封装，可以让前端开发不直接操作 DOM，而是通过操作数据来处理 UI。通过这种方式，来解耦 UI 和逻辑。我们在使用这些框架的时候，必须要遵循他们的基本用法，这样就极大地在我们的项目中应用了这些框架的方法论，让我们的前端项目代码可以被更好地组织和管理，从而拥有一个比较好的可维护性和开发效率。

当然，不是说我们只要使用了 React/Vue 就可以让我们的代码更好维护了，React/Vue 只是给我们提供了下限而已。想要让我们的代码更好维护，还需要不断提升我们自己的编码和设计能力。

好了，前端 UI 框架的发展历程差不多就介绍到这里了，可以看到，前端 UI 框架是伴随着互联网行业而发展的，你觉得，下一步，前端 UI 框架会如何发展呢？