整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
譯 ｜ 核子可樂、Tina
技術(shù)和軟件開發(fā)領(lǐng)域存在一種有趣的現(xiàn)象，就是同樣的模式迭起興衰、周而復(fù)始。
過去Web非常簡單。URL 指向服務(wù)器，服務(wù)器將數(shù)據(jù)混合成 html，然后在瀏覽器上呈現(xiàn)該響應(yīng)。圍繞這種簡單范式，誕生了各種Javascript框架，以前可能需要數(shù)月時間完成的一個應(yīng)用程序基本功能，現(xiàn)在借助這些框架創(chuàng)建相對復(fù)雜的項(xiàng)目卻只需要數(shù)小時，我們節(jié)省了很多時間，從而可以將更多精力花在業(yè)務(wù)邏輯和應(yīng)用程序設(shè)計(jì)上。
但隨著 Web 不斷地發(fā)展，Javascript 失控了。不知何故，我們決定向用戶拋出大量 App，并在使用時發(fā)出不斷增加的網(wǎng)絡(luò)請求；不知何故，為了生成 html，我們必須使用 JSON，發(fā)出數(shù)十個網(wǎng)絡(luò)請求，丟棄我們在這些請求中獲得的大部分?jǐn)?shù)據(jù)，用一個越來越不透明的 JavaScript 框架黑匣子將 JSON 轉(zhuǎn)換為 html，然后將新的 html 修補(bǔ)到 DOM 中......
難道大家快忘記了我們可以在服務(wù)器上渲染 html 嗎？更快、更一致、更接近應(yīng)用程序的實(shí)際狀態(tài)，并且不會向用戶設(shè)備發(fā)送任何不必要的數(shù)據(jù)？但是如果沒有 Javascript，我們必須在每次操作時重新加載頁面。
現(xiàn)在，有一個新的庫出現(xiàn)了，摒棄了定制化的方法，這就是 htmx。作為 Web 開發(fā)未來理念的一種實(shí)現(xiàn)，它的原理很簡單：
htmx 出現(xiàn)在 2020 年，創(chuàng)建者 Carson Gross 說 htmx 來源自他于 2013 年研究的一個項(xiàng)目 intercooler.js。2020 年，他重寫了不依賴 jQuery 的 intercooler.js，并將其重命名為 htmx。然后他驚訝的發(fā)現(xiàn) Django 社區(qū)迅速并戲劇性地接受了它！
圖片來源：https://lp.jetbrains.com/django-developer-survey-2021-486/
Carson Gross 認(rèn)為 htmx 設(shè)法抓住了開發(fā)者對現(xiàn)有 Javascript 框架不滿的浪潮，“這些框架非常復(fù)雜，并且經(jīng)常將 Django 變成一個愚蠢的 JSON 生產(chǎn)者”，而 htmx 與開箱即用的 Django 配合得更好，因?yàn)樗ㄟ^ html 與服務(wù)器交互，而 Django 非常擅長生成 html。
對于 htmx 的迅速走紅，Carson Gross 發(fā)出了一聲感嘆：這真是“十年窗下無人問，一舉成名天下知（this is another example of a decade-long overnight success）”。
可以肯定的一點(diǎn)是 htmx 絕對能用，單從理論上講，這個方法確實(shí)值得稱道。但軟件問題終究要?dú)w結(jié)于實(shí)踐效果：效果好嗎，能不能給前端開發(fā)帶來改善？
在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他們在真實(shí) SaaS 產(chǎn)品上實(shí)現(xiàn)了從 React 到 htmx 的遷移，而且效果非常好，堪稱“一切 htmx 演示之母”（視頻地址：https://www.youtube.com/watch?v=3GObi93tjZI）。
Contexte 的項(xiàng)目開始于 2017 年，其后端相當(dāng)復(fù)雜，前端 UI 也非常豐富，但團(tuán)隊(duì)非常小。所以他們在一開始的時候跟隨潮流選擇了 React 來“構(gòu)建 API 綁定 SPA、實(shí)現(xiàn)客戶端狀態(tài)管理、前后端狀態(tài)分離”等。但實(shí)際應(yīng)用中，因?yàn)?API 設(shè)計(jì)不當(dāng)，DOM 樹太深，又需要加載很多信息，導(dǎo)致 UI“非常非常緩慢”。在敏捷開發(fā)的要求下，團(tuán)隊(duì)里唯一的 Javascript 專家對項(xiàng)目的復(fù)雜性表現(xiàn)得一無所措，因此他們決定試試 htmx。
于是我們決定大膽嘗試，花幾個月時間用簡單的 Django 模板和 htmx 替換掉了 SaaS 產(chǎn)品中已經(jīng)使用兩年的 React UI。這里我們分享了一些相關(guān)經(jīng)驗(yàn)，公布各項(xiàng)具體指標(biāo)，希望能幫同樣關(guān)注 htmx 的朋友們找到說服 CTO 的理由！
6. 將 Web 構(gòu)建時間縮短了 88%（由 40 秒縮短至 5 秒）
7. 首次加載交互時間縮短了 50% 至 60%（由 2 到 6 秒，縮短至 1 到 2 秒）
8. 使用 htmx 時可以配合更大的數(shù)據(jù)集，超越 React 的處理極限
9. Web 應(yīng)用程序的內(nèi)存使用量減少了 46%（由 75 MB 降低至 40 MB）
這些數(shù)字令人頗為意外，也反映出 Contexte 應(yīng)用程序高度契合超媒體的這一客觀結(jié)果：這是一款以內(nèi)容為中心的應(yīng)用程序，用于顯示大量文本和圖像。很明顯，其他 Web 應(yīng)用程序在遷移之后恐怕很難有同樣夸張的提升幅度。
但一些開發(fā)者仍然相信，大部分應(yīng)用程序在采用超媒體 /htmx 方法之后，肯定也迎來顯著的改善，至少在部分系統(tǒng)中大受裨益。
可能很多朋友沒有注意，移植本身對團(tuán)隊(duì)結(jié)構(gòu)也有直接影響。在 Contexte 使用 React 的時候，后端與前端之間存在硬性割裂，其中兩位開發(fā)者全職管理后端，一位開發(fā)者單純管理前端，另有一名開發(fā)者負(fù)責(zé)“全棧”。（這里的「全棧」，代表這位開發(fā)者能夠輕松接手前端和后端工作，因此能夠在整個「棧」上獨(dú)立開發(fā)功能。）
而在移植至 htmx 之后，整個團(tuán)隊(duì)全都成了“全棧”開發(fā)人員。于是每位團(tuán)隊(duì)成員都更高效，能夠貢獻(xiàn)出更多價值。這也讓開發(fā)變得更有樂趣，因?yàn)殚_發(fā)人員自己就能掌握完整功能。最后，轉(zhuǎn)向 htmx 也讓軟件優(yōu)化度上了一個臺階，現(xiàn)在開發(fā)人員可以在棧內(nèi)的任意位置進(jìn)行優(yōu)化，無需與其他開發(fā)者提前協(xié)調(diào)。
如今，單頁應(yīng)用（SPA）可謂風(fēng)靡一時：配合 React、Redux 或 Angular 等庫的 JS 或 TS 密集型前端，已經(jīng)成為創(chuàng)建 Web 應(yīng)用程序的主流方式。以一個需要轉(zhuǎn)譯成 JS 的 SPA 應(yīng)用為例：
但 htmx 風(fēng)潮已經(jīng)襲來，人們開始強(qiáng)調(diào)一種“傻瓜客戶端”方法，即由服務(wù)器生成 html 本體并發(fā)送至客戶端，意味著 UI 事件會被發(fā)送至服務(wù)器進(jìn)行處理。
用這個例子進(jìn)行前后對比，我們就會看到前者涉及的活動部件更多。從客戶端角度出發(fā)，后者其實(shí)回避了定制化客戶端技術(shù)，采取更簡單的方法將原本只作為數(shù)據(jù)引擎的服務(wù)器變成了視圖引擎。
后一種方法被稱為 AJAX（異步 JavaScript 與 XML）。這種簡單思路能夠讓 Web 應(yīng)用程序獲得更高的響應(yīng)性體驗(yàn)，同時消除了糟糕的“回發(fā)”（postback，即網(wǎng)頁完全刷新），由此回避了極其低效的“viewstate”等.NET 技術(shù)。
htmx 在很多方面都體現(xiàn)出對 AJAX 思路的回歸，最大的區(qū)別就是它僅僅作為新的聲明性 html 屬性出現(xiàn)，負(fù)責(zé)指示觸發(fā)條件是什么、要發(fā)布到哪個端點(diǎn)等。
另一個得到簡化的元素是物理應(yīng)用程序的結(jié)構(gòu)與構(gòu)建管道。因?yàn)椴辉偕婕笆止ぞ帉?JS，而且整個應(yīng)用程序都基于服務(wù)器，因此不再對 JS 壓縮器、捆綁器和轉(zhuǎn)譯器做（即時）要求。就連客戶端項(xiàng)目也能解放出來，一切都由 Web 服務(wù)器項(xiàng)目負(fù)責(zé)完成，所有應(yīng)用程序代碼都在.NET 之上運(yùn)行。從這個角度來看，這與高度依賴服務(wù)器的 Blazor Server 編程模型倒是頗有異曲同工之妙。
技術(shù)和軟件開發(fā)領(lǐng)域存在一種有趣的現(xiàn)象，就是同樣的模式迭起興衰、周而復(fù)始。隨著 SPA 的興起，人們一度以為 AJAX 已經(jīng)過氣了，但其基本思路如今正卷土重來。這其中當(dāng)然會有不同的權(quán)衡，例如更高的服務(wù)器負(fù)載和網(wǎng)絡(luò)流量（畢竟現(xiàn)在我們發(fā)送的是數(shù)據(jù)視圖，而不只是數(shù)據(jù)），但能讓開發(fā)者多個選擇肯定不是壞事。
雖然不敢確定這種趨勢是否適用于包含豐富用戶體驗(yàn)的高復(fù)雜度應(yīng)用程序，但毫無疑問，相當(dāng)一部分 Web 應(yīng)用程序并不需要完整的 SPA 結(jié)構(gòu)。對于這類用例，簡單的 htmx 應(yīng)用程序可能就是最好的解決方案。
參考鏈接：
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編譯，未經(jīng)許可禁止轉(zhuǎn)載。
長不看版：Snowpack v3.0 將于 2021 年 1 月 6 日發(fā)布（也是該版本最初公布的一周年紀(jì)念日）。這是我們最重大的一次版本更新，其中有一些重要的新特性，包括一種按需加載 npm 導(dǎo)入的新方法，可以完全跳過前端的 npm install 步驟。
激動人心的是，大家現(xiàn)在就可以開始試用新版了！
Snowpack v3 的重點(diǎn)是完善和正式發(fā)布四項(xiàng)已有特性，這些特性在當(dāng)前版本的 Snowpack（v2.18.0）中通過 experiments 標(biāo)志提供：
Snowpack 一直在努力探索前端開發(fā)的邊界，這個版本也是如此。Snowpack v3.0 引入了一項(xiàng)令人興奮的新特性，可加快并簡化你的開發(fā)工作流程。
一般來說，JavaScript 依賴項(xiàng)是由包管理器 CLI（如 npm、yarn 或 pnpm）在本地安裝和管理的。程序包經(jīng)常帶有不相關(guān)的文件，并且?guī)缀鯖]有哪個包能直接在瀏覽器中運(yùn)行。我們需要額外的步驟來處理、構(gòu)建和打包這些安裝進(jìn)來的軟件包，才能讓它們運(yùn)行在瀏覽器中。
我們可以簡化這一過程嗎？如果 Snowpack 可以完全跳過“npm install”步驟，并通過 ESM 按需獲取我們需要的，預(yù)構(gòu)建的包代碼，這是不是非常令人期待？
// 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 包當(dāng)作 ESM 處理。Snowpack、Deno 和所有主要瀏覽器都能很好地支持通過 URL 導(dǎo)入依賴項(xiàng)。但是，將這些 URL 直接寫入源代碼的方法并不好用，并且如果沒有網(wǎng)絡(luò)連接就無法開發(fā)了。
Snowpack v3.0 融合了兩個方面的優(yōu)勢：在你自己的源代碼中獲得 import 'react'的簡單性，并讓 Snowpack 在后臺獲取這些依賴項(xiàng)，這些依賴項(xiàng)已預(yù)構(gòu)建完畢并可以在瀏覽器中運(yùn)行。Snowpack 會自動為你緩存所有內(nèi)容，因此你可以脫機(jī)工作，而無需依賴 Skypack。
與傳統(tǒng)的“npm install”方法相比，這種機(jī)制有很多優(yōu)點(diǎn)：
如果這一切聽起來太不可思議了，請放心。想要使用它的話，這是 100％ opt-in 的行為。默認(rèn)情況下，Snowpack 會像往常一樣繼續(xù)將 npm 包依賴項(xiàng)從項(xiàng)目 node_modules 目錄中拉出來。
請查閱我們的流式NPM導(dǎo)入指南，了解如何在已有的項(xiàng)目中啟用這一新行為。在將來的發(fā)行版中，我們希望對定制的 ESM 軟件包源和其他 CDN 開放此特性。
esbuild 太令人震驚了：它的性能比大多數(shù)流行的打包器快 100 倍，比 Parcel 快 300 倍（根據(jù) esbuild 自己的基準(zhǔn)測試）。esbuild 用 Go 編寫，而 Go 是一種編譯語言，可以并行化繁重的打包任務(wù)負(fù)載，而其他流行的打包程序（用 JavaScript 編寫）是做不到的。
Snowpack 已在內(nèi)部使用 esbuild，作為我們 JavaScript、TypeScript 和 JSX 文件的默認(rèn)單文件構(gòu)建器。Snowpack v3.0 更進(jìn)一步，加入了新的內(nèi)置構(gòu)建優(yōu)化管道。為生產(chǎn)環(huán)境打包、縮小和轉(zhuǎn)譯你的站點(diǎn)時，它需要的時間只有其他打包器的 1/100。
今天 Snowpack 之所以可以采用采用 esbuild，是因?yàn)槲覀兒茉缇蛯Υ虬奈磥硗断铝速€注：打包是一種構(gòu)建后的優(yōu)化步驟，而不是承載其他一切內(nèi)容的核心基礎(chǔ)。由于早期的這一設(shè)計(jì)決策，esbuild 可以像其他打包器一樣輕松地插入和換出你的 Snowpack 構(gòu)建。
esbuild 仍算是一個年輕的項(xiàng)目，但它的未來看起來很有希望。同時，我們還將在很長的一段時間內(nèi)繼續(xù)投資現(xiàn)有的 Webpack & Rollup 打包插件。
請查看我們最新的《優(yōu)化Snowpack構(gòu)建指南》中的 experiments.optimize 選項(xiàng)來開始嘗試。
Snowpack 新加入的 experiments.routes 配置使你可以定義讓開發(fā)環(huán)境與生產(chǎn)保持一致的路由。這一特性解鎖了一些有趣的新用例，包括：
Snowpack 已經(jīng)支持 API 代理和 SPA 回退有一段時間了，而這一新特性會將它們組合在一起，成為一個單一的、富有表現(xiàn)力的新 API。
Snowpack 的全新 JavaScriptAPI 可讓你對 Snowpack 的開發(fā)服務(wù)器和構(gòu)建管道進(jìn)行更高級別的控制，從而幫助你在 Snowpack 上構(gòu)建更強(qiáng)大的集成，以解鎖新的開發(fā)工具和服務(wù)端渲染（SSR）解決方案。
Svelte 團(tuán)隊(duì)最近發(fā)布的 SvelteKit 引發(fā)了關(guān)注：這是 Svelte 應(yīng)用的官方 zero-effort SSR 應(yīng)用框架。SvelteKit 由 Snowpack 提供內(nèi)部支持，使用了我們?nèi)碌?JavaScript API 來管理你的構(gòu)建管道并按需構(gòu)建文件。Snowpack 加快了開發(fā)速度，并幫助將 SvelteKit 的啟動時間減少到了幾乎可以忽略不計(jì)。
請查看我們新的JavaScript API參考，開始在 Snowpack 上構(gòu)建你自己的自定義集成。或者通讀我們關(guān)于服務(wù)端渲染的指南，開始使用用于生產(chǎn)的自定義 SSR 集成。
你可以通過以下命令安裝 Snowpack v3.0 RC 版本：
npm install snowpack@next由于所有 v3.0 特性在現(xiàn)在的版本中都包括了，因此我們現(xiàn)有的文檔站點(diǎn)同時適用于 v2 和 v3。目前，只有非常舊的，沒有文檔支持的舊行為在 next 分支中移除了。隨著我們接近正式發(fā)布日期，實(shí)驗(yàn)標(biāo)志下的特性可能會繼續(xù)更改。到今年年底，這些特性將從實(shí)驗(yàn)標(biāo)志后移到下一個 v3.0 分支的頂級配置對象中。
請?jiān)?snowpack.dev 上了解更多信息。
原文鏈接：
Snowpack 3 Release
https://www.snowpack.dev/posts/2020-12-03-snowpack-3-release-candidate?utm_source=tinyjs&utm_medium=email
微軟發(fā)布.NET 5.0 RC1，未來將只有一個.NET-InfoQ
關(guān)注我并轉(zhuǎn)發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費(fèi)獲得InfoQ價值4999元迷你書，點(diǎn)擊文末「了解更多」，即可移步InfoQ官網(wǎng)，獲取最新資訊～
eb前端技術(shù)由html、css和 javascript三大部分構(gòu)成，是一個龐大而復(fù)雜的技術(shù)體系，其復(fù)雜程度不低于任何一門后端語言。而我們在學(xué)習(xí)它的時候往往是先從某一個點(diǎn)切入，然后不斷地接觸和學(xué)習(xí)新的知識點(diǎn)，因此對于初學(xué)者很難理清楚整個體系的脈絡(luò)結(jié)構(gòu)。本文將對Web前端知識體系進(jìn)行簡單的梳理，對應(yīng)的每個知識點(diǎn)點(diǎn)到為止，不作詳細(xì)介紹。目的是幫助大家審查自己的知識結(jié)構(gòu)是否完善，如有遺漏或不正確的地方，希望共勉。
HTML 篇
1、BOM
BOM 是 Browser Object Model
的縮寫，即瀏覽器對象模型，當(dāng)一個瀏覽器頁面初始化時，會在內(nèi)存創(chuàng)建一個全局的對象，用以描述當(dāng)前窗口的屬性和狀態(tài)，這個全局對象被稱為瀏覽器對象模型，即BOM。BOM的核心對象就是window，window
對象也是BOM的頂級對象，其中包含了瀏覽器的 6個核心模塊：
document -
即文檔對象，渲染引擎在解析HTML代碼時，會為每一個元素生成對應(yīng)的DOM對象，由于元素之間有層級關(guān)系，因此整個HTML代碼解析完以后，會生成一個由不同節(jié)點(diǎn)組成的樹形結(jié)構(gòu)，俗稱DOM樹，document
用于描述DOM樹的狀態(tài)和屬性，并提供了很多操作DOM的API。
frames - HTML 子框架，即在瀏覽器里嵌入另一個窗口，父框架和子框架擁有獨(dú)立的作用域和上下文。
history - 以棧(FIFO)的形式保存著頁面被訪問的歷史記錄，頁面前進(jìn)即入棧，頁面返回即出棧。
location - 提供了當(dāng)前窗口中加載的文檔相關(guān)信息以及一些導(dǎo)航功能。
navigator - 用來描述瀏覽器本身，包括瀏覽器的名稱、版本、語言、系統(tǒng)平臺、用戶特性字符串等信息。
screen - 提供了瀏覽器顯示屏幕的相關(guān)屬性，比如顯示屏幕的寬度和高度，可用寬度和高度。
2、DOM 系統(tǒng)
DOM 是 Document Object Model 的縮寫，即 文檔對象模型，是所有瀏覽器公共遵守的標(biāo)準(zhǔn)，DOM
將HTML和XML文檔映射成一個由不同節(jié)點(diǎn)組成的樹型結(jié)構(gòu)，俗稱DOM樹。其核心對象是document，用于描述DOM樹的狀態(tài)和屬性，并提供對應(yīng)的DOM操作API。隨著歷史的發(fā)展，DOM
被劃分為1級、2級、3級，共3個級別：
1級DOM - 在1998年10月份成為W3C的提議，由DOM核心與DOM
HTML兩個模塊組成。DOM核心能映射以XML為基礎(chǔ)的文檔結(jié)構(gòu)，允許獲取和操作文檔的任意部分。DOM
HTML通過添加HTML專用的對象與函數(shù)對DOM核心進(jìn)行了擴(kuò)展。
2級DOM - 鑒于1級DOM僅以映射文檔結(jié)構(gòu)為目標(biāo)，DOM
2級面向更為寬廣。通過對原有DOM的擴(kuò)展，2級DOM通過對象接口增加了對鼠標(biāo)和用戶界面事件（DHTML長期支持鼠標(biāo)與用戶界面事件）、范圍、遍歷（重復(fù)執(zhí)行DOM文檔）和層疊樣式表（CSS）的支持。同時也對DOM
1的核心進(jìn)行了擴(kuò)展，從而可支持XML命名空間。
3級DOM -
通過引入統(tǒng)一方式載入和保存文檔和文檔驗(yàn)證方法對DOM進(jìn)行進(jìn)一步擴(kuò)展，DOM3包含一個名為“DOM載入與保存”的新模塊，DOM核心擴(kuò)展后可支持XML1.0的所有內(nèi)容，包括XML
Infoset、 XPath、和XML Base。
瀏覽器對不同級別DOM的支持情況如下所示：
從圖中可以看出，移動端常用的 webkit 內(nèi)核瀏覽器目前只支持DOM2，而不支持DOM3 。
新手福利獲取方式：
1.在你手機(jī)的右上角有【關(guān)注】選項(xiàng)，或點(diǎn)擊我的頭像，點(diǎn)擊關(guān)注！（關(guān)注我）
2.關(guān)注后，手機(jī)客戶端點(diǎn)擊我的主頁面，右上角有私信，請私信發(fā)我：html
其實(shí)作為一個開發(fā)者，有一個學(xué)習(xí)的氛圍跟一個交流圈子特別重要這里請私信我“html”不管你是小白還是大牛歡迎入住大家一起交流成長。小編會在里面不定期分享干貨源碼，包括我精心整理的一份零基礎(chǔ)教程。歡迎各位感興趣的的小伙伴。
學(xué)習(xí)思路：
3、事件系統(tǒng)
事件是用戶與頁面交互的基礎(chǔ)，到目前為止，DOM事件從PC端的 鼠標(biāo)事件(mouse) 發(fā)展到了 移動端的 觸摸事件(touch) 和
手勢事件(guesture)，touch事件描述了手指在屏幕操作的每一個細(xì)節(jié)，guesture 則是描述多手指操作時更為復(fù)雜的情況，總結(jié)如下：
第一根手指放下，觸發(fā) touchstart，除此之外什么都不會發(fā)生
手指滑動時，觸發(fā)touchmove
第二根手指放下，觸發(fā) gesturestart
觸發(fā)第二根手指的 touchstart
立即觸發(fā) gesturechange
任意手指移動，持續(xù)觸發(fā) gesturechange
第二根手指彈起時，觸發(fā) gestureend，以后將不會再觸發(fā) gesturechange
觸發(fā)第二根手指的 touchend
觸發(fā)touchstart (多根手指在屏幕上，提起一根，會刷新一次全局touch) _ ___
彈起第一根手指，觸發(fā) touchend
更多關(guān)于手勢事件的介紹請參考：
gesture事件處理復(fù)雜手勢
DOM2.0 模型將事件處理流程分為三個階段，即 事件捕獲階段 、 事件處理階段 、 事件冒泡階段， 如圖所示：
事件捕獲 ：當(dāng)用戶觸發(fā)點(diǎn)擊事件后，頂層對象document 就會發(fā)出一個事件流，從最外層的DOM節(jié)點(diǎn)向目標(biāo)元素節(jié)點(diǎn)傳遞，最終到達(dá)目標(biāo)元素。
事件處理 ：當(dāng)?shù)竭_(dá)目標(biāo)元素之后，執(zhí)行目標(biāo)元素綁定的處理函數(shù)。如果沒有綁定監(jiān)聽函數(shù)，則不做任何處理。
事件冒泡 ：事件流從目標(biāo)元素開始，向最外層DOM節(jié)點(diǎn)傳遞，途中如果有節(jié)點(diǎn)綁定了事件處理函數(shù)，這些函數(shù)就會被執(zhí)行。
利用事件冒泡原理可以實(shí)現(xiàn) 事件委托
，所謂事件委托，就是在父元素上添加事件監(jiān)聽器，用以監(jiān)聽和處理子元素的事件，避免重復(fù)為子元素綁定相同的事件。當(dāng)目標(biāo)元素的事件被觸發(fā)以后，這個事件就從目標(biāo)元素開始，向最外層元素傳遞，最終冒泡到父元素上，父元素再通過event.target
獲取到這個目標(biāo)元素，這樣做的好處是，父元素只需綁定一個事件監(jiān)聽，就可以對所有子元素的事件進(jìn)行處理了，從而減少了不必要的事件綁定，對頁面性能有一定的提升。
4、HTML解析過程
瀏覽器加載 html 文件以后，渲染引擎會從上往下，一步步來解析HTML標(biāo)簽，大致過程如下：
用戶輸入網(wǎng)址，瀏覽器向服務(wù)器發(fā)出請求，服務(wù)器返回html文件；
渲染引擎開始解析 html 標(biāo)簽，并將標(biāo)簽轉(zhuǎn)化為DOM節(jié)點(diǎn)，生成 DOM樹；
如果head 標(biāo)簽中引用了外部css文件，則發(fā)出css文件請求，服務(wù)器返回該文件，該過程會阻塞后面的解析；
如果引用了外部 js 文件，則發(fā)出 js 文件請求，服務(wù)器返回后立即執(zhí)行該腳本，這個過程也會阻塞html的解析；
引擎開始解析 body 里面的內(nèi)容，如果標(biāo)簽里引用了css 樣式，就需要解析剛才下載好的css文件，然后用css來設(shè)置標(biāo)簽的樣式屬性，并生成渲染樹；
如果 body 中的 img 標(biāo)簽引用了圖片資源，則立即向服務(wù)器發(fā)出請求，此時引擎不會等待圖片下載完畢，而是繼續(xù)解析后面的標(biāo)簽；
服務(wù)器返回圖片文件，由于圖片需要占用一定的空間，會影響到后面元素的排版，因此引擎需要重新渲染這部分內(nèi)容；
如果此時 js 腳本中運(yùn)行了 style.display="none"，布局被改變，引擎也需要重新渲染這部分代碼；
直到 html 結(jié)束標(biāo)簽為止，頁面解析完畢。
5、重繪 和 回流
當(dāng)渲染樹中的一部分(或全部)因?yàn)樵氐囊?guī)模尺寸，布局，隱藏等改變而需要重新構(gòu)建。這就稱為回流。比如上面的img文件加載完成后就會引起回流，每個頁面至少需要一次回流，就是在頁面第一次加載的時候。
當(dāng)渲染樹中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀，風(fēng)格，而不會影響布局的，比如 background-color。則就叫稱為重繪。
從上面可以看出，回流必將引起重繪，而重繪不一定會引起回流。會引起重繪和回流的操作如下：
添加、刪除元素(回流+重繪)
隱藏元素，display:none(回流+重繪)，visibility:hidden(只重繪，不回流)
移動元素，比如改變top,left的值，或者移動元素到另外一個父元素中。(重繪+回流)
對style的操作(對不同的屬性操作，影響不一樣)
還有一種是用戶的操作，比如改變?yōu)g覽器大小，改變?yōu)g覽器的字體大小等(回流+重繪)
另外，transform
操作不會引起重繪和回流，是一種高效率的渲染。這是因?yàn)閠ransform屬于合成屬性，對合成屬性進(jìn)行transition/animation
動畫時將會創(chuàng)建一個合成層，這使得動畫元素在一個獨(dú)立的層中進(jìn)行渲染，當(dāng)元素的內(nèi)容沒有發(fā)生改變，就沒必要進(jìn)行重繪，瀏覽器會通過重新復(fù)合來創(chuàng)建動畫幀。
6、本地存儲
本地存儲最原始的方式就是 cookie,cookie 是存放在本地瀏覽器的一段文本，數(shù)據(jù)以鍵值對的形式保存，可以設(shè)置過期時間。 但是 cookie
不適合大量數(shù)據(jù)的存儲，因?yàn)槊空埱笠淮雾撁妫琧ookie 都會發(fā)送給服務(wù)器，這使得 cookie
速度很慢而且效率也不高。因此cookie的大小被限制為4k左右(不同瀏覽器可能不同,分HOST)，如下所示：
Firefox和Safari允許cookie多達(dá)4097個字節(jié)，包括名(name)、值(value) 和 等號。
Opera允許cookie多達(dá)4096個字節(jié)，包括：名(name)、值(value) 和 等號。
Internet Explorer允許cookie多達(dá)4095個字節(jié)，包括：名(name)、值(value) 和 等號。
在所有瀏覽器中，任何cookie大小超過限制都被忽略，且永遠(yuǎn)不會被設(shè)置。
html5 提供了兩種在客戶端存儲數(shù)據(jù)的新方法：localStorage 和 sessionStorage, 它們都是以key/value
的形式來存儲數(shù)據(jù)，前者是永久存儲，后者的存儲期限僅限于瀏覽器會話(session)，即當(dāng)瀏覽器窗口關(guān)閉后，sessionStorage中的數(shù)據(jù)被清除。
localStorage的存儲空間大約5M左右(不同瀏覽器可能不同，分
HOST)，這個相當(dāng)于一個5M大小的前端數(shù)據(jù)庫，相比于cookie，可以節(jié)約帶寬，但localStorage在瀏覽器隱私模式下是不可讀取的，當(dāng)存儲數(shù)據(jù)超過了localStorage
的存儲空間后會拋出異常。
此外，H5還提供了逆天的websql和
indexedDB，允許前端以關(guān)系型數(shù)據(jù)庫的方式來存儲本地?cái)?shù)據(jù)，相對來說，這個功能目前應(yīng)用的場景比較少，此處不作介紹。
7、瀏覽器緩存機(jī)制
瀏覽器緩存機(jī)制是指通過 HTTP 協(xié)議頭里的 Cache-Control (或 Expires) 和 Last-Modified (或 Etag)
等字段來控制文件緩存的機(jī)制。
Cache-Control 用于控制文件在本地緩存有效時長。最常見的，比如服務(wù)器回包：Cache-Control:max-age=600
表示文件在本地應(yīng)該緩存，且有效時長是600秒 (從發(fā)出請求算起)。在接下來600秒內(nèi)，如果有請求這個資源，瀏覽器不會發(fā)出 HTTP
請求，而是直接使用本地緩存的文件。
Last-Modified 是標(biāo)識文件在服務(wù)器上的最新更新時間。下次請求時，如果文件緩存過期，瀏覽器通過 If-Modified-Since
字段帶上這個時間，發(fā)送給服務(wù)器，由服務(wù)器比較時間戳來判斷文件是否有修改。如果沒有修改，服務(wù)器返回304告訴瀏覽器繼續(xù)使用緩存；如果有修改，則返回200，同時返回最新的文件。
Cache-Control 通常與 Last-Modified 一起使用。一個用于控制緩存有效時間，一個在緩存失效后，向服務(wù)查詢是否有更新。
Cache-Control 還有一個同功能的字段：Expires。Expires 的值一個絕對的時間點(diǎn)，如：Expires: Thu, 10 Nov
2015 08:45:11 GMT，表示在這個時間點(diǎn)之前，緩存都是有效的。
Expires 是 HTTP1.0 標(biāo)準(zhǔn)中的字段，Cache-Control 是 HTTP1.1
標(biāo)準(zhǔn)中新加的字段，功能一樣，都是控制緩存的有效時間。當(dāng)這兩個字段同時出現(xiàn)時，Cache-Control 是高優(yōu)化級的。
Etag 也是和 Last-Modified 一樣，對文件進(jìn)行標(biāo)識的字段。不同的是，Etag
的取值是一個對文件進(jìn)行標(biāo)識的特征字串。在向服務(wù)器查詢文件是否有更新時，瀏覽器通過 If-None-Match
字段把特征字串發(fā)送給服務(wù)器，由服務(wù)器和文件最新特征字串進(jìn)行匹配，來判斷文件是否有更新。沒有更新回包304，有更新回包200。Etag 和
Last-Modified 可根據(jù)需求使用一個或兩個同時使用。兩個同時使用時，只要滿足基中一個條件，就認(rèn)為文件沒有更新。
另外有兩種特殊的情況：
手動刷新頁面(F5)，瀏覽器會直接認(rèn)為緩存已經(jīng)過期(可能緩存還沒有過期)，在請求中加上字段：Cache-Control:max-age=0，發(fā)包向服務(wù)器查詢是否有文件是否有更新。
強(qiáng)制刷新頁面(Ctrl+F5)，瀏覽器會直接忽略本地的緩存(有緩存也會認(rèn)為本地沒有緩存)，在請求中加上字段：Cache-Control:no-cache
(或 Pragma:no-cache)，發(fā)包向服務(wù)重新拉取文件。
8、History
用戶訪問網(wǎng)頁的歷史記錄通常會被保存在一個類似于棧的對象中，即history對象，點(diǎn)擊返回就出棧，跳下一頁就入棧。 它提供了以下方法來操作頁面的前進(jìn)和后退：
window.history.back( ) 返回到上一個頁面
window.history.forward( ) 進(jìn)入到下一個頁面
window.history.go( [delta] ) 跳轉(zhuǎn)到指定頁面
HTML5 對History Api 進(jìn)行了增強(qiáng)，新增了兩個Api 和一個事件，分別是pushState、replaceState 和
onpopstate：
pushState是往history對象里添加一個新的歷史記錄，即壓棧。
replaceState 是替換history對象中的當(dāng)前歷史記錄。
當(dāng)點(diǎn)擊瀏覽器后退按鈕或 js調(diào)用history.back 都會觸發(fā) onpopstate 事件。
與其類似的還有一個事件：onhashchange，onhashchange是老API，瀏覽器支持度高，本來是用來監(jiān)聽hash變化的，但可以被利用來做客戶端前進(jìn)和后退事件的監(jiān)聽，而onpopstate是專門用來監(jiān)聽瀏覽器前進(jìn)后退的，不僅可以支持hash，非hash的同源
url 也支持。
9、HTML5離線緩存
HTML5離線緩存又叫Application
Cache，是從瀏覽器的緩存中分出來的一塊緩存區(qū)，如果要在這個緩存中保存數(shù)據(jù)，可以使用一個描述文件（manifest file），列出要下載和緩存的資源。
manifest 文件是簡單的文本文件，它告知瀏覽器被緩存的內(nèi)容（以及不緩存的內(nèi)容）。manifest 文件可分為三個部分：
- CACHE MANIFEST - 在此標(biāo)題下列出的文件將在首次下載后進(jìn)行緩存
- NETWORK - 在此標(biāo)題下列出的文件需要與服務(wù)器的連接，且不會被緩存
- FALLBACK - 在此標(biāo)題下列出的文件規(guī)定當(dāng)頁面無法訪問時的回退頁面（比如 404 頁面）
離線緩存為應(yīng)用帶來三個優(yōu)勢：
離線瀏覽 - 用戶可在應(yīng)用離線時使用它們
速度 - 已緩存資源加載得更快
減少服務(wù)器負(fù)載 - 瀏覽器將只從服務(wù)器下載更新過或更改過的資源。
10、Web語義化 和 SEO
Web語義化是指使用語義恰當(dāng)?shù)臉?biāo)簽，使頁面有良好的結(jié)構(gòu)，頁面元素有含義，能夠讓人和搜索引擎都容易理解。
SEO是指在了解搜索引擎自然排名機(jī)制的基礎(chǔ)之上，對網(wǎng)站進(jìn)行內(nèi)部及外部的調(diào)整優(yōu)化，改進(jìn)網(wǎng)站在搜索引擎中關(guān)鍵詞的自然排名，獲得更多的展現(xiàn)量，吸引更多目標(biāo)客戶點(diǎn)擊訪問網(wǎng)站，從而達(dá)到互聯(lián)網(wǎng)營銷及品牌建設(shè)的目標(biāo)。
搜索引擎通過爬蟲技術(shù)獲取的頁面就是由一堆 html 標(biāo)簽組成的代碼，人可以通過可視化的方式來判斷頁面上哪些內(nèi)容是重點(diǎn)，而機(jī)器做不到。
但搜索引擎會根據(jù)標(biāo)簽的含義來判斷內(nèi)容的權(quán)重，因此，在合適的位置使用恰當(dāng)?shù)臉?biāo)簽，使整個頁面的語義明確，結(jié)構(gòu)清晰，搜索引擎才能正確識別頁面中的重要內(nèi)容，并予以較高的權(quán)值。比如h1~h6這幾個標(biāo)簽在SEO中的權(quán)值非常高，用它們作頁面的標(biāo)題就是一個簡單的SEO優(yōu)化。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
