Web开发发展史

了解一下Web开发相关的历史，相关技术的演进历程，知其前世今生，非常有助于加深Web开发相关技术的理解和认识。

从静态页面到JavaScript，从依赖后端到自主开发，前端开发者从不被重视的“页面仔”逆袭为如今很多前端工程师的薪资比后端还高，从前端技术由国外开发者主导到如今国内自主产生的小程序技术，我们走了 20 年。

1990 年，第一个Web浏览器诞生，而WWW的诞生直接拉开前端史的序幕。本文从最初的静态网页到CGI、PHP/JSP/ASP、分布式企业计算平台J2EE/.Net、框架时代、Ajax、前端MVC、NodeJS、组件化、智能化的这个过程进行简要的介绍。

静态网页

纯粹HTML格式的网页通常被称为“静态网页”，静态网页是标准的HTML文件，它的文件扩展名是.htm、.html，可以包含文本、图像、声音、FLASH动画、客户端脚本和ActiveX控件及JAVA小程序等。静态网页是网站建设的基础，早期的网站一般都是由静态网页制作的。

初期动态网页CGI

1993年CGI（Common Gateway Interface）出现了，Web上的动态信息服务开始蓬勃兴起。CGI定义了Web服务器与外部应用程序之间的通信接口标准，因此Web服务器可以通过CGI执行外部程序，让外部程序根据Web请求内容生成动态的内容。Perl因为跨操作系统和易于修改的特性成为CGI的主要编写语言。当然，CGI可以用任何支持标准输入输出和环境变量的语言编写，比如Shell脚本,C/C++语言，只要符合接口标准即可。比如你用C语言编写CGI程序，你把希望返回的HTML内容通过printf输出就可以发送给Web服务器，进而返回给用户。

## 动态网页PHP/JSP/ASP 1994年的时候，PHP诞生了，PHP可以把程序（动态内容）嵌入到HTML（模版）中去执行，不仅能更好的组织Web应用的内容，而且执行效率比CGI还更高。之后96年出现的ASP和98年出现的JSP本质上也都可以看成是一种支持某种脚本语言编程（分别是VB和Java）的模版引擎。

随着动态网页技术发展，ASP、JSP、PHP等嵌入网页的脚本语言正被广泛使用，不过这些脚本要通过Web Server解释,而Html则被浏览器执行；

## 分布式企业计算平台J2EE/.Net Web开始广泛用于构建大型应用时，在分布式、安全性、事务性等方面的要求催生了J2EE(现在已更名为Java EE)平台在1999年的诞生，从那时开始为企业应用提供支撑平台的各种应用服务器也开始大行其道。Java Servlet、Java Server Pages (JSP)和Enterprise Java Bean (EJB )是Java EE中的核心规范，Servlet和JSP是运行在服务器端的Web组件，EJB运行在服务器端的业务组件，是一种分布式组件技术。2000年随之而来的.net平台，其ASP.net构件化的Web开发方式以及Visual Stidio.net开发环境的强大支持，大大降低了开发企业应用的复杂度。ASP.Net第一次让程序员可以像拖拽组件来创建Windows Form程序那样来组件化地创建Web页面，Java平台后来出现的JSF也承袭了这一思想。两大平台在相互竞争和模仿中不断向前发展。

框架时代MVC/ORM

虽然脚本语言大大提高了应用开发效率，但是试想一个复杂的大型Web应用，访问各种功能的URL地址纷繁复杂，涉及到的Web页面多种多样，同时还管理着大量的后台数据，因此我们需要在架构层面上解决维护性和扩展性等问题。这个时候，MVC的概念被引入到Web开发中来了。2004年出现的Struts就是当时非常流行的Java Web开发的MVC框架。MVC早在1978年就作为Smalltalk的一种设计模式被提出来了，应用到Web应用上，模型Model用于封装与业务逻辑相关的数据和数据处理方法，视图View是数据的HTML展现，控制器Controller负责响应请求，协调Model和View。Model，View和Controller的分开，是一种典型的关注点分离的思想，不仅使得代码复用性和组织性更好，使得Web应用的配置性和灵活性更好。这是Spring MVC的示意图，典型的MVC架构。

此外，数据访问也逐渐通过面向对象的方式来替代直接的SQL访问，出现了ORM（Object Relation Mapping）的概念，2001年出现的Hibernate就是其中的佼佼者，已经成为Java持久层的规范JPA的主要参考和实现。更多的全栈框架开始出现，比如2003年出现的Java开发框架Spring，同时更多的动态语言也被加入到Web编程语言的阵营中，2004年出现的Ruby开发框架Rails，2005出现的Python开发框架Django，都提供了全栈开发框架，或者自身提供Web开发的各种组件，或者可以方便的集成各种组件。比如Spring基于IoC和AOP思想可以方便得整合出全套Web开发组件，SSH（Struts+Spring+Hibernate）一度成为Java Web开发的标配。值得一提的时Rails这个MVC框架，26岁的丹麦大神David Heinemeier Hansson在开发著名项目管理软件BaseCamp的过程中形成，Ruby语言本身在快速开发上的优势，加上Rails诸如崇尚DRY（Don't）Repeat Yourself)原则, 约定优于配置，拥抱REST等特性，使其迅速成为一个极其流行的Web开发框架。

## 客户端崛起时代Ajax/SPA > 今天，需要在单个页面之间切换的 Web 应用模式似乎过时了...

历史滚滚往前，2004 年 Gmail 像风一样来到人间，很快 2005 年 Ajax 正式提出，加上 CDN 开始大量用于静态资源存储，于是出现了 JavaScript 王者归来的 SPA （Single Page Application 单页面应用）时代。

这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。看起来是如此美妙，但回过头来看看的话，这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。类似 Spring MVC，这个时代开始出现浏览器端的分层架构：

对于 SPA 应用有几个很重要的挑战：

前后端接口的约定。

如果后端的接口一塌糊涂，业务模型不够稳定，那么前端开发会很痛苦。在项目中不少团队也有类似尝试，通过接口规则、接口平台等方式来做。有了和后端一起沉淀的接口规则，还可以用来模拟数据，使得前后端可以在约定接口后实现高效并行开发。相信这一块会越做越好。

前端开发的复杂度控制。

SPA 应用大多以功能交互型为主，JavaScript 代码过十万行很正常。大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情。典型的解决方案是业界的 Backbone，但 Backbone 做的事还很有限，依旧存在大量空白区域需要挑战。

前端MVC Angular/Backbone

为了降低前端开发复杂度，除了 Backbone，还有大量框架涌现，比如 EmberJS、KnockoutJS、AngularJS 等等。这些框架总的原则是先按类型分层，比如 view、controller、model。 好处很明显：

前后端职责很清晰。前端工作在浏览器端，后端工作在服务端。清晰的分工，可以让开发并行，测试数据的模拟不难，前端可以本地开发。后端则可以专注于业务逻辑的处理，输出 RESTful 等接口。

前端开发的复杂度可控。前端代码很重，但合理的分层，让前端代码能各司其职。

部署相对独立，产品体验可以快速改进。

JavaScript在服务器端的逆袭 Node

各大浏览器的竞争，使其引擎的性能不断提升，至今Google V8引擎的性能已经足以运行大型Javascript程序。在V8之上加以网络、文件系统等内置模块，形成了如今的Node.js。

随着Node.js的出现，JavaScript开始拥有在服务端运行的能力，它的异步本质使得Node.js在处理I/O密集型业务中优势凸显，而大多Web业务中I/O性能都是瓶颈。eBay、Yahoo、甚至Microsoft Azure纷纷引入Node.js以提升性能。Node.js的package每天都有几千万的下载量。这对前端工程师来说可是一个好消息，精通JavaScript的他们也能够做服务端开发了！虽然现实中并不是这样美好（服务端开发涉及的不仅仅是语言层面），但一种新的开发模式也因此兴起：浏览器端处理展现层逻辑、而服务端Controller这一层以及相关的模板渲染、路由、数据接口以及Session/Cookie先关处理实际上交给了Nodejs来做。通过Nodejs, 意味着前后端很多代码可以复用（例如数据验证逻辑），在需要SEO的场景下也可以选择服务端模板渲染。

前端组件化时代

2013年，Facebook宣布推出React，引入了基于组件的架构。不久之后，大多数其他框架，如Vue、Angular，都选择组件化。

差不多在2015年左右，我们的思维方式有个大跳变——从熟悉的 MVC 模式转组件化开发模式。

组件化，给前端开发带来了极大的效率提升，是近几年以来web开发发展的趋势，各种组件化的用户界面库，框架也层出不穷，如，React，Vue，angular等，这些框架关于组件化都有各自的实现，推崇理念，与编程规范，各大框架的支持者之间的争论也是向来不断，而若想在不同框架间切换，成本还是挺高的，因为毕竟谁都希望自己能占主流，占据绝对优势地位，就像当前IE与网景浏览器之争，延续到现在，各类浏览器标准兼容差异万千，近年来w3c不断在为web标准规范做努力，Web Components就是推出的关于组件化的一个标准，希望它能将组件化更好的带进web开发，同时尽量保证标准规范，开发者可以更好的关注于开发，而不是框架选择与争论之上。

Web Components

Web Components它由四项主要技术组成，它们可以一起使用来创建封装功能的定制元素，可以在你喜欢的任何地方重用，不必担心代码冲突。 Web Components它本身不是一个规范，他是由W3C提出的另外4个规范的合集。这四个规范是：

技术	说明
Custom elements（自定义元素）	一组JavaScript API，允许您定义custom elements及其行为，然后可以在您的用户界面中按照需要使用它们。
Shadow DOM（影子DOM）	一组JavaScript API，用于将封装的“影子”DOM树附加到元素（与主文档DOM分开呈现）并控制其关联的功能。通过这种方式，您可以保持元素的功能私有，这样它们就可以被脚本化和样式化，而不用担心与文档的其他部分发生冲突。
HTML templates（HTML模板）	<template> 和 <slot> 元素使您可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。
HTML Imports（HTML导入）	一旦定义了自定义组件，最简单的重用它的方法就是使其定义细节保存在一个单独的文件中，然后使用导入机制将其导入到想要实际使用它的页面中。HTML 导入就是这样一种机制，尽管存在争议 — Mozilla 根本不同意这种方法，并打算在将来实现更合适的。

总体来说，Web component他是w3c标准，基本会是组件技术的最终方向，但是需要大量的时间来让来让浏览器支持(点击查看兼容情况)。

未来：前端智能化

前端目前的生产工艺还是人工的，即便有一定的程度的 lowcode 产品手段来辅助前端释放生产压力，但还是解决不了供不应求的问题，所以没有别的办法，只有一条路就是去人工，改成完全自动化的生产手段，只有让供给能力远远超越需求的市场增长指数，那么才能彻底解决供不应求的问题。

那么，前端该如何将生产手段提升到自动化阶段呢？
首先，我们能想到的生产手段上肯定不能重度依赖人，那么剩下的也仅有机器，对于我们而言，肯定就是计算机了。

长远来看，前端 + AI 的这种前端智能化方向肯定是持续存在的，前端也会因为 AI 能力的加入，会产生诸多不一样的生产力变化。这种变化可能是阶段性的，也可能是终极的，总之生产力会慢慢向计算机身上过渡，前端做的工作是驱动这一切的更深层工作。这个方向没有退路，也绕不过去。