前端那些事儿(3) --- WEB架构的历史变迁

经常有人问我:

  • 前端到底是干啥的?
  • 怎么入门呀?
  • 为什么以前从来没有前端工程师这个职位,但是现在到处都在招前端?

大多数的新人刚刚入门前端,就扑面上去把HTML、CSS、JS学了,然后感觉前端就是这么多内容,简直就是个“画网页的”,实在没什么技术含量,这种观点甚至被很多大牛不停的宣扬,比如知乎上的某轮子(逃

所以我想专门写一篇文章来介绍一下WEB发展的历史,为什么需要前端工程师,以及前端工程师到底是做什么的。

WEB的石器时代

1991年,CERN(European Particle Physics Laboratory)正式发布了Web技术标准。目前,与Web相关的各种技术标准都由著名的W3C组织(World Wide Web Consortium)管理和维护。

从技术层面看,Web架构的精华有三处:

  • 用超文本技术(HTML)实现信息与信息的连接;
  • 用统一资源定位技术(URI)实现全球信息的精确定位;
  • 用新的应用层协议(HTTP)实现分布式的信息共享。

那个时候的网站,其实就是一段运行在服务器上的程序,当你访问请求时,它便会返回一段HTML文本(这个时候还没有CSS/JS),浏览器解析这段HTML,然后页面就在你眼前了。

这里写图片描述

这就是世界上第一张网页,现在依然可以访问:
http://info.cern.ch/
里面有关于WEB和浏览器的历史,不妨看一看。

这个时候的WEB,还在茹毛饮血的时代,根本不存在所谓的“前端工程师”,因为WEB还很简单,只需要一个服务器端的程序,那时所有的程序猿都是做服务器和后台的。

那个时候的浏览器,大概长成这个样子:

这里写图片描述


新成员CSS、JS的加入

1、JS

1996年,红极一时的网景公司在它的Netscape浏览器2.0版中增加了对JavaApplets和JavaScript的支持。

这里写图片描述

Netscape的冤家对头,Microsoft的IE 3.0也在这一年开始支持Java技术。现在,喜欢动画、喜欢交互操作、喜欢客户端应用的开发人员可以用Java或JavaScript语言随心所欲地丰富HTML页面的功能了。

顺便说一句,JavaScript语言在所有客户端开发技术中占有非常独特的地位:它是一种以脚本方式运行的,简化了的Java语言,这也是脚本技术第一次在Web世界里崭露头角。为了与JavaScript抗衡,Microsoft还为1996年的IE 3.0设计了另一种后来也声名显赫的脚本语言—VBScript语言。

2、CSS

1994年哈坤·利提出了CSS的最初建议,当时已经有过一些样式表语言的建议了,但CSS是第一个含有“层叠”的主意的。

在CSS中,一个文件的样式可以从其它的样式表中继承下来。读者在有些地方可以使用他自己更喜欢的样式,在其他地方则继承,或“层叠”作者的样式。这种层叠的方式使作者和读者都可以灵活地加入自己的设计,混合各人的爱好。

哈坤于1994年在芝加哥的一次会议上第一次展示了CSS的建议,1995年他与波斯一起再次展示这个建议。当时W3C刚刚建立,W3C对CSS的发展很感兴趣,它为此组织了一次讨论会。哈坤、波斯和其他一些人(比如微软的托马斯·雷尔登)是这个项目的主要技术负责人。1996年底,CSS已经完成。1996年12月CSS要求的第一版本被出版。

这时的WEB已经开始展现雏形,HTML/CSS/JS三大件凑齐,可以召唤神龙了呢(误


服务器端技术的成熟与发展

上面说到过,最早的WEB服务器非常非常简单,响应HTTP请求,把储存在服务器上的HTML/CSS/JS文件发给浏览器,浏览器解析,生成页面给用户。

这个时候的HTML文件是静态的,换句话说,它只能实现“展示”的功能,因为所有用户根据URL请求到的HTML都是一样的,没有任何动态。

第一种真正使服务器能根据运行时的具体情况,动态生成HTML页面的技术是大名鼎鼎的CGI(Common Gateway Interface)技术。1993年,CGI 1.0的标准草案由NCSA(National Center for Supercomputing Applications)提出,1995年,NCSA开始制定CGI 1.1标准,1997年,CGI 1.2也被纳入了议事日程。

CGI技术允许服务端的应用程序根据客户端的请求,动态生成HTML页面,这使客户端和服务端的动态信息交换成为了可能。

JAVA、C++、PYTHON等一系列语言都可以用来实现CGI程序,这就是所谓的“动态网站”。

这里写图片描述

有人可能要问了,这和前端开发有什么关系么?

关系很大,这个时候已经开始出现前端开发的雏形,但还非常简单,因为这个时候只需要写一张页面,然后交给后台工程师变成CGI程序,所以被称为“页面仔”(现在很多人黑前端的来由就是如此)

这个时期的WEB已经和我们现在的WEB差别不那么大了,比如我们现在用的微博、人人,其实用这些技术已经足够写成了,现在还依然保留有大量上一代技术写成的网站。

那后来到底发生了什么,让前端突然从一个“页面仔”变成“工程师”的呢?


AJAX的出现

AJAX是“Asynchronous JavaScript and XML”(异步javascript与XML技术)的缩写,在1998年就被提出,但直到05年的时候才被大量应用,最有名的便是GOOGLE的一系列产品:GMAIL、GOOGLE MAP等等。

这里写图片描述

传统的web应用允许用户填写表单(form),当提交表单时就向web服务器发送一个请求。服务器接收并处理传来的表单,然后返回一个新的网页。

这个做法浪费了许多带宽,因为在前后两个页面中的大部分HTML代码是相同的。由于每次应用的交互都需要向服务器发送请求,应用的响应时间就依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。

与此不同,AJAX应用可以仅向服务器发送并取回必需的数据,并在客户端采用JavaScript处理来自服务器的响应。因为在服务器和浏览器之间交换的数据大量减少,结果我们就能看到响应更快的应用。

如果仅仅是更快,还不足以改变WEB的格局,更重要的意义在于,AJAX使得很多的处理工作可以在发出请求的客户端机器上完成。这是前后端解耦的重要环节。


前后端解耦

为什么“让处理工作在客户端完成”的意义如此重要?

我们来举个例子:

下图是一个传统的、现在依然在很多网站使用的架构:

这里写图片描述

这个架构很常见,一个MVC框架的后台(比如python的django、PHP的cakephp、JAVA的Spring MVC、ruby on ralis),响应用户的请求,动态生成HTML页面,发送给用户。

在这个架构里,前端的工作大部分是将美工稿实现,把HTML/CSS/JS给后台程序猿,变成相应的动态模板,上线部署。

那么我们来想象一下这样一个工作场景:

“小前是某公司的前端工程师,这一天设计师的设计稿发给了他,他通宵加班把美工稿实现,给到服务器端的工程师小后,小后把这些HTML变成对应的PHP模板文件,第二天上线部署,完成工作。

小前很高兴,小后很高兴,每个人都很高兴。”

一切都很顺利,有什么不对呢?让我把故事接着往下说:

“第二天,产品经理跑来找小前,告诉小前,他觉得网站的设计不太好,要改一下页面的结构。改结构对于一个专业的前端工程师来说实在是很简单,于是小前很快把HTML/CSS/JS写好,再次给到小后。小后再次把这些HTML变成对应的模板,上线部署。

小前很高兴,产品经理很高兴,但是小后不高兴了。”

“为什么每次改一点前端的结构,甚至加一个HTML标签都要来找我?!!!”小后很不爽。

问题出在哪里呢?

蔬菜供应商(服务器)不仅要卖菜(数据流)给饭店(前端),还要把这些菜烹饪好(用数据生成HTML),端给顾客,而实际开饭店的人(前端)只需要把做菜的流程图(设计好的HTML)给供应商。


在上面这个传统的架构里,后台的责任不仅仅是管理数据库、动态地输出响应的数据流,还有一项很重要的任务:负责生成视图(也就是HTML页面结构),用户看到的所有HTML标签,都是服务器动态生成的,一旦HTML的结构发生变化,后台也要改变。

但这一项任务其实是前端的责任,不是么?前端就应该负责网站的页面、与用户的一切交互,而后台应该只是一个数据接口,管理好数据库,输出对应的数据就行了,视图这个任务实在不应该让后台来管。

这里写图片描述

于是我们出现了诸如angularJS、backbone、reactJS这样的框架,很多人不能理解这些框架究竟要干啥,我们来举个第二个例子:

假设我们微博里有一个列表,看起来像这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<ul>
<li>微博内容1</li>
<li>作者1</li>
</ul>

<ul>
<li>微博内容2</li>
<li>作者2</li>
</ul>

<ul>
<li>微博内容3</li>
<li>作者3</li>
</ul>

其中“微博内容”和“作者”就是所谓的数据流。

我们暂且不考虑这个列表的CSS样式,在一个传统的架构里,http响应回来的数据是这样的(和实际的HTML一样):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<ul>
<li>微博内容1</li>
<li>作者1</li>
</ul>

<ul>
<li>微博内容2</li>
<li>作者2</li>
</ul>

<ul>
<li>微博内容3</li>
<li>作者3</li>
</ul>

但是如果使用了angularJS这样的框架,后台响应的数据大概是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
1:{
content:"微博内容1",
author:"作者1"
},


2:{
content:"微博内容2",
author:"作者2"
},


3:{
content:"微博内容3",
author:"作者3"
},

}

然后angularJS会把这个数据填充进页面里面。如果还需要再看几条微博,那么只需要再一次发起AJAX,获取一个和上面同样格式的JSON,然后解析、填入页面。

这两者有什么区别呢?

所谓的“数据流”,就应该只有数据,而具体的样式、结构、交互逻辑,都应该放到前端来实现,后台只提供数据。显然后一种方法把数据抽象出来,用JSON的方式封装好给到前端,此时前端的责任就是把这些数据变成可视的页面,前后端实现解耦。

这里写图片描述

前后端解耦使得后台服务器变成了一个抽象的数据提供者,而一切和视图、逻辑有关系的业务都放到了前端上来实现,这个时候,前端开发不再只是“画页面”、“写CSS、JS”,而是变成了一种和iOS APP、Android APP开发差别不大的Web APP开发,页面越来越像一个小小的app,服务器后台只提供相应的数据接口。


尾声

随着Web APP开发的兴起,Javascript这种并不适合大规模开发的脚本语言为了适应开发的需求,出现了很多开发模式、模块管理工具、自动化工具,随着nodeJS的快速发展JS更是延伸到了服务器端,未来ECMA6script标准的推广可以进一步让JS适应如今的大规模开发,这就是为何前端开发现在如此火热如此缺人的原因,或许这就是Web的未来?