整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
译 ｜ 核子可乐、Tina
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。
过去Web非常简单。URL 指向服务器，服务器将数据混合成 html，然后在浏览器上呈现该响应。围绕这种简单范式，诞生了各种Javascript框架，以前可能需要数月时间完成的一个应用程序基本功能，现在借助这些框架创建相对复杂的项目却只需要数小时，我们节省了很多时间，从而可以将更多精力花在业务逻辑和应用程序设计上。
但随着 Web 不断地发展，Javascript 失控了。不知何故，我们决定向用户抛出大量 App，并在使用时发出不断增加的网络请求；不知何故，为了生成 html，我们必须使用 JSON，发出数十个网络请求，丢弃我们在这些请求中获得的大部分数据，用一个越来越不透明的 JavaScript 框架黑匣子将 JSON 转换为 html，然后将新的 html 修补到 DOM 中......
难道大家快忘记了我们可以在服务器上渲染 html 吗？更快、更一致、更接近应用程序的实际状态，并且不会向用户设备发送任何不必要的数据？但是如果没有 Javascript，我们必须在每次操作时重新加载页面。
现在，有一个新的库出现了，摒弃了定制化的方法，这就是 htmx。作为 Web 开发未来理念的一种实现，它的原理很简单：
htmx 出现在 2020 年，创建者 Carson Gross 说 htmx 来源自他于 2013 年研究的一个项目 intercooler.js。2020 年，他重写了不依赖 jQuery 的 intercooler.js，并将其重命名为 htmx。然后他惊讶的发现 Django 社区迅速并戏剧性地接受了它！
图片来源：https://lp.jetbrains.com/django-developer-survey-2021-486/
Carson Gross 认为 htmx 设法抓住了开发者对现有 Javascript 框架不满的浪潮，“这些框架非常复杂，并且经常将 Django 变成一个愚蠢的 JSON 生产者”，而 htmx 与开箱即用的 Django 配合得更好，因为它通过 html 与服务器交互，而 Django 非常擅长生成 html。
对于 htmx 的迅速走红，Carson Gross 发出了一声感叹：这真是“十年窗下无人问，一举成名天下知（this is another example of a decade-long overnight success）”。
可以肯定的一点是 htmx 绝对能用，单从理论上讲，这个方法确实值得称道。但软件问题终究要归结于实践效果：效果好吗，能不能给前端开发带来改善？
在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他们在真实 SaaS 产品上实现了从 React 到 htmx 的迁移，而且效果非常好，堪称“一切 htmx 演示之母”（视频地址：https://www.youtube.com/watch?v=3GObi93tjZI）。
Contexte 的项目开始于 2017 年，其后端相当复杂，前端 UI 也非常丰富，但团队非常小。所以他们在一开始的时候跟随潮流选择了 React 来“构建 API 绑定 SPA、实现客户端状态管理、前后端状态分离”等。但实际应用中，因为 API 设计不当，DOM 树太深，又需要加载很多信息，导致 UI“非常非常缓慢”。在敏捷开发的要求下，团队里唯一的 Javascript 专家对项目的复杂性表现得一无所措，因此他们决定试试 htmx。
于是我们决定大胆尝试，花几个月时间用简单的 Django 模板和 htmx 替换掉了 SaaS 产品中已经使用两年的 React UI。这里我们分享了一些相关经验，公布各项具体指标，希望能帮同样关注 htmx 的朋友们找到说服 CTO 的理由！
6. 将 Web 构建时间缩短了 88%（由 40 秒缩短至 5 秒）
7. 首次加载交互时间缩短了 50% 至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）
8. 使用 htmx 时可以配合更大的数据集，超越 React 的处理极限
9. Web 应用程序的内存使用量减少了 46%（由 75 MB 降低至 40 MB）
这些数字令人颇为意外，也反映出 Contexte 应用程序高度契合超媒体的这一客观结果：这是一款以内容为中心的应用程序，用于显示大量文本和图像。很明显，其他 Web 应用程序在迁移之后恐怕很难有同样夸张的提升幅度。
但一些开发者仍然相信，大部分应用程序在采用超媒体 /htmx 方法之后，肯定也迎来显著的改善，至少在部分系统中大受裨益。
可能很多朋友没有注意，移植本身对团队结构也有直接影响。在 Contexte 使用 React 的时候，后端与前端之间存在硬性割裂，其中两位开发者全职管理后端，一位开发者单纯管理前端，另有一名开发者负责“全栈”。（这里的「全栈」，代表这位开发者能够轻松接手前端和后端工作，因此能够在整个「栈」上独立开发功能。）
而在移植至 htmx 之后，整个团队全都成了“全栈”开发人员。于是每位团队成员都更高效，能够贡献出更多价值。这也让开发变得更有乐趣，因为开发人员自己就能掌握完整功能。最后，转向 htmx 也让软件优化度上了一个台阶，现在开发人员可以在栈内的任意位置进行优化，无需与其他开发者提前协调。
如今，单页应用（SPA）可谓风靡一时：配合 React、Redux 或 Angular 等库的 JS 或 TS 密集型前端，已经成为创建 Web 应用程序的主流方式。以一个需要转译成 JS 的 SPA 应用为例：
但 htmx 风潮已经袭来，人们开始强调一种“傻瓜客户端”方法，即由服务器生成 html 本体并发送至客户端，意味着 UI 事件会被发送至服务器进行处理。
用这个例子进行前后对比，我们就会看到前者涉及的活动部件更多。从客户端角度出发，后者其实回避了定制化客户端技术，采取更简单的方法将原本只作为数据引擎的服务器变成了视图引擎。
后一种方法被称为 AJAX（异步 JavaScript 与 XML）。这种简单思路能够让 Web 应用程序获得更高的响应性体验，同时消除了糟糕的“回发”（postback，即网页完全刷新），由此回避了极其低效的“viewstate”等.NET 技术。
htmx 在很多方面都体现出对 AJAX 思路的回归，最大的区别就是它仅仅作为新的声明性 html 属性出现，负责指示触发条件是什么、要发布到哪个端点等。
另一个得到简化的元素是物理应用程序的结构与构建管道。因为不再涉及手工编写 JS，而且整个应用程序都基于服务器，因此不再对 JS 压缩器、捆绑器和转译器做（即时）要求。就连客户端项目也能解放出来，一切都由 Web 服务器项目负责完成，所有应用程序代码都在.NET 之上运行。从这个角度来看，这与高度依赖服务器的 Blazor Server 编程模型倒是颇有异曲同工之妙。
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着 SPA 的兴起，人们一度以为 AJAX 已经过气了，但其基本思路如今正卷土重来。这其中当然会有不同的权衡，例如更高的服务器负载和网络流量（毕竟现在我们发送的是数据视图，而不只是数据），但能让开发者多个选择肯定不是坏事。
虽然不敢确定这种趋势是否适用于包含丰富用户体验的高复杂度应用程序，但毫无疑问，相当一部分 Web 应用程序并不需要完整的 SPA 结构。对于这类用例，简单的 htmx 应用程序可能就是最好的解决方案。
参考链接：
https://news.ycombinator.com/item?id=33218439
https://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/
https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/
https://www.compositional-it.com/news-blog/more-on-htmx-back-to-the-future/
声明：本文为InfoQ编译，未经许可禁止转载。
长不看版：Snowpack v3.0 将于 2021 年 1 月 6 日发布（也是该版本最初公布的一周年纪念日）。这是我们最重大的一次版本更新，其中有一些重要的新特性，包括一种按需加载 npm 导入的新方法，可以完全跳过前端的 npm install 步骤。
激动人心的是，大家现在就可以开始试用新版了！
Snowpack v3 的重点是完善和正式发布四项已有特性，这些特性在当前版本的 Snowpack（v2.18.0）中通过 experiments 标志提供：
Snowpack 一直在努力探索前端开发的边界，这个版本也是如此。Snowpack v3.0 引入了一项令人兴奋的新特性，可加快并简化你的开发工作流程。
一般来说，JavaScript 依赖项是由包管理器 CLI（如 npm、yarn 或 pnpm）在本地安装和管理的。程序包经常带有不相关的文件，并且几乎没有哪个包能直接在浏览器中运行。我们需要额外的步骤来处理、构建和打包这些安装进来的软件包，才能让它们运行在浏览器中。
我们可以简化这一过程吗？如果 Snowpack 可以完全跳过“npm install”步骤，并通过 ESM 按需获取我们需要的，预构建的包代码，这是不是非常令人期待？
// you do this:
import * as React from 'react';
// but get behavior like this:
import * as React from 'https://cdn.skypack.dev/react@17.0.1';
上例中的 URL 指向 Skypack，这是一种流行的 JavaScript CDN，我们通过它将所有 npm 包当作 ESM 处理。Snowpack、Deno 和所有主要浏览器都能很好地支持通过 URL 导入依赖项。但是，将这些 URL 直接写入源代码的方法并不好用，并且如果没有网络连接就无法开发了。
Snowpack v3.0 融合了两个方面的优势：在你自己的源代码中获得 import 'react'的简单性，并让 Snowpack 在后台获取这些依赖项，这些依赖项已预构建完毕并可以在浏览器中运行。Snowpack 会自动为你缓存所有内容，因此你可以脱机工作，而无需依赖 Skypack。
与传统的“npm install”方法相比，这种机制有很多优点：
如果这一切听起来太不可思议了，请放心。想要使用它的话，这是 100％ opt-in 的行为。默认情况下，Snowpack 会像往常一样继续将 npm 包依赖项从项目 node_modules 目录中拉出来。
请查阅我们的流式NPM导入指南，了解如何在已有的项目中启用这一新行为。在将来的发行版中，我们希望对定制的 ESM 软件包源和其他 CDN 开放此特性。
esbuild 太令人震惊了：它的性能比大多数流行的打包器快 100 倍，比 Parcel 快 300 倍（根据 esbuild 自己的基准测试）。esbuild 用 Go 编写，而 Go 是一种编译语言，可以并行化繁重的打包任务负载，而其他流行的打包程序（用 JavaScript 编写）是做不到的。
Snowpack 已在内部使用 esbuild，作为我们 JavaScript、TypeScript 和 JSX 文件的默认单文件构建器。Snowpack v3.0 更进一步，加入了新的内置构建优化管道。为生产环境打包、缩小和转译你的站点时，它需要的时间只有其他打包器的 1/100。
今天 Snowpack 之所以可以采用采用 esbuild，是因为我们很早就对打包的未来投下了赌注：打包是一种构建后的优化步骤，而不是承载其他一切内容的核心基础。由于早期的这一设计决策，esbuild 可以像其他打包器一样轻松地插入和换出你的 Snowpack 构建。
esbuild 仍算是一个年轻的项目，但它的未来看起来很有希望。同时，我们还将在很长的一段时间内继续投资现有的 Webpack & Rollup 打包插件。
请查看我们最新的《优化Snowpack构建指南》中的 experiments.optimize 选项来开始尝试。
Snowpack 新加入的 experiments.routes 配置使你可以定义让开发环境与生产保持一致的路由。这一特性解锁了一些有趣的新用例，包括：
Snowpack 已经支持 API 代理和 SPA 回退有一段时间了，而这一新特性会将它们组合在一起，成为一个单一的、富有表现力的新 API。
Snowpack 的全新 JavaScriptAPI 可让你对 Snowpack 的开发服务器和构建管道进行更高级别的控制，从而帮助你在 Snowpack 上构建更强大的集成，以解锁新的开发工具和服务端渲染（SSR）解决方案。
Svelte 团队最近发布的 SvelteKit 引发了关注：这是 Svelte 应用的官方 zero-effort SSR 应用框架。SvelteKit 由 Snowpack 提供内部支持，使用了我们全新的 JavaScript API 来管理你的构建管道并按需构建文件。Snowpack 加快了开发速度，并帮助将 SvelteKit 的启动时间减少到了几乎可以忽略不计。
请查看我们新的JavaScript API参考，开始在 Snowpack 上构建你自己的自定义集成。或者通读我们关于服务端渲染的指南，开始使用用于生产的自定义 SSR 集成。
你可以通过以下命令安装 Snowpack v3.0 RC 版本：
npm install snowpack@next由于所有 v3.0 特性在现在的版本中都包括了，因此我们现有的文档站点同时适用于 v2 和 v3。目前，只有非常旧的，没有文档支持的旧行为在 next 分支中移除了。随着我们接近正式发布日期，实验标志下的特性可能会继续更改。到今年年底，这些特性将从实验标志后移到下一个 v3.0 分支的顶级配置对象中。
请在 snowpack.dev 上了解更多信息。
原文链接：
Snowpack 3 Release
https://www.snowpack.dev/posts/2020-12-03-snowpack-3-release-candidate?utm_source=tinyjs&utm_medium=email
微软发布.NET 5.0 RC1，未来将只有一个.NET-InfoQ
关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～
eb前端技术由html、css和 javascript三大部分构成，是一个庞大而复杂的技术体系，其复杂程度不低于任何一门后端语言。而我们在学习它的时候往往是先从某一个点切入，然后不断地接触和学习新的知识点，因此对于初学者很难理清楚整个体系的脉络结构。本文将对Web前端知识体系进行简单的梳理，对应的每个知识点点到为止，不作详细介绍。目的是帮助大家审查自己的知识结构是否完善，如有遗漏或不正确的地方，希望共勉。
HTML 篇
1、BOM
BOM 是 Browser Object Model
的缩写，即浏览器对象模型，当一个浏览器页面初始化时，会在内存创建一个全局的对象，用以描述当前窗口的属性和状态，这个全局对象被称为浏览器对象模型，即BOM。BOM的核心对象就是window，window
对象也是BOM的顶级对象，其中包含了浏览器的 6个核心模块：
document -
即文档对象，渲染引擎在解析HTML代码时，会为每一个元素生成对应的DOM对象，由于元素之间有层级关系，因此整个HTML代码解析完以后，会生成一个由不同节点组成的树形结构，俗称DOM树，document
用于描述DOM树的状态和属性，并提供了很多操作DOM的API。
frames - HTML 子框架，即在浏览器里嵌入另一个窗口，父框架和子框架拥有独立的作用域和上下文。
history - 以栈(FIFO)的形式保存着页面被访问的历史记录，页面前进即入栈，页面返回即出栈。
location - 提供了当前窗口中加载的文档相关信息以及一些导航功能。
navigator - 用来描述浏览器本身，包括浏览器的名称、版本、语言、系统平台、用户特性字符串等信息。
screen - 提供了浏览器显示屏幕的相关属性，比如显示屏幕的宽度和高度，可用宽度和高度。
2、DOM 系统
DOM 是 Document Object Model 的缩写，即 文档对象模型，是所有浏览器公共遵守的标准，DOM
将HTML和XML文档映射成一个由不同节点组成的树型结构，俗称DOM树。其核心对象是document，用于描述DOM树的状态和属性，并提供对应的DOM操作API。随着历史的发展，DOM
被划分为1级、2级、3级，共3个级别：
1级DOM - 在1998年10月份成为W3C的提议，由DOM核心与DOM
HTML两个模块组成。DOM核心能映射以XML为基础的文档结构，允许获取和操作文档的任意部分。DOM
HTML通过添加HTML专用的对象与函数对DOM核心进行了扩展。
2级DOM - 鉴于1级DOM仅以映射文档结构为目标，DOM
2级面向更为宽广。通过对原有DOM的扩展，2级DOM通过对象接口增加了对鼠标和用户界面事件（DHTML长期支持鼠标与用户界面事件）、范围、遍历（重复执行DOM文档）和层叠样式表（CSS）的支持。同时也对DOM
1的核心进行了扩展，从而可支持XML命名空间。
3级DOM -
通过引入统一方式载入和保存文档和文档验证方法对DOM进行进一步扩展，DOM3包含一个名为“DOM载入与保存”的新模块，DOM核心扩展后可支持XML1.0的所有内容，包括XML
Infoset、 XPath、和XML Base。
浏览器对不同级别DOM的支持情况如下所示：
从图中可以看出，移动端常用的 webkit 内核浏览器目前只支持DOM2，而不支持DOM3 。
新手福利获取方式：
1.在你手机的右上角有【关注】选项，或点击我的头像，点击关注！（关注我）
2.关注后，手机客户端点击我的主页面，右上角有私信，请私信发我：html
其实作为一个开发者，有一个学习的氛围跟一个交流圈子特别重要这里请私信我“html”不管你是小白还是大牛欢迎入住大家一起交流成长。小编会在里面不定期分享干货源码，包括我精心整理的一份零基础教程。欢迎各位感兴趣的的小伙伴。
学习思路：
3、事件系统
事件是用户与页面交互的基础，到目前为止，DOM事件从PC端的 鼠标事件(mouse) 发展到了 移动端的 触摸事件(touch) 和
手势事件(guesture)，touch事件描述了手指在屏幕操作的每一个细节，guesture 则是描述多手指操作时更为复杂的情况，总结如下：
第一根手指放下，触发 touchstart，除此之外什么都不会发生
手指滑动时，触发touchmove
第二根手指放下，触发 gesturestart
触发第二根手指的 touchstart
立即触发 gesturechange
任意手指移动，持续触发 gesturechange
第二根手指弹起时，触发 gestureend，以后将不会再触发 gesturechange
触发第二根手指的 touchend
触发touchstart (多根手指在屏幕上，提起一根，会刷新一次全局touch) _ ___
弹起第一根手指，触发 touchend
更多关于手势事件的介绍请参考：
gesture事件处理复杂手势
DOM2.0 模型将事件处理流程分为三个阶段，即 事件捕获阶段 、 事件处理阶段 、 事件冒泡阶段， 如图所示：
事件捕获 ：当用户触发点击事件后，顶层对象document 就会发出一个事件流，从最外层的DOM节点向目标元素节点传递，最终到达目标元素。
事件处理 ：当到达目标元素之后，执行目标元素绑定的处理函数。如果没有绑定监听函数，则不做任何处理。
事件冒泡 ：事件流从目标元素开始，向最外层DOM节点传递，途中如果有节点绑定了事件处理函数，这些函数就会被执行。
利用事件冒泡原理可以实现 事件委托
，所谓事件委托，就是在父元素上添加事件监听器，用以监听和处理子元素的事件，避免重复为子元素绑定相同的事件。当目标元素的事件被触发以后，这个事件就从目标元素开始，向最外层元素传递，最终冒泡到父元素上，父元素再通过event.target
获取到这个目标元素，这样做的好处是，父元素只需绑定一个事件监听，就可以对所有子元素的事件进行处理了，从而减少了不必要的事件绑定，对页面性能有一定的提升。
4、HTML解析过程
浏览器加载 html 文件以后，渲染引擎会从上往下，一步步来解析HTML标签，大致过程如下：
用户输入网址，浏览器向服务器发出请求，服务器返回html文件；
渲染引擎开始解析 html 标签，并将标签转化为DOM节点，生成 DOM树；
如果head 标签中引用了外部css文件，则发出css文件请求，服务器返回该文件，该过程会阻塞后面的解析；
如果引用了外部 js 文件，则发出 js 文件请求，服务器返回后立即执行该脚本，这个过程也会阻塞html的解析；
引擎开始解析 body 里面的内容，如果标签里引用了css 样式，就需要解析刚才下载好的css文件，然后用css来设置标签的样式属性，并生成渲染树；
如果 body 中的 img 标签引用了图片资源，则立即向服务器发出请求，此时引擎不会等待图片下载完毕，而是继续解析后面的标签；
服务器返回图片文件，由于图片需要占用一定的空间，会影响到后面元素的排版，因此引擎需要重新渲染这部分内容；
如果此时 js 脚本中运行了 style.display="none"，布局被改变，引擎也需要重新渲染这部分代码；
直到 html 结束标签为止，页面解析完毕。
5、重绘 和 回流
当渲染树中的一部分(或全部)因为元素的规模尺寸，布局，隐藏等改变而需要重新构建。这就称为回流。比如上面的img文件加载完成后就会引起回流，每个页面至少需要一次回流，就是在页面第一次加载的时候。
当渲染树中的一些元素需要更新属性，而这些属性只是影响元素的外观，风格，而不会影响布局的，比如 background-color。则就叫称为重绘。
从上面可以看出，回流必将引起重绘，而重绘不一定会引起回流。会引起重绘和回流的操作如下：
添加、删除元素(回流+重绘)
隐藏元素，display:none(回流+重绘)，visibility:hidden(只重绘，不回流)
移动元素，比如改变top,left的值，或者移动元素到另外一个父元素中。(重绘+回流)
对style的操作(对不同的属性操作，影响不一样)
还有一种是用户的操作，比如改变浏览器大小，改变浏览器的字体大小等(回流+重绘)
另外，transform
操作不会引起重绘和回流，是一种高效率的渲染。这是因为transform属于合成属性，对合成属性进行transition/animation
动画时将会创建一个合成层，这使得动画元素在一个独立的层中进行渲染，当元素的内容没有发生改变，就没必要进行重绘，浏览器会通过重新复合来创建动画帧。
6、本地存储
本地存储最原始的方式就是 cookie,cookie 是存放在本地浏览器的一段文本，数据以键值对的形式保存，可以设置过期时间。 但是 cookie
不适合大量数据的存储，因为每请求一次页面，cookie 都会发送给服务器，这使得 cookie
速度很慢而且效率也不高。因此cookie的大小被限制为4k左右(不同浏览器可能不同,分HOST)，如下所示：
Firefox和Safari允许cookie多达4097个字节，包括名(name)、值(value) 和 等号。
Opera允许cookie多达4096个字节，包括：名(name)、值(value) 和 等号。
Internet Explorer允许cookie多达4095个字节，包括：名(name)、值(value) 和 等号。
在所有浏览器中，任何cookie大小超过限制都被忽略，且永远不会被设置。
html5 提供了两种在客户端存储数据的新方法：localStorage 和 sessionStorage, 它们都是以key/value
的形式来存储数据，前者是永久存储，后者的存储期限仅限于浏览器会话(session)，即当浏览器窗口关闭后，sessionStorage中的数据被清除。
localStorage的存储空间大约5M左右(不同浏览器可能不同，分
HOST)，这个相当于一个5M大小的前端数据库，相比于cookie，可以节约带宽，但localStorage在浏览器隐私模式下是不可读取的，当存储数据超过了localStorage
的存储空间后会抛出异常。
此外，H5还提供了逆天的websql和
indexedDB，允许前端以关系型数据库的方式来存储本地数据，相对来说，这个功能目前应用的场景比较少，此处不作介绍。
7、浏览器缓存机制
浏览器缓存机制是指通过 HTTP 协议头里的 Cache-Control (或 Expires) 和 Last-Modified (或 Etag)
等字段来控制文件缓存的机制。
Cache-Control 用于控制文件在本地缓存有效时长。最常见的，比如服务器回包：Cache-Control:max-age=600
表示文件在本地应该缓存，且有效时长是600秒 (从发出请求算起)。在接下来600秒内，如果有请求这个资源，浏览器不会发出 HTTP
请求，而是直接使用本地缓存的文件。
Last-Modified 是标识文件在服务器上的最新更新时间。下次请求时，如果文件缓存过期，浏览器通过 If-Modified-Since
字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存；如果有修改，则返回200，同时返回最新的文件。
Cache-Control 通常与 Last-Modified 一起使用。一个用于控制缓存有效时间，一个在缓存失效后，向服务查询是否有更新。
Cache-Control 还有一个同功能的字段：Expires。Expires 的值一个绝对的时间点，如：Expires: Thu, 10 Nov
2015 08:45:11 GMT，表示在这个时间点之前，缓存都是有效的。
Expires 是 HTTP1.0 标准中的字段，Cache-Control 是 HTTP1.1
标准中新加的字段，功能一样，都是控制缓存的有效时间。当这两个字段同时出现时，Cache-Control 是高优化级的。
Etag 也是和 Last-Modified 一样，对文件进行标识的字段。不同的是，Etag
的取值是一个对文件进行标识的特征字串。在向服务器查询文件是否有更新时，浏览器通过 If-None-Match
字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新。没有更新回包304，有更新回包200。Etag 和
Last-Modified 可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。
另外有两种特殊的情况：
手动刷新页面(F5)，浏览器会直接认为缓存已经过期(可能缓存还没有过期)，在请求中加上字段：Cache-Control:max-age=0，发包向服务器查询是否有文件是否有更新。
强制刷新页面(Ctrl+F5)，浏览器会直接忽略本地的缓存(有缓存也会认为本地没有缓存)，在请求中加上字段：Cache-Control:no-cache
(或 Pragma:no-cache)，发包向服务重新拉取文件。
8、History
用户访问网页的历史记录通常会被保存在一个类似于栈的对象中，即history对象，点击返回就出栈，跳下一页就入栈。 它提供了以下方法来操作页面的前进和后退：
window.history.back( ) 返回到上一个页面
window.history.forward( ) 进入到下一个页面
window.history.go( [delta] ) 跳转到指定页面
HTML5 对History Api 进行了增强，新增了两个Api 和一个事件，分别是pushState、replaceState 和
onpopstate：
pushState是往history对象里添加一个新的历史记录，即压栈。
replaceState 是替换history对象中的当前历史记录。
当点击浏览器后退按钮或 js调用history.back 都会触发 onpopstate 事件。
与其类似的还有一个事件：onhashchange，onhashchange是老API，浏览器支持度高，本来是用来监听hash变化的，但可以被利用来做客户端前进和后退事件的监听，而onpopstate是专门用来监听浏览器前进后退的，不仅可以支持hash，非hash的同源
url 也支持。
9、HTML5离线缓存
HTML5离线缓存又叫Application
Cache，是从浏览器的缓存中分出来的一块缓存区，如果要在这个缓存中保存数据，可以使用一个描述文件（manifest file），列出要下载和缓存的资源。
manifest 文件是简单的文本文件，它告知浏览器被缓存的内容（以及不缓存的内容）。manifest 文件可分为三个部分：
- CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存
- NETWORK - 在此标题下列出的文件需要与服务器的连接，且不会被缓存
- FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面（比如 404 页面）
离线缓存为应用带来三个优势：
离线浏览 - 用户可在应用离线时使用它们
速度 - 已缓存资源加载得更快
减少服务器负载 - 浏览器将只从服务器下载更新过或更改过的资源。
10、Web语义化 和 SEO
Web语义化是指使用语义恰当的标签，使页面有良好的结构，页面元素有含义，能够让人和搜索引擎都容易理解。
SEO是指在了解搜索引擎自然排名机制的基础之上，对网站进行内部及外部的调整优化，改进网站在搜索引擎中关键词的自然排名，获得更多的展现量，吸引更多目标客户点击访问网站，从而达到互联网营销及品牌建设的目标。
搜索引擎通过爬虫技术获取的页面就是由一堆 html 标签组成的代码，人可以通过可视化的方式来判断页面上哪些内容是重点，而机器做不到。
但搜索引擎会根据标签的含义来判断内容的权重，因此，在合适的位置使用恰当的标签，使整个页面的语义明确，结构清晰，搜索引擎才能正确识别页面中的重要内容，并予以较高的权值。比如h1~h6这几个标签在SEO中的权值非常高，用它们作页面的标题就是一个简单的SEO优化。
*请认真填写需求信息，我们会在24小时内与您取得联系。
