Http Keep-Alive seems to be massively misunderstood. Here’s a short description of how it works, under both 1.0 and 1.1

HTTP/1.0

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.

Not reliable

HTTP is a stateless protocol – this means that every request is independent of every other. Keep alive doesn’t change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that theconnection is being closed. So keepalive is something you should not write your application to rely upon.

KeepAlive and POST

The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters. It also states that “certain” browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there’s no way to know how a server will handle it without testing.

https://tools.ietf.org/html/rfc7230#appendix-A.1.2

A.1.2. Keep-Alive Connections

   In HTTP/1.0, each connection is established by the client prior to
   the request and closed by the server after sending the response.
   However, some implementations implement the explicitly negotiated
   ("Keep-Alive") version of persistent connections described in Section
   19.7.1 of [RFC2068].

   Some clients and servers might wish to be compatible with these
   previous approaches to persistent connections, by explicitly
   negotiating for them with a "Connection: keep-alive" request header
   field.  However, some experimental implementations of HTTP/1.0
   persistent connections are faulty; for example, if an HTTP/1.0 proxy
   server doesn't understand Connection, it will erroneously forward
   that header field to the next inbound server, which would result in a
   hung connection.

   One attempted solution was the introduction of a Proxy-Connection
   header field, targeted specifically at proxies.  In practice, this
   was also unworkable, because proxies are often deployed in multiple
   layers, bringing about the same problem discussed above.

   As a result, clients are encouraged not to send the Proxy-Connection
   header field in any requests.

   Clients are also encouraged to consider the use of Connection:
   keep-alive in requests carefully; while they can enable persistent
   connections with HTTP/1.0 servers, clients using them will need to
   monitor the connection for "hung" requests (which indicate that the
   client ought stop sending the header field), and this mechanism ought
   not be used by clients at all when a proxy is being used.

来自：https://www.jianshu.com/p/dc0912de2ad0

一、HTTP的历史

由于目前的网络发展进度，http1.1  基本还是主流，http2.0 只是对 http1.1 进行了帧封装，里面的请求报文格式 都没有变化。

早在HTTP建立之初，主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说，我们所写的HTML页面将要放在我们的web服务器上，用户端通过浏览器访问url地址来获取网页的显示内容，但是到了WEB2.0以来，我们的页面变得复杂，不仅仅单纯的是一些简单的文字和图片，同时我们的HTML页面有了CSS，Javascript，来丰富我们的页面展示，当ajax的出现，我们又多了一种向服务器端获取数据的方法，这些其实都是基于HTTP协议的。同样到了移动互联网时代，我们页面可以跑在手机端浏览器里面，但是和PC相比，手机端的网络情况更加复杂，这使得我们开始了不得不对HTTP进行深入理解并不断优化过程中。

二、HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个：带宽和延迟。

• 带宽：如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。
• 延迟：
• 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
• DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
• 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

三、HTTP1.0

支持长连接（但默认还是使用短连接），参看web概述-http发展简史简明版

HTTP 协议老的标准是HTTP/1.0，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的图像标签后，浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。显 然，访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。

同时，带宽和延迟也是影响一个网络请求的重要因素。在网络基础建设已经使得带宽得到极大的提升的当下，大部分时候都是延迟在于响应速度。基于此会发现，http1.0被抱怨最多的就是连接无法复用，和head of line blocking这两个问题。理解这两个问题有一个十分重要的前提：客户端是依据域名来向服务器建立连接，一般PC端浏览器会针对单个域名的server同时建立6～8个连接，手机端的连接数则一般控制在4～6个。显然连接数并不是越多越好，资源开销和整体延迟都会随之增大。连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。head of line blocking会导致带宽无法被充分利用，以及后续健康请求被阻塞。

head of line blocking(holb)会导致健康的请求会被不健康的请求影响，而且这种体验的损耗受网络环境影响，出现随机且难以监控。为了解决holb带来的延迟，协议设计者设计了一种新的pipelining机制。pipelining只能适用于http1.1,而且由于使用苛刻，很多浏览器厂商并不支持。

四、HTTP1.1

为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。

在http1.1，request和reponse头中都有可能出现一个connection的头，此header的含义是当client和server通信时对于长链接如何进行处理。
在http1.1中，client和server都是默认对方支持长链接的， 如果client使用http1.1协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

HTTP 1.1在继承了HTTP 1.0优点的基础上，也克服了HTTP 1.0的性能问题。HTTP 1.1通过增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能。如，HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。HTTP/1.0不支持文件断点续传，<code>RANGE:bytes</code>是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。<code>RANGE:bytes=XXXX</code>表示要求服务器从文件XXXX字节处开始传送，这就是我们平时所说的断点续传！

五、HTTP/1.1和 HTTP/1.0 的区别：

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

1. ** 缓存处理**，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

Pipelining介绍：（来自维基百科）

（整体上还是先进先出，如果第一个响应没有出现，就一直等了）

Schema of non-pipelined vs. pipelined connection.

HTTP管线化（英语：HTTP pipelining）是将多个HTTP请求（request）整批提交的技术，而在发送过程中不需先等待服务端的回应。

请求结果管线化使得 HTML 网页加载时间动态提升，特别是在具体有高延迟的连接环境下，如卫星上网。在宽带连接中，加速不是那么显著的，因为需要服务器端应用 HTTP/1.1 协议:服务器端必须按照客户端的请求顺序恢复请求，这样整个连接还是先进先出的，队头阻塞（HOL blocking）可能会发生，造成延迟。未来的 HTTP/2.0 或者SPDY中的异步操作将会解决这个问题。因为它可能将多个 HTTP 请求填充在一个TCP数据包内，HTTP 管线化需要在网络上传输较少的 TCP 数据包，减少了网络负载。

管线化机制须通过永久连接（persistent connection）完成，并且只有 GET 和 HEAD 等要求可以进行管线化，非幂等的方法，例如POST将不会被管线化。连续的 GET 和 HEAD 请求总可以管线化的。一个连续的幂等请求，如 GET，HEAD，PUT，DELETE，是否可以被管线化取决于一连串请求是否依赖于其他的。此外，初次创建连接时也不应启动管线机制，因为对方（服务器）不一定支持 HTTP/1.1 版本的协议。

HTTP 管线化同时依赖于客户端和服务器的支持。遵守 HTTP/1.1 的服务器支持管线化。这并不是意味着服务器需要提供管线化的回复，而只是要求在收到管线化的请求时候不会失败。

六、SPDY：HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

1. 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
2. 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
5. 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：
   

   SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

七、HTTP2.0性能惊人

HTTP/2: the Future of the Internet 是 Akamai 公司建立的一个官方的演示，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片，从Load time 的对比可以看出 HTTP/2 在速度上的优势。

八、HTTP2.0：SPDY的升级版

HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
HTTP2.0和SPDY的区别：

1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
2. HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE

九、HTTP2.0和HTTP1.X相比的新特性

多路复用 (Multiplexing)

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，http://twimg.com，目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

二进制分帧

HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。

HTTP/2 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我调谐，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

这种单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；而且由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快。

首部压缩（Header Compression）

HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。

服务端推送（Server Push）

服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源，不过与之相比，服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。

十、HTTP2.0的升级改造

1. 前文说了HTTP2.0其实可以支持非HTTPS的，但是现在主流的浏览器像chrome，firefox表示还是只支持基于 TLS 部署的HTTP2.0协议，所以要想升级成HTTP2.0还是先升级HTTPS为好。
2. 当你的网站已经升级HTTPS之后，那么升级HTTP2.0就简单很多，如果你使用NGINX，只要在配置文件中启动相应的协议就可以了，可以参考NGINX白皮书，NGINX配置HTTP2.0官方指南。
3. 使用了HTTP2.0那么，原本的HTTP1.x怎么办，这个问题其实不用担心，HTTP2.0完全兼容HTTP1.x的语义，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容的。

参考：

Here we would like to talk about the major differences among Web 1.0, Web 2.0 and Web 3.0. To help you better understand, please watch this Youtube video, “Evolution Web 1.0, Web 2.0 to Web 3.0”.

Web 1.0
It is the “readable” phrase of the World Wide Web with flat data. In Web 1.0, there is only limited interaction between sites and web users. Web 1.0 is simply an information portal where users passively receive information without being given the opportunity to post reviews, comments, and feedback.

CSS3 标准

W3C 仍然在对 CSS3 规范进行开发。

不过，现代浏览器已经实现了相当多的 CSS3 属性。

以下为截至2017年，CSS3各模块的规范情况：

HTML的诞生于20世纪90年代初，1996年底，CSS第一版诞生，1998年5月，CSS2正式发布，2004年，CSS2.1发布，2002-2010年，陆续发布部分css3新增属性。

CSS1 中定义了网页的基本属性：字体、颜色、基本选择器等。

CSS2中在CSS1的基础上添加了高级功能，浮动和定位、高级选择器等(子选择器、相邻选择器、通用选择器)。

CSS3遵循的是模块化开发。发布时间并不是一个时间点，而是一个时间段。

一、css选择器回顾：

（1）通用选择器：*  选择到所有的元素；
（2）选择子元素：> 选择到元素的直接后代
（3）相邻兄弟选择器：+ 选择到紧随目标元素后的第一个元素
（3）普通兄弟选择器：~ 选择到紧随其后的所有兄弟元素
（4）伪元素选择器：
::first-line 匹配文本块的首行
::first-letter 选择文本块的首字母
（5）伪类选择器：
:before,:after在元素内容前面、后面添加内容(相当于行内元素)

例如：选中ul标签后边的第一个div相邻标签。

ul.list +div.box

二、css3结构选择器：

（1）:nth-child 选择指定索引处的子元素
（2）nth-child(n) 父元素下的第n个子元素
（3）nth-child(odd)奇数子元素(同nth-child(2n-1))
（4）nth-child(even)偶数子元素(同nth-child(2n))
（5）nth-child(an+b)公式
（6）:nth-last-child(n) 倒数第n个子元素
（7）:nth-of-type(n) 父元素下的第n个指定类型的子元素
（7）:nth-last-of-type 父元素下的倒数第n个指定类型的子元素
（8）:first-child 选择父元素下的第一个子元素
（9）:last-child 选择父元素下的最后一个子元素
（10）:only-child 选择父元素下唯一的子元素
（11）:only-of-type选择父元素下指定类型的唯一子元素
（12）:root 选择文档的根目录，返回html</span>

例如：选中ul标签里边的第三个li子元素。

ul li:nth-child(3)

三、css3属性选择器：

（1）E[attr] 属性名，不确定具体属性值
（2）E[attr="value"] 指定属性名，并指定其对应属性值
（3）E[attr ~="value"] 指定属性名，其具有多个属性值空格隔开，并包含  value值
（4）E[attr ^= "value"] 指定属性名，属性值以value开头
（5）E[attr $="value"] 指定属性名，属性值以value结束
（6）E[attr *="value"] 指定了属性名，属性值中包含了value
（7）E[attr |= "value"] 指定属性名，属性值以value-开头

例如：选中所有的class类并且以类型是指定的value的div元素，让他的背景颜色变成红色。

div[class="value"]{background:red}

四、css3伪类选择器：

1、UI伪类选择器：

（1）:enabled 选择启用状态元素
（2）:disabled 选择禁用状态元素
（3）:checked 选择被选中的input元素（单选按钮或复选框）
（4）:default 选择默认元素
（5）:valid、invalid 根据输入验证选择有效或无效的input元素
（6）:in-range、out-of-range 选择指定范围之内或者之外受限的元素
（7）:repuired、optional 根据是否允许:required属性选择input元素

例如：有3个input复选框，其中第一个被选中了，它的checked=”checked”，其他两个没有，那么让这个被选中的复选框的宽高都变成50px。

input:checked{width:50px;height:50px}

2、动态伪类选择器：

 （1）:link 选择链接元素
 （2）:visited 选择用户以访问的元素
 （3）:hover 鼠标悬停其上的元素
 （4）:ative 鼠标点击时触发的事件
 （5）:focus 当前获取焦点的元素

例如：滑过一个div的时候，让它的背景颜色变成红色。

div:hover{background:red}

3、其他伪类选择器：

（1）:not(<选择器>) 对括号内选择器的选择取反
（2）:lang(<目标语言>) 基于lang全局属性的元素
（3）:target url片段标识符指向的元素
（4）:empty选择内容为空的元素
（5）:selection 鼠标光标选择元素内容

例如：有3个div，前两个都有内容，第三个是空的，什么内容都没有，那么让这个空的div的背景颜色变成橙色。

div:empty{background:orange}

来自：https://www.tianmaying.com/blog/8ab3eda84daf4e54014daf68ff09000b

“1994年，网景公司（Netscape）发布了Navigator浏览器0.9版。这是历史上第一个比较成熟的网络浏览器，轰动一时。但是，这个版本的浏览器只能用来浏览，不具备与访问者互动的能力。……网景公司急需一种网页脚本语言，使得浏览器可以与网页互动。”

网页脚本语言到底是什么语言？网景公司当时有两个选择：一个是采用现有的语言，比如Perl、Python、Tcl、Scheme等等，允许它们直接嵌入网页；另一个是发明一种全新的语言。

这两个选择各有利弊。第一个选择，有利于充分利用现有代码和程序员资源，推广起来比较容易；第二个选择，有利于开发出完全适用的语言，实现起来比较容易。

到底采用哪一个选择，网景公司内部争执不下，管理层一时难以下定决心。

3.

就在这时，发生了另外一件大事：1995年Sun公司将Oak语言改名为Java，正式向市场推出。

Sun公司大肆宣传，许诺这种语言可以”一次编写，到处运行”（Write Once, Run Anywhere），它看上去很可能成为未来的主宰。

网景公司动了心，决定与Sun公司结成联盟。它不仅允许Java程序以applet（小程序）的形式，直接在浏览器中运行；甚至还考虑直接将Java作为脚本语言嵌入网页，只是因为这样会使HTML网页过于复杂，后来才不得不放弃。

总之，当时的形势就是，网景公司的整个管理层，都是Java语言的信徒，Sun公司完全介入网页脚本语言的决策。因此，Javascript后来就是网景和Sun两家公司一起携手推向市场的，这种语言被命名为”Java+script”并不是偶然的。

4.

此时，34岁的系统程序员Brendan Eich登场了。1995年4月，网景公司录用了他。

Brendan Eich的主要方向和兴趣是函数式编程，网景公司招聘他的目的，是研究将Scheme语言作为网页脚本语言的可能性。Brendan Eich本人也是这样想的，以为进入新公司后，会主要与Scheme语言打交道。

仅仅一个月之后，1995年5月，网景公司做出决策，未来的网页脚本语言必须”看上去与Java足够相似”，但是比Java简单，使得非专业的网页作者也能很快上手。这个决策实际上将Perl、Python、Tcl、Scheme等非面向对象编程的语言都排除在外了。

Brendan Eich被指定为这种”简化版Java语言”的设计师。

5.

但是，他对Java一点兴趣也没有。为了应付公司安排的任务，他只用10天时间就把Javascript设计出来了。

由于设计时间太短，语言的一些细节考虑得不够严谨，导致后来很长一段时间，Javascript写出来的程序混乱不堪。如果Brendan Eich预见到，未来这种语言会成为互联网第一大语言，全世界有几百万学习者，他会不会多花一点时间呢？

总的来说，他的设计思路是这样的：

（1）借鉴C语言的基本语法；

（2）借鉴Java语言的数据类型和内存管理；

（3）借鉴Scheme语言，将函数提升到”第一等公民”（first class）的地位；

（4）借鉴Self语言，使用基于原型（prototype）的继承机制。

所以，Javascript语言实际上是两种语言风格的混合产物—-（简化的）函数式编程+（简化的）面向对象编程。这是由Brendan Eich（函数式编程）与网景公司（面向对象编程）共同决定的。

6.

多年以后，Brendan Eich还是看不起Java。

他说：

“Java（对Javascript）的影响，主要是把数据分成基本类型（primitive）和对象类型（object）两种，比如字符串和字符串对象，以及引入了Y2K问题。这真是不幸啊。”

把基本数据类型包装成对象，这样做是否可取，这里暂且不论。Y2K问题则是直接与Java有关。根据设想，Date.getYear()返回的应该是年份的最后两位：

　　var date1 = new Date(1999,0,1);

var year1 = date1.getYear();

alert(year1); // 99

但是实际上，对于2000年，它返回的是100！

　　var date2 = new Date(2000,0,1);

var year2 = date2.getYear();

alert(year2); // 100

如果用这个函数生成年份，某些网页可能出现”19100″这样的结果。这个问题完全来源于Java，因为Javascript的日期类直接采用了java.util.Date函数库。Brendan Eich显然很不满意这个结果，这导致后来不得不添加了一个返回四位数年份的Date.getFullYear()函数。

如果不是公司的决策，Brendan Eich绝不可能把Java作为Javascript设计的原型。作为设计者，他一点也不喜欢自己的这个作品：

“与其说我爱Javascript，不如说我恨它。它是C语言和Self语言一夜情的产物。十八世纪英国文学家约翰逊博士说得好：’它的优秀之处并非原创，它的原创之处并不优秀。’（the part that is good is not original, and the part that is original is not good.）”

不管怎么样，javascript诞生了，它的设计之初其实很简单，就是为了解决浏览器上表单提交的人机交互，而作为一种脚本语言，它天生的设计缺陷为后来的大型应用程序开发，留下了隐患。

石器时代

大约10年前（2007年左右），前端处在基于table（表格）布局的时代，有一家公司很出名，有三款产品，大家耳熟能详：

没错，就是Macromedia（后被adobe公司收购）和网页三剑客，所见即所得的编辑方式让开发者更关注于展示效果，而不去关注代码层的实现（这个时候语义化才刚刚兴起，table占据上风），那个时候没有前端后端之分，web工程师真的是“全栈”，写的了后端，套的了表格，查的了数据库，写的了js，js主要承载的作用是网页特效（对，如果有前端的话，其实也是写点特效），例如特效排行榜第一的“跑马灯”效果，类似这样的代码:

function scrollit(seed) {
		var m1 = "HI：你 好! ";
		var m2 = "欢迎访问一醉的知乎专栏";
		var m3 = "请 多 提 意 见，谢 谢!";
		var m4 = "/";
		var msg = m1 + m2 + m3 + m4;
		var out = " ";
		var c = 1;
		if (seed > 100) {
			seed--;
			cmd = "scrollit(" + seed + ")";
			timerTwo = window.setTimeout(cmd, 100);
		}
		else if (seed <= 100 && seed > 0) {
			for (c = 0; c < seed; c++) {
				out += " ";
			}
			out += msg;
			seed--;
			window.status = out;
			cmd = "scrollit(" + seed + ")";
			timerTwo = window.setTimeout(cmd, 100);
		}
		else if (seed <= 0) {
			if (-seed < msg.length) {
				out += msg.substring(-seed, msg.length);
				seed--;
				window.status = out;
				cmd = "scrollit(" + seed + ")";
				timerTwo = window.setTimeout(cmd, 100);
			}
			else {
				window.status = " ";
				timerTwo = window.setTimeout("scrollit(100)", 75);
			}
		}
	}

这样的代码，一般以内连方式放在页面的任何地方，就像一块一块的补丁，看了让人难受，不过还好，这个阶段很快就结束了（也许很多很烂的政府网站还在用table布局也说不定）。

铜器时代

1.2001年发布的ie6当时是世界上最先进的浏览器
2.2004年2月9日，Mozilla Firebird改称“Mozilla Firefox”，简称“Firefox”
3.在2006年年尾，微软发布了rebranded代号的Internet Explorer 7
4.北京时间2008年3月6日，微软发布了InternetExplorer 8的第一个公开测试版本(beta1)
5.Chrome beta测试版本在2008年9月2日发布

铜器时代，是令人悲伤的一个阶段，因为这个阶段终于有前端开发工程师这个职位了，但是主要工作居然是处理浏览器兼容性问题，下边是那个时代的浏览器情况，虽然ie6在2001年就发布了，但是它持续的时间太长，2012年貌似淘宝才不再兼容ie6（具体时间有待求证），大部分的时间，前端同学要兼容ie6,ie7,ie8,ie9,FF,chrome,safari…

大部分的css代码里边会有这样的熟悉的hack存在:

.hack{  
    background-color:red; /* All browsers */  
    background-color:blue !important;/* All browsers but IE6 */  
    *background-color:black; /* IE6, IE7 */  
    +background-color:yellow;/* IE6, IE7*/  
    background-color:gray\9; /* IE6, IE7, IE8, IE9, IE10 */  
    background-color:purple\0; /* IE8, IE9, IE10 */  
    background-color:orange\9\0;/*IE9, IE10*/  
    _background-color:green; /* Only works in IE6 */  
    *+background-color:pink; /*  WARNING: Only works in IE7 ? Is it right? */  
} 

那个时候的js代码已经不再内连在页面代码里，转而以文件的方式引入，类似这样：

<script src=“../your/code/a.js”></script>
<script src=“../your/code/b.js”></script>
<script src=“../your/code/c.js”></script>
<script src=“../your/code/d.js”></script>

$('J_Hook').html('haha');

<script src=“js/jquery.min.js”></script>
<script src="js/require.js" data-main="js/main"></script>

<!—— your dom element ——>
<div class=‘J_RenderCont’></div>

<!—— your javascript source ——>
<script src=“js/jquery.min.js”></script>
<script src="js/require.js" data-main="js/main"></script>

前端发展简史

起源

• 1990 HTML 草创

1990 年，Tim Berners Lee 以超文本语言 HTML 为基础在 NeXT 电脑上发明了最原始的 Web 浏览器（“WorldWideWeb.app”）后来改名为Nexus,同时发明了第一个web服务器（“httpd“字样）。截至1990年底，第一个网页投放在开放的互联网上。

• 1991 HTML1.0规范 发布

HTML 1.0首次亮相为SGML的混合体，其中包括“href”标签，将已经被广泛接受的文本标记语言与链接文档的能力结合起来。
•原始版本仅包含20个元素，其中13个元素仍然是HTML 4.01的一部分。

1991年8月6日，Tim Berners Lee在alt.hypertext新闻组贴出了一份关于World Wide Web的简单摘要: “WorldWideWeb（WWW）项目旨在允许在任何地方对任何信息进行全部链接。[…] WWW项目开始允许高能物理学家共享数据，新闻和文档。 我们非常有兴趣将网络传播到其他领域，并为其他数据提供网关服务器。 合作者欢迎！“
这标志了Web页面在Internet上的首次登场。最早Web主要被一帮科学家们用来共享和传递信息，全世界的Web服务器也就几十台。

与此同时，美国国家超算应用中心（National Center for Supercomputer Applications）对此表现出了浓厚的兴趣，并开发了名为 Mosaic 的浏览器，于 1993 年 4 月进行了发布。Mosaic 使得web开始流行起来，这便是曾经大名鼎鼎的Netscape Navigator的前身。

1993年 Tim Berners Lee建立了万维网联盟（World Wide Web Consortium，W3C），负责Web相关标准的制定。浏览器的普及和W3C的推动，使得Web上可以访问的资源逐渐丰富起来。这个时候Web的主要功能就是浏览器向服务器请求静态HTML信息。95年的时候马云在美国看到了互联网，更准确的说他其实看到的就是Web，阿里早先做的黄页也就是把企业信息通过进行HTML展示的Web应用。

1994 年 5 月，第一届万维网大会在日内瓦召开。

• 1994.7 HTML 2.0 规范发布

HTML 2.0成为HTML的第一套官方标准 – 所有浏览器的测试基础标准，直到HTML 3.2。
•在Web爆炸期间，HTML 2.0被用作基准。
•1993年发布的其他浏览器包括Cello，Arena，Lynx，tkWWW和Mosaic。
•后来更名为Netscape Communications的Mosaic Communications根据美国国家超级计算应用中心（NCSA）Mosaic浏览器发布了Netscape，该浏览器是第一款带图形界面的商业网页浏览器。
• 亮点：根据Wired的Gary Wolfe的说法，Mosaic “正在成为世界标准界面 。”

1994 年 9 月，因特网工程任务组（Internet Engineering Task Force）设立了 HTML 工作组。

1994 年 11 月，Mosaic 浏览器的开发人员创建了网景公司（Netscape Communications Corp.），并发布了 Mosaic Netscape 1.0 beta 浏览器，后改名为 Navigator。

• 1994 万维网联盟（World Wide Web Consortium）成立，简称 W3C

1994 年底，由Tim Berners Lee 牵头的万维网联盟（World Wide Web Consortium）成立，这标志着万维网的正式诞生。

此时的网页以 HTML 为主，是纯静态的网页，网页是“只读”的，信息流只能通过服务器到客户端单向流通，由此世界进入了 Web 1.0 时代。

• 1995 网景推出 JavaScript

1995 年，网景工程师 Brendan Eich 花了10天时间设计了 JavaScript 语言。起初这种脚本语言叫做 Mocha，后改名 LiveScript，后来为了借助 Java 语言创造良好的营销效果最终改名为 JavaScript。网景公司把这种脚本语言嵌入到了 Navigator 2.0 之中，使其能在浏览器中运行。

与此相对的是，1996 年，微软发布了 VBScript 和 JScript。JScript 是对 JavaScript 进行逆向工程的实现，并内置于 Internet Explorer 3 中。但是 JavaScript 与 JScript 两种语言的实现存在差别，这导致了程序员开发的网页不能同时兼容 Navigator 和 Internet Explorer 浏览器。 Internet Explorer 开始抢夺 Netscape 的市场份额，这导致了第一次浏览器战争。

1996年 

•HTML现在支持表格，可以更好地控制表格信息的显示
•HTML还支持“客户端图像映射”文档元素，该元素允许单击图像的不同区域以引用不同的网络资源，如统一标识符（URI）所指定的。
•第一个CSS规范成为官方的W3C推荐标准，虽然已经完成，但是在任何Web浏览器达到接近完全规范的实现之前已经超过3年。
• 亮点： IE 3.0发布的功能等同于Netscape，它提供了脚本支持和市场上的第一个商业CSS实现。

第一次浏览器战争

1996 年 11 月，为了确保 JavaScript 的市场领导地位，网景将 JavaScript 提交到欧洲计算机制造商协会（European Computer Manufacturers Association）以便将其进行国际标准化。

• 1996.12 W3C 推出了 CSS 1.0 规范

1997年
•经过研究人员的激烈争论，研究人员认为文本属性（如背景颜色和纹理，字体大小和字体）正在将HTML从根部移开，以便组织而不是修饰文档以供共享; 并且在IE和Netscape之间的浏览器战争中，HTML 3.2（代码名称WILBUR）被批准。
•获得批准的让步包括Internet Explorer阵营和Netscape阵营同意杀死他们专有的<marquee>和<​​blink>属性，这些属性负责我们知道并讨厌的引人注目，闪烁的文本。
•这是网页中广泛过度使用帧的时间，这是互联网上最糟糕的失误之一，仅次于自动播放midi文件。
• 突出显示：已集成到Microsoft Windows中的IE 4.0版本不鼓励用户使用竞争的浏览器，因为默认情况下IE是在那里。

• 1997.1 HTML3.2 作为 W3C 推荐标准发布
• 1997.6 ECMA 以 JavaScript 语言为基础制定了 ECMAScript 1.0 标准规范

1997 年 6 月，ECMA 以 JavaScript 语言为基础制定了 ECMAScript 标准规范 ECMA-262。JavaScript 是 ECMAScript 规范最著名的实现之一，除此之外，ActionScript 和 JScript 也都是 ECMAScript 规范的实现语言。自此，浏览器厂商都开始逐步实现 ECMAScript 规范。

1998年
•Cougar是成为HTML 4.0的代码名称，在1997年底发布为推荐，最终被批准为HTML 4.01。
•此版本包含层叠样式表（CSS），这是控制表示元素（如颜色，字体和背景）的更简单方法。 (对啊 ，简单来说  CSS1.0 是 table td布局，CSS2.0 是div li布局，学校里压根都没有提到  )
• 亮点： Netscape在“浏览器战争”中被击败，被美国在线以42亿美元收购。

• 1997.12 HTML 4.0 规范发布
• 1998 W3C 推出了 CSS 2.0 规范
• 1998.6 ECMAScript 2 规范发布

1998 年 6 月，ECMAScript 2 规范发布，并通过 ISO 生成了正式的国际标准 ISO/IEC 16262 。

• 1999.12 ECMAScript 3 规范发布

1999 年 12 月，ECMAScript 3 规范发布，在此后的十年间，ECMAScript 规范基本没有发生变动。ECMAScript 3 成为当今主流浏览器最广泛使用和实现的语言规范基础。

第一次浏览器战争以 IE 浏览器完胜 Netscape 而结束，IE 开始统领浏览器市场，份额的最高峰达到 2002 年的 96%。随着第一轮大战的结束，浏览器的创新也随之减少。

2000
•HTML和XML联手成为XHTML，挑选严格的XML代码结构来执行更清晰的代码，但由于它不向后兼容，因此需要重写代码。
尽管XML是标准的，但大多数浏览器原谅了这一点，并且仍然允许使用潦草的代码，大写代码和不正确的封闭标签，以致难以广泛采用更严格的XML代码。
•问：为什么XHTML鸟无效？ 答：因为它没有正确嵌套。
• 突出显示： IE是占主导地位的浏览器，在2002年达到网络浏览器使用份额的约96％的峰值，超过Netscape的高峰。

XHTML

• 1999 W3C 发布 HTML 4.01 标准，同年微软推出用于异步数据传输的 ActiveX，随即各大浏览器厂商模仿实现了 XMLHttpRequest（AJAX 雏形）。
• 2000: W3C 采用了一个大胆的计划，把 XML 引入 HTML，XHTML1.0 作为 W3C 推荐标准发布
• 2001.5 W3C 推出了 CSS 3.0 规范草案
• 2002-2006 XHTML 2.0 最终放弃
• 2009 W3C 宣布 XHTML2.0 不再继续，宣告死亡

2002年
•许多人对杂乱的编码实践表 （table布局）示批评，（div布局）无表设计的想法开始增长。
•术语“无表设计”意味着使用CSS而不是布局表来定位页面上的HTML元素。
•在网页中显示表格信息时，HTML表格仍然有其合法的位置。
•这也是分享和交换特别内容（如Weblogs和RSS）的新想法迅速获得采用并被命名为“Web 2.0”的时候。
• 亮点：第一次浏览器大战结束，IE浏览器没有对其市场份额进行严重的竞争 – 这为Web浏览器的快速创新带来了一段时间。

（

动态页面的崛起

JavaScript 诞生之后，可以用来更改前端 DOM 的样式，实现一些类似于时钟之类的小功能。那时候的JavaScript 仅限于此，大部分的前端界面还很简单，显示的都是纯静态的文本和图片。这种静态页面不能读取后台数据库中的数据，为了使得 Web 更加充满活力，以 PHP、JSP、ASP.NET 为代表的动态页面技术相继诞生。

PHP（PHP：Hypertext Preprocessor）最初是由 Rasmus Lerdorf 在 1995 年开始开发的，现在PHP 的标准由 PHP Group 维护。PHP 是一种开源的通用计算机脚本语言，尤其适用于网络开发并可嵌入 HTML 中使用。PHP 的语法借鉴吸收 C 语言、Java 和 Perl 等流行计算机语言的特点，易于一般程序员学习。PHP 的主要目标是允许网络开发人员快速编写动态页面。

JSP（JavaServer Pages）是由 Sun 公司倡导和许多公司参与共同创建的一种使软件开发者可以响应客户端请求，从而动态生成 HTML、XML 或其他格式文档的 Web 网页的技术标准。JSP 技术是以 Java 语言为基础的。1999 年，JSP 1.2 规范随着 J2EE 1.2 发布。

ASP（Active Server Pages）1.0 在 1996 年随着 IIS 3.0 而发布。2002 年，ASP.NET 发布，用于替代 ASP。

随着这些动态服务器页面技术的出现，页面不再是静止的，页面可以获取服务器数据信息并不断更新。以 Google 为代表的搜索引擎以及各种论坛相继出现，使得 Web 充满了活力。

随着动态页面技术的不断发展，后台代码变得庞大臃肿，后端逻辑也越来越复杂，逐渐难以维护。此时，后端的各种 MVC 框架逐渐发展起来，以 JSP 为例，Struct、Spring 等框架层出不穷。

从 Web 诞生至 2005 年，一直处于后端重、前端轻的状态。

2005年
•Ajax是一种可追溯到IE 4的iFrame的技术，它使网页更快地请求和更新动态页面内容，以响应像桌面应用程序，如Rackspace Email和Gmail等云应用程序以及社交媒体网站Digg，Facebook和Twitter; 和在线内容管理系统（CMS），如WordPress。
•2005年，Adaptive Path使用Ajax作为与客户谈论Asynchronous JavaScript + CSS + DOM + XMLHttpRequest的更简单方法
• 突出显示：浏览器大战再次启动，Mozilla在2004年发布Firefox 1.0; 从那以后，Firefox继续获得越来越多的浏览器市场份额。

• AJAX 的流行

在 Web 最初发展的阶段，前端页面要想获取后台信息需要刷新整个页面，这是很糟糕的用户体验。

Google 分别在 2004 年和 2005 年先后发布了两款重量级的 Web 产品：Gmail 和 Google Map。这两款 Web 产品都大量使用了 AJAX 技术，不需要刷新页面就可以使得前端与服务器进行网络通信，这虽然在当今看来是理所应当的，但是在十几年前AJAX却是一项革命性的技术，颠覆了用户体验。

随着 AJAX 的流行，越来越多的网站使用 AJAX 动态获取数据，这使得动态网页内容变成可能，像 Facebook 这样的社交网络开始变得繁荣起来，前端一时间呈现出了欣欣向荣的局面。

AJAX 使得浏览器客户端可以更方便地向服务器发送数据信息，这促进了 Web 2.0 的发展。

Google Trend: AJAX 从 2005 年开始得到开发人员的广泛关注。

• 2006 XMLHttpRequest 被 W3C 正式纳入标准。

第二次浏览器大战

• 前端兼容性框架的出现

IE 在第一次浏览器大战中击败 Netscape 赢得胜利，垄断了浏览器市场。作为独裁者，IE 并不遵循 W3C 的标准，IE 成了事实标准。

Netscape 于 1998 年被 AOL 收购前创建了 Mozilla 社区，Firefox 于 2004 年 11 月首次发布，并且 9 个月内下载量超过 6000 万，获取了巨大的成功，IE 的主导地位首次受到了挑战， Firefox 被认为是 Netscape 的精神续作。

之后 Firefox 浏览器一路奋起直追，逐渐蚕食 IE 市场份额，这引发了第二次浏览器战争。在 2008 年底时，Firefox 的市场份额达到了 25% 以上，IE 则跌至 65% 以下。

第二次浏览器战争中，随着以 Firefox 和 Opera 为首的 W3C 阵营与 IE 对抗程度的加剧，浏览器碎片化问题越来越严重，不同的浏览器执行不同的标准，对于开发人员来说这是一个恶梦。

为了解决浏览器兼容性问题，Dojo、jQuery、YUI、ExtJS、MooTools 等前端 Framework 相继诞生。前端开发人员用这些 Framework 频繁发送 AJAX 请求到后台，在得到数据后，再用这些 Framework 更新 DOM 树。

其中，jQuery 独领风骚，几乎成了所有网站的标配。Dojo、YUI、ExtJS 等提供了很多组件，这使得开发复杂的企业级 Web 应用成为可能。

Google Trend: 蓝色 jQuery，红色 Dojo，绿色 YUI，紫色 ExtJS，黄色 MooTools

HTML 5

1999年，W3C发布了 HTML 4.01 版本，在之后的几年，没有再发布更新的 Web 标准。随着Web的迅猛发展，旧的Web标准已不能满足 Web 应用的快速增长。

2004 年 6 月，Mozilla 基金会和 Opera 软件公司在万维网联盟（W3C）所主办的研讨会上提出了一份联合建议书，其中包括 Web Forms 2.0 的初步规范草案。建议举行一次投票，以表决 W3C 是否应该扩展 HTML 和 DOM，从而满足 Web 应用中的新需求。研讨会最后以 8 票赞成，14 票反对否决此建议，这引起一些人的不满，不久后，部分浏览器厂商宣布成立网页超文本技术工作小组（WHATWG），以继续推动该规范的开发工作，该组织再度提出 Web Applications 1.0 规范草案，后来这两种规范合并形成 HTML5。2007 年，获得 W3C 接纳，并成立了新的 HTML 工作团队。2008 年 1 月 22 日，第一份正式草案发布。

2008年
•由于缺乏对XHTML中丰富Web应用程序的关注，Web超文本应用技术（WHAT）工作组于2004年与Apple，Mozilla和Opera成员形成了这个协议，并在四年后发布了第一份HTML5草案。
•到2009年，XHTML开发团队进行反汇编，加入HTML5阵营。
•至少2022年前，HTML5不会成为标准，但Firefox和IE9已经支持其某些功能。 与大多数新版本的HTML一样，它的优势只会与其开发者和浏览器支持一样强大。
• 突出显示： Google发布适用于Windows的Chrome浏览器。 Chrome在09年10月份获得了3.6％的使用份额，并在Mac OS X和Linux测试版发布后迅速增长。

• 2008.12 Chrome 发布，JavaScript 引擎 V8

HTML5 草案发布不久，Google 在 2008 年 12 月发布了 Chrome 浏览器，加入了第二次浏览器大战当中。Chrome 使用了 Safari 开源的 WebKit 作为布局引擎，并且研发了高效的 JavaScript 引擎 V8。

尽管 HTML5 在网络开发人员中非常出名了，但是它成为主流媒体的一个话题是在 2010 年的 4 月，当时苹果公司的 CEO 乔布斯发表一篇题为“对 Flash 的思考”的文章，指出随着 HTML5 的发展，观看视频或其它内容时，Adobe Flash 将不再是必须的。这引发了开发人员间的争论，包括 HTML5 虽然提供了加强的功能，但开发人员必须考虑到不同浏览器对标准不同部分的支持程度的不同，以及 HTML5 和 Flash 间的功能差异。

2010
•2010年，史蒂夫乔布斯宣布苹果产品将不再支持Flash，原因包括其专有的代码和安全漏洞，并推动HTML5的音频和视频播放功能的发展成为众人关注的焦点。
•将Flash和HTML5结合为人们分享用户生成的视频提供了一个免费空间的YouTube在2005年推出后每天提供约20亿视频。
• 突出显示： StatCounter报告说，在统计单个浏览器版本时，Firefox 3.5是最流行的浏览器，IE 7和8其次。

在第二次浏览器大战中，各个浏览器厂商都以提升 JavaScript 运行效率和支持 HTML5 各种新特性为主要目标，促进了浏览器的良性竞争。在这一场战争中，Chrome 攻城略地，抢夺 IE 市场份额。2013 年，Chrome 超过 IE，成为市场份额最高的浏览器。2016 年，Chrome 占据了浏览器市场的半壁江山。

全球浏览器市场份额（2009-2017）

自 2008 年以来，浏览器中不断支持的 HTML5 新特性让开发者激动不已：WebWorker 可以让 JavaScript 运行在多线程中，WebSocket 可以实现前端与后台的双工通信，WebGL 可以创建 Web3D 网页游戏……

桌面浏览器对 HTML5 支持程度（2009-2017）

• 2009.12 ECMAScript 5.0 规范发布
• 2011.6 ECMAScript 5.1 规范发布
• 2012.10 微软发布 TypeScript 公开版

TypeScript 是一种由微软开发的自由和开源的编程语言。它是 JavaScript 的一个超集，而且本质上向这个语言添加了可选的静态类型和基于类的面向对象编程。

TypeScript 扩展了 JavaScript 的语法，所以任何现有的 JavaScript 程序可以不加改变的在 TypeScript 下工作。TypeScript 是为大型应用之开发而设计，而编译时它产生 JavaScript 以确保兼容性。

• 2013.6.19 TypeScript 0.9 正式版
• 2014.10.28 W3C 正式发布 HTML 5.0 推荐标准

2014 年 10 月 28 日，W3C 正式发布 HTML 5.0 推荐标准。

Node.js 的爆发

早在 1994 年，Netspace 就公布了其 Netspace Enterprise Server 中的一种服务器脚本实现，叫做 LiveWire，是最早的服务器端 JavaScript，甚至早于浏览器中的 JavaScript。对于这门图灵完备的语言，Netspace 很早就开始尝试将它用在后端。

微软在 1996 年发布的 IE 3.0 中内嵌了自己的 JScript语言，其兼容 JavaScript 语法。1997 年年初，微软在它的服务器 IIS 3.0 中也包含了 JScript，这就是我们在 ASP 中能使用的脚本语言。

1997 年，Netspace 为了用 Java 实现 JavaScript 而创建了 Rhino 项目，最终 Rhino 演变成一个基于 Java 实现的 JavaScript 引擎，由 Mozilla 维护并开源。Rhino 可以为 Java 应用程序提供脚本能力。2006 年 12 月，J2SE 6 将 Rhino 作为 Java 默认的脚本引擎。

SpiderMonkey 是 Mozilla 用 C/C++ 语言实现的一个 JavaScript 引擎，从 Firefox 3.5 开始作为 JavaScript 编译引擎，并被 CouchDB 等项目作为服务端脚本语言使用。

可以看到，JavaScript 最开始就能同时运行在前后端，但时在前后端的待遇却不尽相同。随着 Java、PHP、.Net 等服务器端技术的风靡，与前端浏览器中的 JavaScript 越来越流行相比，服务端 JavaScript 逐渐式微。

2008 年 Chrome 发布，其 JavaScript 引擎 V8 的高效执行引起了 Ryan Dahl 的注意。2009 年，Ryan 利用 Chrome 的 V8 引擎打造了基于事件循环的异步 I/O 框架 —— Node.js 诞生。

Node.js 具有以下特点：

• 基于事件循环的异步 I/O 框架，能够提高 I/O 吞吐量
• 单线程运行，能够避免了多线程变量同步的问题
• 使得 JavaScript 可以编写后台代码，前后端编程语言统一。

Node.js 的出现吸引了很多前端开发人员开始用 JavaScript 开发服务器代码，其异步编程风格也深受开发人员的喜爱。Node.js 的伟大不仅在于拓展了 JavaScript 在服务器端的无限可能，更重要的是它构建了一个庞大的生态系统。

2010 年 1 月，NPM 作为 Node.js 的包管理系统首次发布。开发人员可以按照 CommonJS 的规范编写 Node.js 模块，然后将其发布到 NPM 上面供其他开发人员使用。目前 NPM 具有 40 万左右的模块，是世界上最大的包模块管理系统。

2016 年常见包管理系统模块数量，NPM 高居榜首

Node.js 也催生了 node-webkit 等项目，用 JavaScript 开发跨平台的桌面软件也成为可能。Node.js 给开发人员带来了无穷的想象，JavaScript 大有一统天下的趋势。

前端 MV* 架构

随着 HTML5 的流行，前端不再是人们眼中的小玩意，以前在 C/S 中实现的桌面软件的功能逐步迁移到了前端，前端的代码逻辑逐渐变得复杂起来。

以前只用于后台的 MV* 等架构在前端逐渐使用起来，以下列举了部分常用的 MV* 框架。

随着这些 MV* 框架的出现，网页逐渐由 Web Site 演变成了 Web App，最终导致了复杂的单页应用（ Single Page Application）的出现。

移动 Web 和 Hybrid App

随着 iOS 和 Android 等智能手机的广泛使用，移动浏览器也逐步加强了对 HTML5 特性的支持力度。

移动浏览器对 HTML5 支持程度（2009-2017）

移动浏览器的发展，导致了流量入口逐渐从 PC 分流到移动平台，这是 Web 发展的新机遇。移动 Web 面临着更大的碎片化和兼容性问题，jQuery Mobile、Sencha Touch、Framework7、Ionic 等移动 Web 框架也随之出现。

相比于 Native App，移动 Web 开发成本低、跨平台、发布周期短的优势愈发明显，但是 Native App的性能和 UI 体验要远胜于移动 Web。移动 Web 与 Native App 孰优孰劣的争论愈演愈烈，在无数开发者的实践中，人们发现两者不是替代关系，而是应该将两者结合起来，取长补短，Hybrid 技术逐渐得到认同。

Hybrid 技术指的是利用 Web 开发技术，调用 Native 相关 API，实现移动与 Web 二者的有机结合，既能体现 Web 开发周期短的优势，又能为用户提供 Native 体验。

根据实现原理，Hybrid 技术可以分为两大类：

1. 将 HTML 5 的代码放到 Native App 的 WebView 控件中运行，WebView 为 Web 提供宿主环境，JavaScript 代码通过 WebView 调用 Native API。典型代表有 PhoneGap(Cordova) 以及国内的 AppCan 等。
2. 将 HTML 5 代码针对不同平台编译成不同的原生应用，实现了 Web 开发，Native 部署。这一类的典型代表有 Titanium 和 NativeScript。

Hybrid 一系列技术中很难找出一种方案适应所有应用场景，我们需要根据自身需求对不同技术进行筛选与整合。

ECMAScript 6

JavaScript 语言是 ECMAScript 标准的一种实现，截止 2017 年 2 月，ECMAScript 一共发布了 7 个版本。

1997 年 6 月， ECMAScript 1.0 标准发布。

1998 年 6 月，ECMAScript 2.0 发布。

1999 年 12 月，ECMAScript 3.0 发布。

2007 年 10 月，Mozilla 主张的 ECMAScript 4.0 版草案发布，对 3.0 版做了大幅升级，该草案遭到了以 Yahoo、Microsoft、Google 为首的大公司的强烈反对，JavaScript 语言的创造者 Brendan Eich 和 IE 架构师 Chris Wilson 甚至在博客上就ES4向后兼容性问题打起了口水仗，最后由于各方分歧太大，ECMA 开会决定废弃中止 ECMAScript 4.0 草案。经各方妥协，在保证向下兼容的情况下，将部分增强的功能放到 ECMAScript 3.1 标准中，将原有 ECMAScript 4.0 草案中激进的功能放到以后的标准中。不久，ECMAScript 3.1 就改名为 ECMAScript 5。

2009 年 12 月，本着’Don’t break the web’原则，ECMAScript 5 发布。新增了 strict 模式、属性 getter 和 setter 等。

2011 年 6 月，ECMAScript 5.1 发布。

2015 年 6 月，ECMAScript 6.0 发布。该版本增加了许多新的语法，包括支持 let、const、Arrow function、Class、Module、Promise、Iterator、Generator、Set、Map、async、Symbol、Proxy、Reflect、Decorator 等。TC39 委员会计划以后每年都发布一个新版本的 ECMAScript，所以 ECMAScript 6.0 改名为 ECMAScript 2015。

2016 年 6 月，在 ECMAScript 2015 的基础上进行了部分增强，发布了 ECMAScript 2016。

在 ECMAScript 的各个版本中，ECMAScript 6.0 无疑最受人瞩目的，它增加了许多新特性，极大拓展了 JavaScript 语法和能力，以至于许多浏览器都只能支持部分 ES6 中的新特性。随之，Babel 和 TypeScript 逐渐流行起来，编写 ES6 代码，然后用 Babel 或 TypeScript 将其编译为 ES5 等浏览器支持的 JavaScript。

ECMAScript 以后每年将会发布一个新版本，这无疑将持续促使浏览器厂商不断为 JavaScript 注入新的功能与特性，JavaScript走上了快速发展的正轨。

参考资料

• 前端发展简史
• 前端发展史

更多文章

https://github.com/jeanboydev/Android-ReadTheFuckingSourceCode

来自：https://blog.csdn.net/freekiteyu/article/details/79927047

https://blog.rackspace.com/internet-history-html-evolution

等等