前端基础了解

106号水手

已于 2023-06-16 23:06:44 修改

阅读量114

点赞数

分类专栏：前端基础知识文章标签：前端

于 2023-06-16 16:35:26 首次发布

本文链接：https://blog.csdn.net/weixin_42694511/article/details/131249775

版权

前端基础知识专栏收录该内容

8 篇文章 0 订阅

订阅专栏

前端基础了解

1，历史

前端起源

1990 年，第一个web浏览器诞生，Tim 以超文本语言 HTML 为基础在 NeXT 电脑上发明了最原始的 Web 浏览器。
1991 年，WWW诞生，这标志着前端技术的开始。

前后端不分的时代

初期静态网站
互联网发展的早期，WWW（World Wide Web）、浏览器、JavaScript相继诞生，最开始大多是HTML静态网页。

动态网站技术阶段

比较有代表性的技术有JSP 、PHP、ASP、ASP.NET 等语言，它们都类似，是运行在服务端的语言。
那时候没有专业的前端，前后端开发是一体的，前端代码是后端代码的一部分，前端写静态模板，后端加数据套模板。

浏览器展现页面的流程是：
1、后端收到浏览器的URL请求，后端路由响应
2、后端生成静态页面
3、发送到浏览器渲染成页面
后端 MVC 的开发模式
那时的网站开发，采用的是后端 MVC 模式。

Model（模型层）：提供/保存数据
Controller（控制层）：数据处理，实现业务逻辑
View（视图层）：展示数据，提供用户界面
前端只是后端 MVC 的 V，那时候前端的 V 是在服务端渲染的。
PHP，ASP，ASP.NET，JSP等都是典型的这样的模式；

AJAX诞生

AJAX诞生是前端发展的一个里程碑，Ajax 技术诞生，改变了一切。

Ajax即Asynchronous Javascript And XML（异步JavaScript和XML）在 2005年被Jesse James Garrett提出的新术语，用来描述一种使用现有技术集合的‘新’方法，包括: HTML或 XHTML, CSS, JavaScript, DOM, XML, XSLT, 以及最重要的XMLHttpRequest。使用Ajax技术网页应用能够快速地将增量更新呈现在用户界面上，而不需要重载（刷新）整个页面，这使得程序能够更快地回应用户的操作。

AJAX是基于现有的Internet标准，并且联合使用它们：
XMLHttpRequest 对象 (异步的与服务器交换数据)
JavaScript/DOM (信息显示/交互)
CSS (给数据定义样式)
XML 、JSON(作为转换数据的格式)
lamp AJAX应用程序与浏览器和平台无关的！

AJAX 如何工作

前后分离时代

jQuery 时代

（开始注重前后端分离）

2006年，jQuery发布，它当时的竞争对手很多：Dojo、Prototype、ExtJS、MooTools。
2009年，Sizzle选择器引擎研发成功，jQuery才取得压倒性的优势。
当时前端界首要面对的是浏览器兼容性问题，jQuery在处理DOM兼容上真是知微见著, 发掘出大量的DOM/BOM兼容方案（例如Dean Edwrad的addEvent()， IE的px转换方案，domReady的doScroll方案，globalEval的兼容方案等）

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

随着社会的发展jQuery存在的问题：
jQuery的链式操作风靡一时，也带来许多问题，当Ajax出现依赖时，就不可避免就出现回调地狱。

前端模块化阶段

（后jQuery时代、node.js诞生）

jQuery的出现让前端工程师开发更加轻松，假如工程师想实现一个功能，搜索出一个jQuery插件来实现。那时候大家在前端网站就整天介绍jQuery插件，很少讨论一些底层的实现。

同时也冒出很多新的问题：

前端工程师通常编写一个页面，会引入十多个乃至几十个jQuery插件，页面上塞满了Script标签。众所周知，浏览器是单线程，Script的加载，会影响到页面的解析与呈现，导致著名的白屏问题（当时前端用力过猛，body中的所有东西都是动态生成的）。
jQuery另一个问题是全局污染，由于插件的质量问题，或者开发的素质问题，这已经是IIEF模块或命名空间等传统手段无法解决了。

于是一些优秀的前端工程师们决定向后端取经，引入模块机制。早期，这种模块机制在Dojo、EXT这些框架中都是内置的，但是显然说服不了另一个框架的用户用对方的模块机制，于是有人立志要统一这种模块定义方式，成立了CommonJS。CommonJS诞生很久一段时间后，在后端的Node.js出现时才有用武之地。

前端工程化阶段

以React, Vue, Angular为代表的前端框架，造就了如今SPA（single page application）的大势所趋势。同时React - React Native, Vue - Weex，node.js，各种小程序等也正在拓展前端的边界。

SPA 单页面应用原理

什么是SPA? SPA 即单页面，就是页面整体不刷新，不同的页面只改变局部的内容的一种实现方式。
浏览器URL，location.hash部分发生变化，页面不会重新请求，其它参数变化，均会引起页面的重新请求，而在Js中恰恰有事件 window.onhashchange 能监听到 location.hash的变化，于是就利用这个原理来达到一个修改局部内容的操作(vueRouter就是利用这一原理实现的，还有HTML5，history.pushState实现history模式)。
单页面应用的问题：
对现有的搜索引擎不友好
首页加载速度变慢
于是，为了解决这个问题，前端又把网页搬到后端去渲染了，出现了，服务端渲染(SSR: server side render)只是这次不一样的后端渲染，跟JSP，PHP，ASP不一样了，现在可以前后的分离开发，一套后台多端使用，前后端代码解耦，专业的人做专业的事！

2，前端的发展离不开浏览器的发展

值得一提的是V8引擎（JS虚拟机）：

2008年9月2日，Google的chrome浏览器发布，一并发布的Js引擎，就是V8引擎。V8使用BSD协议开源。
V8引擎使用 C++ 开发，将JavaScript编译成了机器码，而不是字节码，还用很多优化方法提高性能，因此，V8引擎速度非常快。
V8引擎还可以独立运行，可以嵌入到其他任何C++程序中，使在服务端运行JS成为可能。
2009年，基于V8引擎，诞生了Nodejs，这是服务器端运行JS的运行环境。
google的V8意义重大，它间接催生了，前端工程化。

1）浏览器引擎概述

浏览器引擎是浏览器背后的核心，它解析代码并渲染页面。具体来说，它将 HTML、CSS、JS 等前端代码转化为计算机可以理解的机器语言。它是浏览器的一个重要组成部分，分为前端和后端两部分：

1、前端是负责解析 HTML、CSS、JS 等前端代码的模块，主要由 HTML 解释器、CSS 解释器和 JS 引擎三部分组成；

2、后端是负责将计算机理解的机器语言转化为渲染页面的模块，主要由图形系统和呈现系统两部分组成。

下面就来详细探究浏览器引擎的实现原理。

2）引擎模块化

浏览器引擎采用模块化设计，意味着浏览器独立实现了各种模块，每个模块的功能都是分离的。模块之间通过接口交互，实现了更好的灵活性和可维护性。例如，Chrome 的 V8 引擎就是采用模块化设计实现的。

引擎的模块可以分为两大类：

1、主线程模块：包括网络引擎、JS 引擎、图形系统和呈现系统等几个主要模块。

2、线程池模块：包括网络线程池和 UI 线程池两个部分，主要是为了处理网络请求和 UI 操作而设置的线程池。

3）渲染过程

渲染过程是浏览器引擎最核心的部分，所以这里我们将详细介绍。

1、解析 HTML

HTML 解析器是浏览器引擎中的一个重要组件，它能够将 HTML 代码解析成 DOM 树。在解析 HTML 代码时，HTML 解析器会遇到以下几种情况：

（1）遇到标签：解析器会创建对应的 DOM 元素，并把它加到当前节点中；

（2）遇到文本：解析器会将文本添加到当前节点的文本子节点中；

（3）遇到处理指令：解析器会根据指令的内容执行相应的处理程序；

（4）遇到注释：解析器会忽略注释。

例1：下面是一个简单的 HTML 代码片段：
<html>
  <head>
    <title>My Title</title>
  </head>
  <body>
    <p>Hey there!</p>
  </body>
</html>
这个 HTML 代码将会被解释器解析为以下 DOM 树结构：

html
├──head
│   └──title
│       └──文本节点
└──body
    └──p
        └──文本节点

2、解析 CSS

CSS 解析器在解析 CSS 文件时，会将其解析为样式表树。在解析 CSS 文件时，CSS 解析器遇到以下几种情况：

（1）遇到样式规则：解析器会创建样式规则对象，并将其添加到样式表树中；

（2）遇到 @import：解析器会选取该样式表文件，并递归解析该样式表文件；

（3）遇到注释：解析器会忽略注释。

例2：下面是一个简单的 CSS 代码片段：
body {
  background-color: #ddd;
}
p {
  color: red;
}
这个 CSS 代码将会被解释器解析为以下样式表树结构：

.stylesheet
└──规则1
    ├──选择器
    ├──声明块
    │   └──声明1
    └──规则2
        ├──选择器
        ├──声明块
        │   └──声明1

3、解析 JS

JS 引擎解析 JS 代码时，同样会获取代码并将其解析成抽象语法树（AST），然后将 AST 转化为字节码。接着，JS 引擎执行字节码，并将其转化为机器码执行。

浏览器在解析 JS 代码时，会遇到以下几种情况：

（1）遇到函数或变量声明：解析器会创建对应的函数对象或变量对象；

（2）遇到表达式：解析器会对其进行求值；

（3）遇到语句：浏览器会根据语句的类型执行不同的操作；

（4）遇到注释：解析器会忽略注释。

例3：下面是一个简单的 JS 代码片段：
function add(num1, num2) {
  return num1 + num2;
}
var result = add(1, 2);
这个 JS 代码将会被解析器解析为以下抽象语法树：

function add
├──参数列表 (num1, num2)
└──函数体
    └──返回 (num1 + num2)
声明变量
├──名称 (result)
└──赋值 (add(1, 2))

3，渲染

渲染器进程的核心工作是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页。由于渲染机制过于复杂，所以渲染模块在执行的过程中会被划分为很多子阶段，通过输入HTML经过这些子阶段最后输出像素，我们把这样一个处理流程叫做渲染流水线。
按照渲染时间的顺序，流水线可以分为以下几个子阶段：构建DOM树、样式计算、布局、分层、绘制、分块、光栅化和合成。
在这里插入图片描述

html+css渲染

前端页面实际上都是一些html代码，浏览器会通过html parse对html代码进行解析，生成dom树，css一样会进行解析然后通过attachment将html和css进行复加，生成render tree渲染树和layout tree布局树，两者结合起来进行绘制，便能在浏览器上看见展示的页面了。

在这里插入图片描述

含有 JavaScript 和 CSS 的页面渲染流水线

当执行过程中遇到jacascript代码时会停止html解析，去加载JavaScript代码，因为JavaScript代码会操作dom，使dom树发生改变。

在这里插入图片描述

简述渲染流程

在这里插入图片描述

1，浏览器会解析三个东西：

一个是HTML/SVG/XHTML
CSS，解析CSS会产生CSS规则树。
Javascript，脚本，主要是通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree.

2，解析完成后，浏览器引擎会通过DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。

3，最后通过调用操作系统Native GUI的API绘制。

4，前后端分离后，需要考虑哪些事情

分离后的前端，不再是一个简单的HTML文件，已经是一个独立的应用系统。除了要考虑页面的数据渲染展示，还要用工程化的思想来考虑前端的架构，前后端的交互和数据安全等事情。

架构

前端应用部署在Nodejs、Nginx或者Nodejs和Nginx组合的服务器上，通过反向代理转发页面请求到后端服务器，相当于在传统的流程中加了Nodejs这一层。当然，也可以用Nodejs服务器来承担一部分负载均衡的工作，业务逻辑也可以放在Nodejs这一层来处理，例如：通过判断请求是来自PC还是APP，将请求发到不同的后端服务器。

Nodejs的架构中，分层如下：,
RESTful接口交互

前后端分离之后，更多的是采用RESTful风格的接口与后端进行数据交互。

REST是“呈现状态转移（REpresentational State Transfer）”的缩写，一种API的架构风格，在客户端和服务端之间通过呈现状态的转移来驱动应用状态的演进。

在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。

RESTful的API设计，使得后端通过接口向前端传递数据，数据的格式通常是JSON这种通用的格式。对前端来说，只要后端返回过来的是RESTful的数据就行，不管后端是用Java写，还是用python或PHP，拜托对后端的依赖，做到前端系统的独立。

工程化构建

Nodejs不止可以用来做前端服务器，在开发阶段，它也能发挥很大的作用。

前端生态的发展，是围绕着Nodejs进行的。用npm来管理项目依赖，可以很好的维护和运行在Nodejs环境上。

打包工具grunt、gulp、webpack和rollup等，都是运行在nodejs上，再结合语法编译、打包部署等插件，将应用输入成一个完整的应用。

如果你使用了Angular、React或Vue框架，或者你使用浏览器暂时还不兼容的ES6语法，还需要在应用打包前用babel将语法编译成浏览器可识别的ES5的语法。

SPA

SPA是单页Web应用（single page web application，SPA）的简写，就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。

像Angular、React或Vue就是为了SPA而设计的，结合前端路由库（react-router、vue-router）和状态热存储（redux、vuex）等，可以开发出一个媲美Native APP的Web APP，用户体验得到了很大的提升。

当然，SPA也不是完美的，也不是适合所有的web应用，需要结合项目和场景来选择。

SPA有如下缺点：

初次加载耗时增加。可以通过代码拆分、懒加载来提升性能，减少初次加载耗时。

SEO不友好，现在可以通过Prerender或Server render来解决一部分。

页面的前进和后端需要开发者自己写，不过现在一些路由库已经帮助我们基本解决了。

对开发者要求高，由于做SPA需要了解一整套技术栈，所以，要考虑后期是否有合适的人选进行维护。

5，服务端渲染和客户端渲染

1，服务端渲染和客户端渲染的区别

服务端渲染（SSR – server side render）
服务端渲染SSR是指：在服务端对页面进行渲染，把请求得到的数据插入页面html结构。浏览器请求页面时，服务端响应的body中就返回了渲染好的页面html结构。浏览器仅需加载css即可。

客户端渲染
客户端渲染是指：在客户端对页面进行渲染，在客户端解析页面js，遇到ajax就异步请求数据，并插入页面html结构。使用客户端渲染，当请求页面时，返回的body里为空，从上到下依次解析，在解析的过程中，如果发现ajax请求，则再次发起新的请求，拿到动态数据后，渲染成完整的html并注入到body里，结合css显示出来；

2，使用服务端渲染（SSR）的利弊

优势
利于SEO，更利于首屏渲染

局限
服务端压力较大；服务端渲染可以被爬虫抓取到，客户端异步渲染很难被爬虫抓取；本来通过客户端完成渲染，现在统一到服务端node服务实现，在高并发访问时，会大量占用服务端CPU资源；

3，实际应用

应用原则
真正的网站会采用两者结合的方式来实现。

需要seo时，采用服务端渲染
侧重效率和用户体验时，采用客户端渲染，ajax异步刷新获取数据
举例
单页面应用的首屏为了SEO，往往会采用服务端渲染。【也就是希望首页信息能够被浏览器搜索到，网站搜索排名更高】
购物网站的商品信息为了SEO，也会采用服务端渲染。【希望商品信息能够被浏览器搜索到，从而得到更高的销量】
评论信息等不需要考虑SEO的内容，一般会采用客户端渲染，通过ajax异步获取，从而获得更好的用户体验。