前端分享: 前端技术发展演进之路(上)

前端时代周刊
3,013 阅读17分钟

写在前面

本篇是站在前端发展的角度分享前端技术的演变之路,不谈具体的技术,针对非前端开发或者其他岗位同学对前端开发一个全面的认识.可以用作跨部门之间的分享课题.内容为本人整理,里面有描述不准确的地方欢迎大家指正修改.本篇分享也有做成的PPT文件,如需原件可以私信联系.

本文将以PTT分页的结构进行分享.

P1 标题

前端技术演进发展之路

主讲人: XX 部门: 研发中心

P2 互动

web.png

抛出几个互动问题:

  1. 前端是什么?
  2. 前端能做什么?
  3. 都需要哪些技能?
  4. 来谈一谈你对前端的认识?

互动之后: 大家对前端还是有很深刻的了解,今天的分享内容不讲前端具体的某个技术,我想给大家分享一下前端的演进发展历程,让大家对前端有一个更全面的了解.

P3 大纲

  1. web1.0时代
  2. web2.0时代
  3. 前端为主的 MV* 时代
  4. 前端工程化时代
  5. Node带来的全栈时代
  6. 大前端时代

备注:

1990 年，第一个Web浏览器的诞生；1991 年，WWW诞生，这标志着前端技术的开始。在这20年的前端发展史中，我们经历了从最早的纯静态页面，到JavaScript跨时代的诞生；从PC端到移动端再到小程序；

这次会从这几个阶段来深入讨论一下前端,希望通过这次的分享可以让大家对前端的前生来世有一个认识,能够了解前端开发的技术栈,以及前端能做什么

P4 Web1.0时代

我们将从以下几个小节来了解一下web1.0时代

  1. 洪荒时代
  2. 第一次浏览器战争
  3. 动态页面崛起
  4. 后端为主的MVC时代
  5. 第二次浏览器战争

P5 洪荒时代

img

洪荒时代(1990-1994年)

这期间 WWW(World Wide Web)诞生,浏览器诞生,JavaScript诞生

当时没有专业的前端,页面全由后端开发，这带来一个明显的缺憾：每次更新都要整页刷新，加上早期的网速情况，这个操作是非常慢的。

备注: 上图是1994年丽景公司发布的第一款商业浏览器Navigator. 同年，PHP诞生。PHP能将动态的内容嵌入到HTML中，提升了编写页面的效率与可读性。PHP的界定符、循环语句等的发明，深刻影响了后来的ASP、JSP，乃致后来的JavaScript前端模板引擎。

1994年，W3C小组也成立了，他们负责HTML的发展路径，其宗旨是通过促进通用协议的发展。W3C标准不是某一个标准，而是一系列标准的集合。网页主要由三部分组成：结构、表现和行为。

P6 第一次浏览器战争

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

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

但是由于JScript的Bug非常多，大家不愿意为IE开发网站，因此发掘出UA，专门过滤掉IE浏览器。UA即Navigator.userAgent ，是用一个字符串来记录用户当前运行在什么操作系统与浏览器中。当前IE3的UA是这样的：

Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)

程序判断UA信息，假如发现当前运行的环境是IE浏览器的话，就提示用户用网景浏览器打开。因此微软不得不让自己的UA尽量伪装成网景的UA，欺骗用于检测UA的脚本，达到IE浏览器可以跑这些网站的目的。

第一次浏览器战争以 IE 浏览器完胜 Netscape 而结束，IE 开始统领浏览器市场，份额的最高峰达到 2002 年的 96%。

第一次浏览器战争带来了一个问题：尽管当时有ECMA-262（JavaScript规范文档）与W3C（HTML与CSS的规范文档），微软却没有照规范来实现JavaScript、HTML与CSS，导致前端兼容问题的诞生。所以CSS Hack、浏览器判定、特性侦测，这些技术就应运而生。

img

P7 动态页面的崛起

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

image-20210409172123565.png

web1.0.png

这种模式非常适合创业型小项目，不分前后端，经常 3-5 人搞定所有开发。页面由 JSP、PHP 等工程师在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。

这种模式的好处是：简单明快，本地起一个 Tomcat 或 Apache 就能开发，调试什么的都还好，只要业务不太复杂。

然而业务总会变复杂，这是好事情，否则很可能就意味着创业失败了。业务的复杂会让 Service 越来越多，参与开发的人员也很可能从几个人快速扩招到几十人。在这种情况下，会遇到一些典型问题：

1、Service 越来越多，调用关系变复杂，前端搭建本地环境不再是一件简单的事。 考虑团队协作，往往会考虑搭建集中式的开发服务器来解决。这种解决方案对编译型的后端开发来说也许还好，但对前端开发来说并不友好。天哪，我只是想调整下按钮样式，却要本地开发、代码上传、验证生效等好几个步骤。也许习惯了也还好，但开发服务器总是不那么稳定，出问题时往往需要依赖后端开发搞定。看似仅仅是前端开发难以本地化，但这对研发效率的影响其实蛮大。

2、JSP 等代码的可维护性越来越差。 JSP 非常强大，可以内嵌 Java 代码。这种强大使得前后端的职责不清晰，JSP 变成了一个灰色地带。经常为了赶项目，为了各种紧急需求，会在 JSP 里揉杂大量业务代码。积攒到一定阶段时，往往会带来大量维护成本。

P8 后端为主的MVC时代

为了降低复杂度，以后端为出发点，有了 Web Server 层的架构升级，比如 Structs、Spring MVC 等，这是后端的 MVC 时代。

mvc.png

代码可维护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆，还可以选择 Velocity、Freemaker 等模板,这个阶段的典型问题是：

1、前端开发重度依赖开发环境。 这种架构下，前后端协作有两种模式：一种是前端写 demo，写好后，让后端去套模板。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显，demo 可以本地开发，很高效。不足是还需要后端套模板，有可能套错，套完后还需要前端确定，来回沟通调整的成本比较大。另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发，支付宝是这种模式。好处是 UI 相关的代码都是前端去写就好，后端不用太关注，不足就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因素。

2、前后端职责依旧纠缠不清。 Velocity 模板还是蛮强大的，变量、逻辑、宏等特性，依旧可以通过拿到的上下文变量来实现各种业务逻辑。这样，只要前端弱势一点，往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller，页面路由等功能本应该是前端最关注的，但却是由后端来实现。Controller 本身与 Model 往往也会纠缠不清，看了让人咬牙的代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养，否则 JSP 就够了。

P9 第二次浏览器战争

image-20210410110440291.png

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

火狐于2004年11月首次发布,，并且 9 个月内下载量超过 6000 万，获取了巨大的成功，IE 的主导地位首次受到了挑战,之后 Firefox 浏览器一路奋起直追，逐渐蚕食 IE 市场份额，这引发了第二次浏览器战争。在 2008 年底时，Firefox 的市场份额达到了 25% 以上，IE 则跌至 65% 以下。

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

ie.png

P10 Web2.0时代

我们将从以下几个小节来了解一下web2.0时代

  1. Ajax横空出世
  2. jQuery一统天下
  3. 后jQuery时代—前端模块化

P11 Ajax横空出世

1999年,微软的IE5发布,第一次引入新功能：允许JavaScript脚本向服务器发起HTTP请求。这个功能当时并没有引起注意，直到04-05年Google的两个Web产品Gmail和Google Map 大量使用了Ajax技术，不需要刷新页面就可以使得前端与服务器进行网络通信，才引起了广泛的重视. 这虽然在当今看来是理所应当的，但是在十几年前AJAX却是一项革命性的技术，颠覆了用户体验，加上 CDN 开始大量用于静态资源存储，于是出现了 JavaScript 王者归来的 Web 2.0时代。

web2.0.png

这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。看起来是如此美妙.

ajax.png

P12 jQuery一统天下

2006年，jQuery发布,当时前端界首要面对的是浏览器兼容性问题，jQuery在处理DOM兼容上真是知微见著, 发掘出大量的DOM/BOM兼容方案

jquery.png

// js原生
    var tabTotal = document.getElementById('tab');
    var tabNav = tabTotal.querySelectorAll('.tab-nav a');
    var tabContent = tabTotal.querySelectorAll('.tab-content .content');
    for(var i = 0; i < tabNav.length; i++){   // 遍历Tab选项
        tabNav[i].onclick = (function (i) {   // Tab选项绑定点击事件
            return function () {
                // 清除所有Tab选项的标记样式
                for(var j = 0; j < tabNav.length; j++){
                    tabNav[j].classList.remove('current');
                }
　　　　　　　　　// 给当前选中的tab选项增加样式
                tabNav[i].classList.add('current');
                // 清除所有Tab选项内容的显示样式
                for(j = 0; j < tabContent.length; j++){
                    tabContent[j].classList.remove('current');
                }
                tabContent[i].classList.add('current');
            }
        })(i);
    }
　　// jQuery 
    $(".tab-nav a").each(function (index) {
        $(this).click(function () {
                	$(this).css({'background':'black','color':'white'}).siblings().css({'background':'white','color':'black'});
                $(".content").eq(index).css("display","block").siblings().css("display","none");
        })
    })

jQuery的流行间接带来以下的发展：

  1. 促使人们对CSS1~CSS3选择器的学习
  2. 最重要的是降低前端门槛，让更多人进入这行业，前端工程师的队伍越来越壮大。
  3. 开发者们已开始注重前后端分离.

jQuery也打破了前端开发者的编程思维，之前是按照后端的开发思路来的：做一个业务就先封装一个类，有了这个类后，再想办法传入一个DOM，然后再通过类方法操作DOM。而jQuery是DOM为中心，开发者可以选一个或多个DOM，变成jQuery对象，然后进行链式操作。大量优秀的工程师创造了大量的jQuery插件和UI库.

P13 后jQuery时代-前端模块化

随之发展,jQuery也存在一些问题:

  1. jQuery的链式操作风靡一时，也带来许多问题，当Ajax出现依赖时，就不可避免就出现回调地狱。
// Demonstrates nesting, CPS, 'callback hell'
 $.get('api1/data', function(resp1) {
     // Next that depended on the first response.
     $.get('api2/data', function(resp2) {
         // Next request that depended on the second response.
         $.get('api3/data', function(resp3) {
             // Next request that depended on the third response.
             $.get(); // ... you get the idea.
         });
     });
 });
  1. jQuery如此多的选择器不好维护，随着发展，页面的交互也越来越复杂，造就了Web Page向Web App进化，新的趋势带来新的开发方式。
  2. 前端工程师通常编写一个页面，会引入十多个乃至几十个jQuery插件，页面上塞满了Script标签。众所周知，浏览器是单线程，Script的加载，会影响到页面的解析与呈现，导致著名的白屏问题
  3. jQuery另一个问题是全局污染，由于插件的质量问题，或者开发的素质问题，导致全局污染.

于是一些优秀的前端工程师们决定向后端取经，引入模块机制。于是有人立志要统一这种模块定义方式，成立了CommonJS。CommonJS诞生很久一段时间后，在后端的Node.js出现时才有用武之地。

CommonJS规范是诞生比较早的。NodeJS就采用了CommonJS。是这样加载模块：

// clock.js 定义
module.exports ={
  satrt:function(){}
}
// 引用
var clock = require('clock');
clock.start();

但不料，CommonJS内部也有派系，谁也说不服对方。终于有一个人忍不住自己独立开发出RequireJS，其模块规范即为AMD。AMD最大的优势是它支持各种插件，且简单明了，并且提供shim机制加载以非AMD规范编写的JavaScript代码。

AMD，即 (Asynchronous Module Definition)，这种规范是异步的加载模块，requireJs应用了这一规范。先定义所有依赖，然后在加载完成后的回调函数中执行：

// 定义
define(function () {
    return {
        attr1: 'attr1',
        attr2: 456,
        start:function(){}
    }
});
// 引用
require(['clock'],function(clock){
  clock.start();
});

AMD虽然实现了异步加载，但是开始就把所有依赖写出来是不符合书写的逻辑顺序的，能不能像commonJS那样用的时候再require，而且还支持异步加载后再执行呢？

而国内，则流行另一种规范风格，背靠阿里的大旗，有人推出了SeaJS，号称其规范为CMD。其实无论国内还是国外，都产生许多模块加载器，但最后还是被淘汰了，规范一个就够了，不宜过多。

CMD (Common Module Definition), 是seajs推崇的规范，CMD则是依赖就近，用的时候再require。它写起来是这样的：

define(function(require, exports, module) {
   var clock = require('clock');
   clock.start();
});

直到ES6的出现,ES6标准的模块化

ES6静态加载的设计思想，使得在编译时就可以确定模块的依赖关系，以及输入、输出的变量。ES6则在语言层面上实现了模块化，取代CommonJS、AMD、CMD成为服务端和浏览器端通用的模块解决方案。（CommonJS、AMD、CMD运行时确定依赖关系）

备注: CommonJS规范---是通过module.exports定义的，在前端浏览器里面并不支持module.exports,通过node.js后端使用的。Nodejs端是使用CommonJS规范的，前端浏览器一般使用AMD、CMD、ES6等定义模块化开发的

P14 前端为主的MV*时代

标题页

P15 后端MVC带来的问题

image.png

采用的后端为主的MVC模式,业务形态导致前端的Model其实是弱模式,所以选择使用Service来代替Model做API聚合

MVVM最早由微软提出来，它借鉴了桌面应用程序的MVC思想，在前端页面中，把Model用纯JavaScript对象表示，View负责显示，两者做到了最大限度的分离 把Model和View关联起来的就是ViewModel。 ViewModel负责把Model的数据同步到View显示出来，还负责把View的修改同步回Model View 和 Model 之间的同步工作完全是自动的，无需人为干涉。

P16 React & Angular

image.png

随着前端技术的发展，逐渐出现了以React、 Vue、 Angular三大MV*框架瓜分天下的局面. React由Facebook推出的前端框架，Angular则背靠Google，而Vue则是由Google的核心开发工程师——尤雨溪（Evan You）所创建的框架

Angular是出现最早的MVVM框架，虽然背靠大厂，但是由于学习曲线陡峭，颠覆性升级过快，并且随着React和Vue的崛起，国内Angular用的人也随之减少。 React相比Angular比较轻量，灵活性高，并且React生态中的React-Native是一个优秀的移动端开发框架，可以适配安卓和IOS系统开发，并且可以进行热更新，受到了很多大厂的青睐。

P17 Vue

image.png

Vue做为一个国产的框架，作为一个比 React 和 Angular 都更年轻的框架，Vue 从它们那里借鉴了好的部分，即函数式和面向对象编程的混合体。有比较完善的中文文档，学习成本最低，语法精炼、优雅而简洁、代码的可读性高、成熟的组件模块化所以在国内很受欢迎。

vue两大特点：响应式编程、组件化。

vue的优势：轻量级框架、简单易学、双向数据绑定、组件化、数据和结构的分离、虚拟DOM、运行速度快。

vue是单页面应用，使页面局部刷新，不用每次跳转页面都要请求所有数据和dom，这样大大加快了访问速度和提升用户体验。

P18 Vue和JQuery对比

为了更直观的对比一下MVVM的优势,如果想实现一个对输入框的数据绑定的效果,分别用Vue和JQuery实现这个逻辑的代码对比:

image.png

image.png

通过对比之后,发现Vue简单几行代码就可以实现jQuery复杂的逻辑.并且在效率和性能上也有提升. 曾经封神jQuery也逐渐退出历史舞台.

未完待续

因篇幅过长,我们今天先分享前端技术发展演进之路的上半部分.

下半部分的前端工程化,全栈开发时代,大前端时代将在下篇中继续分享

下面贴一下PPT的截图,如果需要PPT文件的可以留言或者私聊哦

如果对本篇文章感兴趣的欢迎点赞转发~

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

最后

欢迎大家访问我们的小程序小程序前端面试题宝典 (点我点我点点点我) ，里面已经搜集了600+常见的前端面试题的题目和答案，希望能够帮助正在面试路上的同学。

avatar
文章
阅读
粉丝
相关推荐
揭秘为什么后端要学习前端，而前端不怎么需要学后端！
616阅读
 · 
0点赞
大前端方向学习路线
165阅读
 · 
0点赞
第一期前端技术月刊（一月）
3.5k阅读
 · 
57点赞
【前端趋势调查系列】带你看看前端生态圈的技术趋势state-of-css 2023详细解读
469阅读
 · 
1点赞
前端发展简史
425阅读
 · 
19点赞