从1991年首个静态页面诞生，看前端技术发展历程与变革？

作者名叫charryhuang，曾任职于腾讯CSIG部门，担任前端开发工程师一职。

1991年8月，首个静态网页问世，由Tim Berners-Lee所推出，旨在向世人介绍万维网的概念。自静态网页至Ajax技术的兴起，再到Server Side Render与React Server Components的问世，技术发展的车轮不断前行，无数技术相继诞生与衰落。

前言

1994年，万维网联盟（W3C）正式诞生，标志着超文本标记语言（HTML）作为网页标准语言的地位得以确立，这一刻，我们的探索之旅正式启程。

本文将按照时间顺序展开，从“识别问题-解决难题”的思路出发，带领大家深入探讨 Web 技术发展的核心阶段，揭示代表性技术的诞生过程以及技术变革的动因，并共同思考技术进步的内在原因。

Tim Berners-Lee

蒂姆·伯纳斯·李，一位来自英国的科学家，被誉为万维网的创始人，他在1989年，在位于欧洲的核子研究组织（CERN）中，首次提出了万维网的构想。该网络最初设计开发的初衷是为了满足全球各大学和研究机构科学家们对自动信息共享的迫切需求，正因如此，HTML的顶层声明被命名为“document”，而标签名以及文档对象模型的名称也都是基于这一命名而来的。

在1990年12月，他成功研制出了全球首个网页浏览器。紧接着，到了1993年4月30日，欧洲核子研究机构将万维网软件无偿开放，此举推动了万维网在全球范围内的普及，极大地促进了万维网科技的迅猛发展，同时也深刻地重塑了人类的生活方式。

他发明了超文本标记语言，即HTML，并且搭建了世界上首个网站。如今，我们只能通过CERN恢复的版本来访问它，即info.cern.ch。

静态网页时代

早期的静态网页仅具备最基础的单栏式布局，而HTML所能够支持的标签种类也十分有限，主要包括以下几种。

、。后来为了丰富网页的内容，

、标签诞生了。

在这一时期，Web服务器主要充当静态资源提供者的角色，对于客户端浏览器发送的访问请求，它总是毫无保留地建立连接，然后根据URL定位到相应的静态页面，并将其发送回客户端。

网页技术的迅猛进步使得人们意识到，手动完成所有信息的录入工作不仅异常艰巨，而且耗费大量时间。

想象一下，若一个网页中存在两个互不干扰的展示区域，那么在构思内容时，你必须考虑到所有可能的组合，此时所需编写的页面总数将是这两个区域内容量相乘的结果！

此外，静态网站仅能依据用户请求反馈相应网页，除超链接跳转外，无法实现其他任何互动功能。

此时，人们想要

JavaScript的诞生

1995年，网景公司的Brendan Eich在公司压力之下，仅用十天时间便完成了JS的雏形设计，并将其命名为Mocha。随后，为了借Java的盛名，网景公司决定将JS正式更名为JavaScript。然而，实际上，这一名称的变更是在网景公司与Sun公司建立合作关系后实现的。

自该网页引入了基础的用户互动功能，诸如表单数据的核实；同时，还融入了以JavaScript为支撑的动态效果，例如轮播展示。

然而，推动网页步入动态网页新时代的关键，正是以PHP为代表的后端网站开发技术。

扩展资料：第一次浏览器大战

当网景公司发布了JavaScript，微软便以此为基础，开发了JScript和VBScript两种浏览器脚本语言，并于1995年8月推出了IE 1.0浏览器。

微软将浏览器与系统捆绑销售，鉴于90%的用户普遍使用Windows操作系统，众多用户因此不自觉地选择了IE浏览器。面对微软在浏览器市场份额上的迅速扩张，网景公司不得不迅速将JavaScript技术提交给ECMA，进而确立了ECMAScript标准。

在这段日子里，有一件颇为有趣的事情发生了，那就是在IE 4.0正式发布的当天，Netscape的员工们惊讶地发现，公司草坪上突然出现了一个硕大的IE图标，这无疑是一种明显的挑衅行为。作为回应，Netscape 将其吉祥物“Mozilla”置于 IE 图标之上，并在其上挂上胸牌，上面写着“Netscape 72，Microsoft 18”——在那个时期，IE 的市场占有率确实不及 Netscape Navigator。

但这并不能彻底解决市场份额的问题，因此网景公司在首次浏览器竞争中失利，并于1998年，被美国在线公司以42亿美元的高价收购。

在1998年，网景公司尚未被收购之际，该公司公开发布了Navigator的源代码，意图借助众多程序员的共同努力，以期夺回市场份额。随后，Navigator更名为Mozilla。这一举措不仅催生了火狐浏览器的诞生，同时也为第二次浏览器大战埋下了伏笔。

CSS

1994年，Hkon Wium Lie 首次提出了关于CSS的构想。到了1996年12月，W3C正式发布了CSS规范的首个版本。

人们普遍渴望拥有美好的外观。自HTML问世以来，网页大多只是一种朴素的富文本展示平台。由于缺乏有效的布局和美化工具，早期的网页设计多依赖于table标签来安排结构。为了克服网页设计上的不足，Hkon Wium Lie与Bert Bos联手提出了CSS方案，而同期，W3C也对这一创新表现出浓厚的兴趣。

早期网页外观

CSS在早期有多个不同的版本，例如在PSL96版本中，用户甚至能够运用逻辑表达式。然而，由于其扩展性过强，加之众多浏览器制造商的存在，统一变得尤为困难，因此该版本最终被废弃。

在众多提案之中，Håkon W Lie 所提出的CHSS（级联HTML样式表）率先引入了样式表叠加的理念。

样式的行尾百分号用来表示该样式的权重，最终结果会依据这些权重来计算总和。例如，在图中会进行如下计算：将30pt乘以40%，再将20pt乘以60%，以此得出h2字体大小的最终数值。

为了克服 CSS 兼容性带来的挑战，网景公司甚至采取了将 CSS 通过 JavaScript 编写的策略。

CSS自问世以来，便饱受众多bug的困扰，各种浏览器间的表现差异更是让无数程序员深受其害。然而，如今我们能够使用相对稳定的CSS，这无疑是一个令人惊叹的成就。

动态网页技术

1995年，Rasmus Lerdof 发明的 PHP 软件在众多网站上崭露头角，使得Web平台能够与数据库进行交互，从而满足了人们对于动态网页的强烈需求。

这里的动态网页并非指网页的动态效果，而是强调内容的实时更新与用户互动的多样性。PHP技术犹如在网络世界中开启了一扇新的大门，随之涌现出诸如ASP、JSP等多种动态网页技术，推动万维网进入快速发展阶段，同时MVC模式也逐步在后端网站技术领域崭露头角。

动态网页技术有效缓解了以往诸多令人窒息的难题，预示着我们的生活将不断迈向美好：

PHP这类动态网页技术的工作原理主要涉及：接收客户端的请求，从数据库中提取相应的信息，将这些信息嵌入到网页中，最终向客户端发送一个内容丰富的网页。在这一过程中，前后端之间的联系是紧密相连的。

网页开发流程

随着基本需求得到满足，动态网页技术的缺陷也逐渐显现出来：

然后AJAX站了出来。

AJAX

AJAX，即异步JavaScript与XML，自1998年起开始被初步应用，并于2005年逐渐流行开来。其广泛的应用，不仅标志着Web2.0时代的到来，也迎来了各大浏览器之间的激烈竞争时期。

目前，我们已能运用AJAX技术动态地抓取信息，并借助DOM技术对网页内容进行实时更新。接下来，让我们探究一下融入AJAX的网页是如何运作的：

那时，前端路由尚未普及，大多数情形下，网页内容都是由后端整体提供，而部分数据则是通过AJAX技术动态加载的。

智能手机的问世催生了APP的诞生。与网页相比，一旦APP开发完成，仅需接入数据接口即可投入使用；而网页的构建则更为复杂，它不仅要求后端编写业务逻辑和控制页面跳转，还需编写接口以支持AJAX请求。

目前前端领域的工作范畴相对有限，且常被称作“切图师”。自HTML5草案问世后，前端所能实现的交互功能日益丰富，程序员们迫切需要解决以下几个关键问题：

能否实现前端功能，使其如同APP般，仅需调用数据接口便能够展示所需内容呢？

扩展资料：第二次浏览器大战

2004年，Firefox浏览器问世，正式开启了新一轮的浏览器竞争。与此同时，市场上涌现出了众多新兴的浏览器，诸如Safari和Chrome，它们也纷纷加入了这场角逐。

之前，因为XP系统异常受欢迎，IE6浏览器没有对手，微软甚至解散了浏览器部门的大部分员工，仅保留少数人象征性地负责维护和修复bug。这一情况让开发人员感到极度痛苦。

Firefox凭借其超越IE的卓越性能和极具亲和力的编程辅助工具，迅速帮助那些因IE6而陷入困境的网页开发者们脱离苦海，进而使得前端工程师们率先成为其忠实的拥趸，随后，这些经验丰富的开发者们又将Firefox推广至广大用户之中。

Safari浏览器依托于webkit内核，利用自家产品（iOS、MacOS）在移动端和mac端市场的垄断地位迅速抢占份额；同样基于webkit内核的Chrome浏览器，趁微软放松警惕之际，凭借其优于市场上所有浏览器的性能，犹如中国历史上的成吉思汗一般，四处征战，迅速扩大市场份额。

微软意识到，它曾错失了称霸市场的先机，此次它决心不再错失良机。IE浏览器再次启动了更新迭代，众多浏览器制造商亦纷纷效仿，无视标准规范，新一轮的迭代由此展开。为了统一标准，W3C推出了HTML5，然而，微软对此却迟迟不予认可。当其他浏览器纷纷拥抱HTML5时，微软发现自己再次陷入了孤立无援的境地，市场份额持续下滑。

2016年，Chrome浏览器的市场份额超过了IE，标志着第二次浏览器大战的落幕。

浏览器之间的竞争极大地促进了技术的快速发展，尤其是Google研发的V8引擎显著提高了JavaScript的执行速度，这使得NodeJS得以问世，前端开发也因此迈向了全栈时代。实际上，JavaScript的运行速度并没有你想象中的那样缓慢。

SPA

2008年，HTML5的草案被提出，随后各大浏览器厂商纷纷展开积极竞争，竞相推出支持HTML5的功能。鉴于HTML5使得前端代码的复杂度上升，为了追求更好的可维护性和可复用性，前端开发者不得不借鉴后端的MVC模式进行设计和模块拆分。这一变革最终催生了三大知名的前端框架：Vue（2014年发布）、React（2010年发布）、AngularJS（2009年发布）。

该应用在单页模式下输出一张空白的HTML页面，并借助JavaScript脚本实现内容的动态构建，从而告别了页面刷新的繁琐操作。

后端不再承担模板渲染的任务，前端与APP的职责逐渐对等，同时后端的API也实现了通用化。这样一来，前后端的界限终于得到了明确划分。（备注：我们的最终目标是成为后端的核心。）

然而，由于SPA生成的仅为空白的HTML，因此所有的JavaScript代码都被合并成了一个单独的文件，这就要求在页面初始化阶段必须将所有资源全部加载完毕。

这导致前端开发者不得不将过于庞大的单页应用进行拆分，从而催生了框架的多页面模式，并衍生出多种应对策略。

实际上，许多网页在初次加载时并不需要加载大量内容，例如论坛的主页和帖子详情页，完全可以将它们分离开来。这样做不仅能让用户在浏览新页面时获得更佳的阅读体验，而且（形成）了一种多页式的应用方式。

例如，在管理后台中，用户可以在网页架构范围内，将各个菜单项所关联的管理页面独立出来，并实现动态的引入（导入）。

Server Side Render

服务端渲染技术，亦称SSR，即服务端同构或直出，通常采用NodeJS进行实现。

此处服务端渲染技术有所改变，与以往不同。SSR技术通过使用“脱水”后的首屏数据来生成首屏页面，并将其发送至客户端。随后，在浏览器中注入相应的事件，同时仍保持单页应用的功能。这种做法对搜索引擎优化非常有利。然而，学习这种技术需要较高的成本，并且存在诸多限制。

让我们看看传统SPA和加入了SSR的SPA在请求上的区别：

客户端渲染示意

服务端渲染示意

传统SPA的页面跳转速度更快，其请求响应时间较短；在加载JavaScript之后才开始页面渲染，导致白屏时间较长；然而，一旦loading动画结束，用户能够感知到的可交互时间就会提前到来。

SSR在收到浏览器发出的请求后，会先从后端获取首屏所需的数据，并在页面上进行渲染，随后才给出响应，这使得请求的响应时间相对较长；然而，由于减少了浏览器请求首屏数据所需的时间，页面的白屏时间相应缩短。尽管JavaScript的异步加载使得用户能够交互的时间相对延后，但从整体体验来看，SSR通常表现得更为出色。

在极端状况下，用户会发现传统SPA持续显示加载状态，而采用SSR技术的页面则可能出现无法点击的现象。

通常情况下，使用SSR的体验更为出色，这是因为服务器端负责了大量的渲染任务，进而使得服务器的负担有所增加。然而，在业务流程较为复杂时，SSR首次加载页面所需的接口数量较多，这便使得HTML的返回速度变得缓慢。

究其根本，SSR在处理业务复杂状况时表现不佳，首屏需要加载的内容过多。因此，我们该如何缩短用户所感受到的白屏时间呢？

企鹅辅导在IMWEB平台实施SSR和PWA技术后，实现了近乎瞬间启动的效果。

NodeJS

谈完SSR之后，我们还需提及NodeJS。自2010年NodeJS项目启动至今，它已走过了11个春秋。NodeJS的问世源于Ryan Dahl（见下图）的创意。他立志以非阻塞模式完成所有任务，通过完全异步的处理方式，能够高效应对大量请求（即高并发）。

NodeJS 的问世促使前端技术迈向全栈领域迈出了关键步伐。众多企业纷纷采用 NodeJS 构建BFF（后端为前端）模式，我们亦将控制器层迁移至 NodeJS 进行处理，使得后端仅负责基础业务数据的支撑。这便是当前流行的三层架构：

这种设计在实现跨平台应用时展现出优异的兼容性，我们能够依据具体业务需求，针对不同的平台定制专属的控制器与视图，同时无需对后台系统进行任何调整。这样的架构大大降低了沟通成本，使得前端团队可以集中精力优化页面展示效果，而后端团队则可以专注于处理业务逻辑。

自然，NodeJS 亦能对后端数据实施预处理，前端可根据实际需求自行构建数据架构，页面制作与接口调试实现无缝对接，同时亦减轻了后端的负担。

扩展资料：第三次浏览器大战

智能手机的迅猛进步在这张图中得到了充分展现。那场被称为第三次浏览器大战的竞争，实质上是各方为了争夺移动市场占有率而展开的激烈角逐，而且这场战斗仍在激烈进行中。

Benedict Evans指出，移动设备正在逐渐吞噬整个世界，同时也在对互联网进行重塑。

在未来的发展道路上，浏览器所面临的真正挑战者并非其他浏览器，而是那些融合了应用程序与网页各自优势的小程序等新兴技术。

未来

自2009年起，Facebook的技术团队便推出了bigPipe技术，显著提升了Facebook页面的加载速度，实现了速度提升至原来的两倍。该技术采纳了分块渲染的理念，将网页的显示过程细分为若干小块，每当服务端完成一块页面的渲染，便立即将其传输至客户端。此举相当于直接拆除了木桶中的短板，有效消除了短板效应的影响。

服务端渲染 VS 流式分块渲染

在相隔11年之后的2020年12月，React开发团队推出了React Server Components，这被视为一种具有扩展性的前后端整合策略。其理念与bigPipe相近，组件在服务器端进行渲染，从而减少了浏览器端数据请求的成本；此外，一些运行时模块无需加载至浏览器，这有助于缩小软件包的体积（例如，markdown在服务器端完成渲染后，就不必再将工具库发送至浏览器了）。React Server Components 的加入，同时也实现了代码拆分的自动化功能。

React Server Components 原理

React Server Components所输出的并非传统的HTML，而是包含了结构信息的个性化JSON数据。

此架构通过抽象服务端渲染的核心要素（即结构加数据），与React的运作模式（例如Suspense）相结合，实现了从服务端到客户端的平滑过渡，同时确保了组件状态的持续，并赋予了开发者更灵活地组合服务器端与客户端组件的能力。

客户端组件和服务端组件混用

关于拆分的这一思路，我联想到微前端的概念。尽管微前端目前仍存在不少挑战，但微应用即服务模式依然是一条可行的解决方案。展望未来，前端技术或许会朝着“精巧而精致”的方向演进，甚至可能发展出一种以服务端组件为基础的包管理机制。届时，网页的打包体积将逐渐减小，而大量组件将直接从网络中获取。

我同样热切期盼Web Components的进步，原生技术的加入使得零运行时成为可能。正如分久必合，合久必分，众多前端框架有望实现统一。当然，若要Web Components得以投入实际应用，浏览器支持是不可或缺的前提，同时还需要经历一个渐进的过程。除此之外，兼容性问题同样不容忽视，最终往往让程序员们承受压力。

结语

自 JavaScript 问世以来，我们透过“发现问题与解决问题”的视角，见证了技术进步的动因与必然趋势。截止到2021年，Web应用程序在用户体验上与原生应用程序仍存在一定差距。或许将来会有一个桌面应用程序小程序问世，该小程序将实现标准化；或许它会在渐进式Web应用（PWA）的道路上不断前行；亦或者浏览器将开放更多的原生系统API，通过多种加载手段，并模拟APP的各项功能，力求实现与APP相似的用户体验。

每个时代都会涌现众多技术，经过时间的筛选，留存下来的不过是属于那个时代的佼佼者。技术的更迭是持续的，关键不在于盲目地追逐技术潮流，而应深入思考技术为何会如此演变，以及这种演变方式所带来的利弊。假若换作是你，你又将如何应对当前的技术挑战呢？