小编

作者：charryhuang；转自：腾讯技能工程

1991 年 8 月，第一个静态页面出身了，这是由 Tim Berners-Lee 发布的，想要见告人们什么是万维网。
从静态页面到 Ajax 技能，从 Server Side Render 到 React Server Components，历史的车轮滚滚向前，一个又一个技能出身和沉寂。
序言
1994 年，万维网同盟（W3C，World Wide Web Consortium）成立，超文本标记措辞（HTML，Hyper Text Markup Language）正式确立为网页标准措辞，我们的旅途从此开始。
本文将沿着韶光线，从“创造问题-办理问题”的角度，带领大家理解 Web 技能发展的关键进程，理解范例技能的出身以及技能更迭的缘由，思考技能发展的缘故原由。
Tim Berners-Lee
Tim Berners-Lee（蒂姆·伯纳斯·李），英国科学家，万维网之父，于 1989 年在欧洲核子研究组织（CERN）正式提出万维网的设想。
该网络最初是为了知足天下各地大学和研究所的科学家之间对自动信息共享的需求而设计和开拓的，这也是为什么HTML的顶层声明是 document，标署名、文档工具模型的名称也是由此而来。
1990 年 12 月，他开拓出了天下上第一个网页浏览器。
1993 年 4 月 30 日，欧洲核子研究组织将万维网软件置于公共领域，把万维网推广到全天下，让万维网科技得到迅速的发展，深深改变了人类的生活面貌。
他创造了超文本标记措辞（HTML），并创建了历史上第一个网站。
当然，现在只剩下了由 CERN 规复的网站副本：info.cern.ch.
静态网页时期
早期的静态网页，只有最基本的单栏布局，HTML 所支持的标签也仅有<h1>、<p>、<a>。
后来为了丰富网页的内容，<img>、<table>标签出身了。
这一阶段，Web 做事器基本上只是一个静态资源做事器，每当客户端浏览器发来访问要求，它都来者不拒的建立连接，查找 URL 指向的静态页面，再返回给客户端。
随着网页的飞速发展，人们创造要人工实现所有信息的编写是非常困难的，而且非常耗时。
设想一下，如果一个页面有两块区域展示的内容是相互独立的，那么你须要涵盖所有的可能，须要编写的页面数量是两块区域的内容数量的乘积！
此外，静态网站只能够根据用户的要求返回指向的网页，除了进行超链接跳转，没办法实现任何交互。
此时，人们想要
网页能够动态显示
直策应用数据库里的数据
网页实现一些用户交互
让页面更都雅
JavaScript 的出身
1994 年，网景公司发布了 Navigator 浏览器，但他们急需一种网页脚本措辞，以使浏览器可以与网页互动。
1995年，网景公司的 Brendan Eich 迫于公司的压力，只花了十天就设计了 JS 的最初版本，并命名为 Mocha。
后来网景公司为了蹭 Java 的热度，把 JS 终极改名为 JavaScript。
但实际情形是，网景公司和 Sun 公司结成同盟，才更名为 JavaScript。
从此网页有了一些大略的用户交互，比如表单验证；也有了一些JS为根本的动效，如走马灯。
但是让网页真正开始进入动态网页时期的却是以 PHP 为代表的后端网站技能。
扩展资料：第一次浏览器大战
在网景公司推出 JavaScript 的时候，微软以 JS 为根本，编写了 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 年，被美国在线（AOL）以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（Cascading HTML Style Sheets）最早提出了样式表可叠加的观点。
行尾的百分比表示这条样式的权重，终极将根据权重打算终极值。
图中将司帐算 30pt 40% + 20pt 60% 作为h2字体大小的终极值。
为理解决 CSS 兼容性的问题，网景公司乃至还将 CSS 用 JS 来编写。
CSS 从出身开始就伴随着大量的 bug，不同浏览器表现不同坑害了无数的程序员。
本日我们能用上相对靠谱的 css，不得不说这是一个奇迹。
动态网页技能
1995 年，Rasmus Lerdof 创造的 PHP 开始生动在各大网站，它让 Web 可以访问数据库了，PHP 实现了人们渴望的动态网页。
这里的动态网页不是指网页动效，而是指内容的动态展示、丰富的用户交互。
PHP 就像给网络天下打开了一扇窗，各种动态网页技能（如 ASP、JSP）雨后春笋般的冒了出来，万维网也因此开始高速发展，MVC 模式也开始涌如今后端网站技能中。
动态网页技能办理了以前各种令人无法呼吸的痛，生活总会越来越好的：
可以用数据库作为根本来展示网页内容
可以实现表单和一些大略交互
再也不用编写一大堆静态页面了
PHP 等动态网页技能的事理，大体上都是根据客户真个要求，从数据库里获取相对应的数据，然后塞到网页里去，返回给客户端一个添补好内容的网页。
这个阶段也是前后端耦合的。
网页开拓流程
而当一些根本的需求被知足之后，动态网页技能带来的不敷也逐渐暴露出来：
网页总是刷新。
用户名密码校验须要刷新以展示缺点提示；因下拉选择器选择不同而展示的内容须要刷新才能展示；每次数据交互一定会刷新一次页面。
网页和后端逻辑稠浊。
相信老前端们都有过这样的经历：开拓完HTML后，会把页面发给后端修正，加上数据注入逻辑；联调或者debug的时候两个人坐在一块看，查问题的效率很低。
有大量重复代码无法复用。
举一个范例的例子，论坛。
很多时候只有内容有变革，菜单、侧边栏等险些不会有改变，但每次要求的时候还是得再将全体网页传输一遍。
不仅页面会刷新，速率慢，还挺耗流量（这个年代上网也是一种奢侈）。
然后 AJAX 站了出来。
AJAX
AJAX，Async JavaScript And XML，于 1998 年开始初步运用，2005 年开始遍及。
AJAX 的广泛利用，标志着 Web2.0 时期的开启。
这同时也是各大浏览器争锋的时期。
现在，我们可以通过 AJAX 来动态获取数据，利用 DOM 操作动态更新网页内容了。
来看看加入了 AJAX 的网页是怎么事情的：
这个时候前端路由还没有兴起，大多数情形下还是后端返回一全体页面，部分内容通过 AJAX 进行获取。
随着智好手机的涌现，APP 开始抽芽。
比较起网页，APP 编写好之后只须要数据接口就能事情；而网页不仅须要后端写业务逻辑，掌握跳转，还要写一部分接口用于 AJAX 要求。
这个阶段前端能做的事情还是很少，还背负着“切图仔”的外号。
随着 HTML5 草案的提出，前端能做的交互越来越多，程序员们急需办理以下问题：
后端业务代码和数据接口稠浊，还得兼容 APP 的接口（很多企业既有 APP 又有网站）
前真个代码繁芜度急剧增加
能不能让前端也像 APP 一样，只须要要求数据接口即可展现内容呢？
扩展资料：第二次浏览器大战
2004 年 Firefox 发布，拉开了第二次浏览器大战的序幕。
同期市情上出身的各种新兴浏览器，如 Safari、Chrome 等，也加入了战役。
此前由于 XP 系统实在过于火爆，导致 IE 6 无任何竞争对手，微软乃至终结了浏览器的大部分员工，只留下几个人象征性地掩护顺便修补一下 bug。
这让开发职员非常痛楚。
此时 Firefox 以优胜于 IE 的性能和非常友好的编程工具，迅速将那些被 IE6 搞得焦头烂额的网页开拓职员们，从水火之中救出，导致先让前端工程师成为虔诚的第一批用户，然后，经由这些有履历的开拓职员们推广到了普通的用户群体。
基于 webkit 内核的 Safari，借助自家产品（iOS、MacOS）的垄断快速收割移动端和 mac 端市场份额；同样基于 webkit 内核的 Chrome，趁着微软放松当心，凭借优胜于市场上所有浏览器的性能，犹如中国历史上的成吉思汗一样大杀四方，快速扩展市场份额。
微软知道，自己已经失落去了最初能称霸的机会，这次它不想失落去，IE 再次开始迭代，各大浏览器厂商又开始不顾标准，迭代再次开始，为了统一化标准，W3C 开拓了 HTML5，但是迟迟得不到微软的认可。
在其他浏览器纷纭支持 HTML5 后，微软创造，自己又成了孤家寡人，份额不断缩水。
2016 年，Chrome 浏览器份额超越 IE，第二次浏览器大战结束。
浏览器大战极大的推动了技能进步，正是 Google 研发出的 V8 引擎极大的提升了 JS 的运行效率，NodeJS 才有机会出身，前端才能走向全栈。
JS 实在没有你想象的那么慢。
SPA
2008 年 HTML5 草案提出，各大浏览器开启良性竞争，争先实现 HTML5 功能。
由于 HTML5 带来前端代码繁芜度的增加，前端为了寻求良好的可掩护性和可复用性，也不得不参考后端 MVC 进行了设计和拆分，后来涌现了三大前端框架：Vue（2014）、React（2010）、AngularJS（2009）。
单页运用返回一个空缺的 HTML，并通过 JS 脚本进行动态天生内容，从此和页面刷新说拜拜。
后端不再卖力模板渲染，前端和 APP 开始对等，后真个 API 也可以通用化了。
前后端终于得以分离。
（PS：终极目标是成为后端）
但 SPA 由于返回的是空 HTML，所有 JS 也被打包为一个文件，须要在一开始就加载完所有的资源，
要求网页后白屏韶光比传统网页要长
爬虫爬到的是空缺页面，没办法做 SEO
在业务繁芜的情形下，要求文件很大，渲染非常慢。
这使得前端不得不拆分过于弘大的单页运用，涌现了框架的多页面观点，也涌现了多种办理方案。
很多网页首次加载的时候实在并不须要太多的东西，比如论坛首页与贴子详情页，完备可以将其拆开，用户在新打开的页面阅读反而体验更好（多页运用）。
又比如管理后台，可以在页面框架内，将每个菜单对应的管理页拆出来动态加载（import）。
Server Side Render
Server Side Render，做事端渲染，简称 SSR，又称做事端同构、直出，一样平常利用 NodeJS 实现。
这里的做事端渲染和以前的不一样，SSR 会利用已经“脱水”的首屏数据来渲染首屏页面返回给客户端，到了浏览器再注入浏览器事宜，并且保留单页运用的能力，对 SEO 非常友好。
但学习本钱高，限定较多。
让我们看看传统 SPA 和加入了 SSR 的 SPA 在要求上的差异：
客户端渲染示意
做事端渲染示意
传统 SPA 可以更快的返回页面，要求相应韶光更短；加载 JS 后才开始渲染，白屏韶光更长，loading 结束后用户感知到的相对可交互韶光更早。
而 SSR 在接到浏览器要求时，先从后端拉取首屏数据渲染在页面内才返回，要求相应韶光更长；由于节约了一段浏览器要求首屏数据的韶光，白屏韶光更短。
由于 JS 异步加载，用户感知的相对可交互韶光变晚。
但体验上 SSR 一样平常更好。
在极度情形下，用户眼中传统 SPA 会一贯显示 loading，利用了 SSR 的页面则会涌现“点不动”的情形。
大多数时候 SSR 体验会更佳，由于做事端承担了大部分渲染事情，这也导致做事端负载变高。
但在业务繁芜的情形下，SSR 首屏要求的接口数很多，导致返回 HTML 变慢。
归根结底，SSR 不能很好的搪塞业务繁芜的情形，首屏要加载的东西还是太多了。
以是我们要若何让用户感知到的白屏韶光变短呢？
减小加载体积
减少接口要求数
PWA 缓存
分块渲染
…
NodeJS
说完了 SSR，必须说一下 NodeJS。
2010 年 NodeJS 正式立项到现在已经 11 个年头了，NodeJS 的出身来自于 Ryan Dahl（下图） 的灵感。
他想以非壅塞的办法做所有事情，用完备异步办法可以处理非常多的要求（高并发）。
NodeJS 的涌现让前端向全栈的发展迈出了重大的一步。
很多公司开始用 NodeJS 搞 BFF（backend for frontend），我们也开始把 Controller 层放到 NodeJS 来处理，后端只卖力根本业务数据。
也便是现在的三层架构：
这种架构在跨真个时候具有良好的适配性，我们可以根据业务需求，为不同端设计不同的 Controller 和 View，而后台可以不做变更。
这种架构省去了很多沟通本钱，前端专注页面的展示，后端专注业务逻辑。
当然，NodeJS 还可以对后端数据进行预处理，前端根据自己的须要自己设计数据构造，页面开拓与接口调试形成闭环，还为后端分担了压力。
扩展资料：第三次浏览器大战

jsp页面走马灯效果实例汗青上第一个网页长如许 HTML

智好手机的飞速发展，这张图表现的淋漓尽致。
第三次浏览器大战是争夺移动端市场份额的一战，也是当下正在进行的一战。
Benedict Evans: “Mobile is eating the world.”（移动设备正在蚕食天下） “Mobile remakes the Internet.”（移动设备正在重构Internet）
而未来，浏览器真正的对手不再是浏览器，而是小程序这样结合了APP和网页优点的新兴技能。
未来
早在 2009 年，Facebook 的工程师就开拓了 bigPipe，让 Facebook 页面打开速率提高了两倍。
bigPipe 利用 分块渲染 的思想，将网页的渲染变成了一小块一小块的，做事端渲染好一块页面就发送给客户端。
他们直接把木桶拆了，冲破了短板效应。
做事端渲染 VS 流式分块渲染
时隔 11 年，也便是 2020 年 12 月，React 团队提出了 React Server Components，算是一个可扩展的前后端领悟方案。
其理念和 bigPipe 类似，把组件放在做事端渲染，节省了从浏览器进行数据要求的开支，一些运行时也可以不用放到浏览器，减小了包大小（如 markdown 在做事端渲染好了，也就不再须要把工具库发送给浏览器了）。
React Server Components 的引入，也同步做到了自动的 Code Split。
React Server Components 事理
不同的是 React Server Components 返回的不是 HTML，而是带有构造和数据的自定义类 JSON 数据。
这种构造，是对做事端渲染的核心（构造+数据）进行抽象，结合 React 的事情办法（如 Suspense），平缓的从做事端过渡到了客户端，坚持了组件状态，并且可以更自由的拼装做事器组件和客户端组件。
客户端组件和做事端组件混用
关于拆分这条思路，让我想到微前端，虽然现在微前端还有很多问题，但微运用即做事也不乏为一条办理之道。
未来前端或许会往“小而美”的方向发展，乃至形成一个以做事端组件为单位的包管理器，网页打包大小会越来越小，更多的组件是从网络上直接获取。
此外，我也很期待 Web Components 的发展，有了原生的支持，0kb runtime 也不是不可能了。
合久必分分久必合，现存很多前端框架也可以得到统一了。
当然现在 Web Components 想要投入利用，首先离不开浏览器的支持，而且必须有一个平缓的过渡，此外兼容性也是一个大问题（末了还是苦了程序员们）。
本文首发公众年夜众号：腾讯技能工程（ID：Tencent_TEG），如需转载请联系出处。