歡迎來到本系列的第三部分，也是最後一部分，我們將探討老IE的退役以及這一事件對(duì)前端開發(fā)領(lǐng)域的影響。到目前為止，我們已經(jīng)介紹了可以安全丟棄的過時(shí)技術(shù)，以及現(xiàn)在在主流瀏覽器中完全原生支持的HTML5和CSS3屬性。今天，我們將重點(diǎn)介紹原生JavaScript技術(shù)以及其他不屬於上述類別的內(nèi)容。

再次感謝CanIUse.com，它是一個(gè)非常寶貴的資源。我還將重申上次的免責(zé)聲明：

本文與是否放棄對(duì)老IE的支持的決定無關(guān)。您必鬚根據(jù)您網(wǎng)站或應(yīng)用程序的具體細(xì)節(jié)自行做出決定。

話不多說，讓我們繼續(xù)！

關(guān)鍵要點(diǎn)

• 現(xiàn)代JavaScript API的採用：隨著Internet Explorer的退役，開發(fā)人員現(xiàn)在可以在主流瀏覽器中直接使用現(xiàn)代JavaScript API（例如Base64編碼和Blob構(gòu)建），而無需polyfill，從而提高性能和兼容性。
• 增強(qiáng)的通信功能：現(xiàn)代瀏覽器中Channel Messaging和WebSockets等API的可用性分別促進(jìn)了更有效的腳本間通信和瀏覽器與服務(wù)器之間的持久連接。
• ES6語法的引入：對(duì)ES6特性（例如const和let用於塊級(jí)變量聲明以及箭頭函數(shù)的普及）的支持允許開發(fā)人員編寫更簡(jiǎn)潔、更高效的代碼。
• 安全和隱私優(yōu)先：Web Cryptography API和內(nèi)容安全策略（CSP）現(xiàn)在已完全支持，為增強(qiáng)Web應(yīng)用程序的安全性用戶隱私提供了強(qiáng)大的工具。
• 性能優(yōu)化：Page Visibility API和requestAnimationFrame等新功能提高了Web應(yīng)用程序的效率，優(yōu)化了資源使用和動(dòng)畫性能。
• 未來安全的Web開發(fā)：隨著Internet Explorer的停用，開發(fā)人員無需受限於舊版瀏覽器的兼容性，可以充分利用HTML5、CSS3和JavaScript的全部潛力，從而為更具創(chuàng)新性和前瞻性的Web應(yīng)用程序鋪平道路。

1. JavaScript APIs

在本節(jié)中，我們將介紹相當(dāng)多的JavaScript特性、API和功能。它們有什麼共同點(diǎn)？它們都不能真正用於老IE，需要使用各種polyfill，或者必須通過各種其他框架和庫來實(shí)現(xiàn)其效果（如果可以實(shí)現(xiàn)的話）。在當(dāng)前環(huán)境（IE11 Edge）中，它們具有內(nèi)置於瀏覽器的原生支持，這意味著可以直接使用它們。

Base64編碼和解碼（btoa和atob）

Base64是Web上非常有用的工具。你們中的許多人可能已經(jīng)用它將字體或圖像嵌入到CSS中。另一個(gè)常見的用法是處理通常會(huì)干擾傳輸協(xié)議的各種資源。一個(gè)很好的例子是基本訪問身份驗(yàn)證，其中用戶名：密碼對(duì)使用Base64打包，然後發(fā)送到服務(wù)器。對(duì)編碼/解碼操作的原生支持意味著它們可以更快地執(zhí)行。以下是一些入門資源：

• MDN上的atob()和btoa()文檔
• Base64.js polyfill

Blob構(gòu)建

二進(jìn)制大對(duì)像或BLOB是存儲(chǔ)在數(shù)據(jù)庫管理系統(tǒng)中的單個(gè)實(shí)體中的原始數(shù)據(jù)的集合。它可以是音頻剪輯或圖像，以Base64格式存儲(chǔ)?；蛘呤且唤M圖像。在許多情況下，Blob字段用於數(shù)據(jù)結(jié)構(gòu)不如通過普通表或表模式（如JSON對(duì)象）表達(dá)得那麼嚴(yán)格的數(shù)據(jù)。你們中的一些人可能還記得Blob接口的祖先，即BlobBuilder。但是，這種方法已被棄用，強(qiáng)烈建議所有Blob操作都應(yīng)通過新的接口進(jìn)行。

最重要的是，由於此集合與文件非常相似，因此Blob對(duì)象的原生接口已被用作File()接口的基礎(chǔ)。因此，有一個(gè)名為“Blob URL”的不錯(cuò)功能，它允許開發(fā)人員為blob對(duì)象創(chuàng)建URL，這些URL可以在任何可以使用文件的地方使用?？紤]到這一點(diǎn)，原生支持現(xiàn)在涵蓋所有主流瀏覽器，這一點(diǎn)非常令人讚賞。

• MDN上的BLOB
• MDN上的BLOB URL
• JavaScript Blob和文件接口簡(jiǎn)介

Channel Messaging

通常，在不同瀏覽器上下文運(yùn)行的兩個(gè)腳本被禁止相互通信，以避免許多安全陷阱。但是，有時(shí)這種通信不僅是需要的，而且是真正必要的。這就是Channel Messaging API發(fā)揮作用的地方。此接口允許我們的兩個(gè)腳本通過雙向管道相互通信。這就像在同一個(gè)頻道上為每個(gè)人提供一個(gè)對(duì)講機(jī)。很巧妙，不是嗎？

• Dev.Opera上的HTML5 Web Messaging簡(jiǎn)介
• MDN上的MessageChannel

常量和塊級(jí)變量

const和let是ES6中定義數(shù)據(jù)的兩種新方法。雖然var定義具有全局或函數(shù)範(fàn)圍的變量，但新增內(nèi)容具有塊級(jí)範(fàn)圍。這意味著使用const和let創(chuàng)建的變量的範(fàn)圍僅限於定義它們的括號(hào)對(duì)內(nèi)。

雖然let定義了一個(gè)（除了範(fàn)圍之外）與經(jīng)典變量行為相同的變量，但常量（const）是對(duì)某個(gè)值的只讀引用。它不能重新賦值，不能重新定義，並且不能與同一範(fàn)圍內(nèi)的任何其他變量或函數(shù)共享相同的名稱。唯一的例外是當(dāng)常量是一個(gè)具有其自身屬性的對(duì)象時(shí)。這些屬性不受更改的保護(hù)，其行為類似於普通變量。

話雖如此，請(qǐng)查看在代碼中正確使用常量和塊級(jí)變量的方法：

• MDN上的常量
• MDN上的Let
• SitePoint上的準(zhǔn)備ECMAScript 6：let和const
• Wes Bos的ES6 let VS const變量

控制臺(tái)日誌記錄

大多數(shù)前端開發(fā)人員都會(huì)同意，當(dāng)腳本行為異常時(shí)，Web控制臺(tái)是手中最有用工具之一。然而，Internet Explorer本質(zhì)上整合它的速度很慢，只有版本10才開始提供完全支持?，F(xiàn)在，隨著老IE的退役，沒有什麼能阻止我們充分利用此功能。如果您需要刷新您的知識(shí)，甚至發(fā)現(xiàn)使用控制臺(tái)的新方法，請(qǐng)查看以下規(guī)範(fàn)：

• MDN上的控制臺(tái)

跨源資源共享

跨源資源共享（CORS）是一個(gè)HTML5 API，它允許請(qǐng)求來自其自身域外部的資源。它描述了一組HTTP標(biāo)頭，這些標(biāo)頭允許瀏覽器和服務(wù)器在授予特定權(quán)限時(shí)請(qǐng)求遠(yuǎn)程資源。以下資源是學(xué)習(xí)如何正確使用此功能的良好起點(diǎn)：

• Dev.Opera上使用跨源資源共享的DOM訪問控制
• MDN上的HTTP訪問控制（CORS）
• SitePoint上對(duì)CORS的深入了解

Web Cryptography API

如今，安全和隱私是任何應(yīng)用程序中最受追捧的兩個(gè)特性，這意味著良好的（且快速的）加密技術(shù)非常受重視?，F(xiàn)在，所有主流瀏覽器都一致支持Web Cryptography API，但I(xiàn)E11（它實(shí)現(xiàn)了舊版本的規(guī)範(fàn)）和Safari（它需要crypto.webkitSubtle前綴）除外。幸運(yùn)的是，某些特定功能（如隨機(jī)值的生成）的實(shí)現(xiàn)更好。因此，使用原生支持實(shí)現(xiàn)加密元素比以往任何時(shí)候都更容易。以下是一些關(guān)於如何正確執(zhí)行此操作的指南：

• MDN上的Crypto對(duì)象
• MDN上的getRandomValues
• GitHub上用於舊版瀏覽器的Web Cryptography API shim

國際化

如今，互聯(lián)網(wǎng)訪問的普遍性意味著訪問您網(wǎng)站的訪問者可以來自世界各地。由於人們更信任熟悉的事物，因此最好以他們的語言和他們習(xí)慣的格式呈現(xiàn)所有信息。這就是您需要國際化（也稱為i18n）和本地化（或L10n）的地方。這聽起來像是胡言亂語嗎？讓我們引用Aurelio De Rosa在他關(guān)於如何在JavaScript中實(shí)現(xiàn)國際化（i18n）的文章中的話：

國際化（也稱為i18n）是創(chuàng)建或轉(zhuǎn)換產(chǎn)品和服務(wù)的過程，以便它們可以輕鬆地適應(yīng)特定的本地語言和文化。本地化（也稱為L(zhǎng)10n）是為特定區(qū)域或語言調(diào)整國際化軟件的過程。換句話說，國際化是使您的軟件適應(yīng)支持多種文化（貨幣格式、日期格式等）的過程，而本地化是實(shí)現(xiàn)一種或多種文化的過程。

瀏覽器的支持比今年年初略好一些，Safari v10於9月份加入了行列。聽起來很有趣嗎？以下是一些讓您走上正軌的資源：

• MDN上的國際化API
• JavaScript國際化API – 簡(jiǎn)要介紹
• 如何在JavaScript中實(shí)現(xiàn)國際化（i18n）

處理媒體查詢

響應(yīng)式Web設(shè)計(jì)是當(dāng)前高效網(wǎng)站的標(biāo)準(zhǔn)，使其成為可能的關(guān)鍵特性是媒體查詢的存在。 matchmedia將媒體查詢從CSS引入JavaScript，為開發(fā)人員提供了更大的靈活性來優(yōu)化各種設(shè)備的內(nèi)容。一個(gè)很好的例子是處理移動(dòng)電話和平板電腦從縱向模式到橫向模式以及反向模式的更改。雖然有一個(gè)API可以處理設(shè)備方向的檢測(cè)，但大多數(shù)瀏覽器的支持都是部分的，只有Microsoft Edge提供完全支持。以下是一些關(guān)於此主題的入門資源：

• MDN上的測(cè)試媒體查詢
• MDN上的Window.matchMedia
• SitePoint上如何在JavaScript中使用媒體查詢

媒體源擴(kuò)展

媒體源擴(kuò)展（MSE）在不使用插件的情況下向視頻和音頻元素添加額外功能。這為您提供了自適應(yīng)媒體流、實(shí)時(shí)流、拼接視頻和視頻編輯等功能。自2013年9月以來，YouTube一直在其HTML5播放器中使用MSE。瀏覽器的支持也相當(dāng)好，只有iOS Safari和Opera Mini缺少此功能。僅當(dāng)在Windows 8 上使用時(shí)，IE11才具有完全支持。不幸的是，IE11/Win7用戶無法從這項(xiàng)技術(shù)中受益。無論您只是好奇還是真的想開始使用此API，您都會(huì)發(fā)現(xiàn)以下資源非常有用：

• MDN上的MediaSource API
• MSDN上的媒體源擴(kuò)展
• HTML5媒體源擴(kuò)展：將製作視頻帶到Web上（Smashing Magazine）

變異觀察器

JavaScript應(yīng)用程序每天都在變得越來越複雜。作為開發(fā)人員，您需要控制頁面上發(fā)生的更改，尤其是在DOM樹更改或“變異”的時(shí)間。對(duì)這種監(jiān)控的需求並非新鮮事物，實(shí)際上已經(jīng)存在了一種解決方案——變異事件。此接口的問題在於，作為事件，它們既是同步的（在調(diào)用時(shí)觸發(fā)，並可能阻止其他事件觸發(fā)），也必須通過DOM捕獲或冒泡。這反過來又會(huì)觸發(fā)其他事件，從而使JavaScript線程過載，並在某些特殊情況下生成整個(gè)級(jí)聯(lián)故障，導(dǎo)致瀏覽器崩潰。

因此，變異事件已被棄用並替換為變異觀察器。您可能會(huì)問，有什麼區(qū)別？首先也是最重要的一點(diǎn)是，觀察器是異步的。它們不會(huì)阻止您的腳本運(yùn)行。它們不是在每次變異時(shí)觸發(fā)，而是在主要活動(dòng)完成後批量傳遞結(jié)果。更重要的是，您可以微調(diào)觀察器以觀察節(jié)點(diǎn)的所有更改或僅觀察特定類別的更改（例如僅子列表的更改或僅屬性的更改等）。使用以下資源開始學(xué)習(xí)如何執(zhí)行此操作：

• MDN上的MutationObserver
• 了解變異觀察器
• SitePoint上正在發(fā)展的新變異

頁面可見性

選項(xiàng)卡瀏覽改變了我們與網(wǎng)絡(luò)交互的方式。許多人同時(shí)打開數(shù)十個(gè)頁面的情況並不少見。每個(gè)頁面都執(zhí)行自己的操作，運(yùn)行其腳本，下載其擁有的資源等等。即使一次只能激活一個(gè)選項(xiàng)卡，所有打開的頁面都在消耗CPU時(shí)間和帶寬。某些應(yīng)用程序可能定期通過連接發(fā)送和接收更新。但是，如果您沒有在活動(dòng)選項(xiàng)卡中打開該應(yīng)用程序，它是否需要在後臺(tái)每X秒更新一次？這似乎有點(diǎn)浪費(fèi)，不是嗎？尤其是在移動(dòng)設(shè)備和數(shù)據(jù)計(jì)劃中，每種資源都很寶貴。

這就是Page Visibility API發(fā)揮作用的地方。此接口允許開發(fā)人員知道他們的應(yīng)用程序是否在活動(dòng)選項(xiàng)卡中或在後臺(tái)。讓我們以我前面提到的執(zhí)行更新的應(yīng)用程序?yàn)槔?。使用Page Visibility API，您可以檢測(cè)應(yīng)用程序何時(shí)在後臺(tái)，然後不要每5或10秒執(zhí)行一次更新，而是每60秒甚至更少執(zhí)行一次。一旦頁面再次可見，您可以切換回正常的更新速率。很酷，不是嗎？

那麼，您還在等什麼？查看以下指南，開始為頁面可見性啟動(dòng)您的應(yīng)用程序。您的用戶會(huì)感謝您的：

• MDN上的頁面可見性API
• SitePoint上頁面可見性API簡(jiǎn)介

頁面轉(zhuǎn)換事件

您是否曾經(jīng)使用過一個(gè)Web表單，當(dāng)您嘗試離開或關(guān)閉頁面時(shí)，它會(huì)彈出一個(gè)消息，提示您有未保存的數(shù)據(jù)？如今，在您更改設(shè)置、個(gè)人資料詳細(xì)信息等的頁面上，這很常見。頁面中的腳本如何知道您要離開？他們監(jiān)聽pagehide事件。

pagehide及其合作夥伴pageshow是頁面轉(zhuǎn)換事件的主要主角。我們上面已經(jīng)看到第一個(gè)主要用於什麼。 pageshow的主要用途是確定頁面是從緩存加載還是直接從服務(wù)器加載。這不是最常見的用途，但是，如果您需要任一功能，請(qǐng)查看以下資源：

• MDN上的pageshow
• MDN上的pagehide

requestAnimationFrame

Web上的動(dòng)畫已經(jīng)走了很長(zhǎng)一段路，從早期的<marquee></marquee>和<blink></blink>，到動(dòng)畫GIF、jQuery效果，再到當(dāng)前的CSS、SVG、canvas和WebGL動(dòng)畫。所有這些方法中的一個(gè)常數(shù)是需要控制動(dòng)畫的流程並使其盡可能流暢。

最初的方法使用setInterval和setTimeout來控制動(dòng)畫的步驟。問題是結(jié)果並非可靠地一致，動(dòng)畫通常很粗糙。這就是為什麼設(shè)計(jì)了一個(gè)新的接口——requestAnimationFrame。這種方法的主要優(yōu)點(diǎn)是瀏覽器可以自由地將請(qǐng)求與自身的繪製週期匹配，從而明顯地平滑動(dòng)畫。與它的對(duì)應(yīng)物cancelAnimationFrame一起，這兩種方法是現(xiàn)代JavaScript動(dòng)畫的基礎(chǔ)。

像往常一樣，以下是一些讓您開始掌握此功能的資源。

• MDN上的requestAnimationFrame
• MDN上的cancelAnimationFrame
• SitePoint上使用requestAnimationFrame進(jìn)行簡(jiǎn)單動(dòng)畫
• SitePoint上的觀看：使用requestAnimationFrame進(jìn)行性能測(cè)試

定時(shí)API

在線性能是當(dāng)今的熱門話題，每個(gè)人都盡最大努力減少資源，優(yōu)化腳本並充分利用他們掌握的所有工具。有兩種主要方法可以解決此問題：網(wǎng)絡(luò)性能（站點(diǎn)和資源的交付速度）和用戶性能（應(yīng)用程序本身的執(zhí)行速度）。

網(wǎng)絡(luò)性能由兩個(gè)API提供服務(wù)：Navigation Timing和Resource Timing。它們都提供與網(wǎng)絡(luò)性能相關(guān)的所有類型的信息，例如DNS、CDN、請(qǐng)求和響應(yīng)時(shí)間等。唯一的區(qū)別是Navigation Timing針對(duì)HTML頁面本身，而Resource Timing處理所有其他資源（圖像、腳本、媒體等）。

在用戶性能方面，我們有一個(gè)API：User Timing。此API處理兩個(gè)主要概念，稱為Mark（高度詳細(xì)的時(shí)間戳）和Measure（兩個(gè)Mark之間的時(shí)間間隔）。使用這些概念可以測(cè)量代碼的運(yùn)行速度並識(shí)別需要優(yōu)化的位置。不幸的是，Safari仍然不支持此API，因此可能需要polyfill。

掌握這些接口的使用對(duì)於確保網(wǎng)站或應(yīng)用程序的最佳性能至關(guān)重要。這就是為什麼我們?yōu)槟峁┮恍W(xué)習(xí)資料的原因：

• Navigation Timing
  • MDN上的Navigation Timing API
  • SitePoint上使用Navigation Timing API分析頁面加載
  • SitePoint上Navigation Timing API：如何高效分析頁面加載
• Resource Timing
  • MDN上的Resource Timing API
  • Google Developers博客上使用Resource Timing API測(cè)量網(wǎng)絡(luò)性能
  • SitePoint上Resource Timing API簡(jiǎn)介
• User Timing
  • SitePoint上發(fā)現(xiàn)User Timing API
  • HTML5Rocks上的User Timing API
  • GitHub上的user-timing-rum.js和UserTiming.js polyfill

類型化數(shù)組

JavaScript類型化數(shù)組是類似數(shù)組的對(duì)象，並提供了一種訪問原始二進(jìn)制數(shù)據(jù)的方法。為了獲得最大的靈活性和效率，實(shí)現(xiàn)是沿著兩個(gè)概念進(jìn)行的：緩衝區(qū)（原始數(shù)據(jù)的塊）和視圖（提供可以解釋緩衝區(qū)數(shù)據(jù)的上下文）。有許多使用類型化數(shù)組的Web API，例如WebGL、Canvas 2D、XMLHttpRequest2、File、Media Source或Binary WebSockets。如果您的代碼處理此類技術(shù)，您可能對(duì)以下資源感興趣：

• MDN上的JavaScript類型化數(shù)組
• 類型化數(shù)組：瀏覽器中的二進(jìn)制數(shù)據(jù)（HTML5Rocks）

WebSockets

我們前面討論了Channel Messaging以及它如何使兩個(gè)不同的腳本可以直接相互通信。 WebSockets與此類似，而且功能更多。使用此API可以在瀏覽器和Web服務(wù)器之間創(chuàng)建持久通信通道。

與HTTP一樣，WebSocket協(xié)議也有兩個(gè)版本：不安全的（ws://...）和安全的（wss://...）。它還考慮了代理服務(wù)器和防火牆，通過它們打開隧道。實(shí)際上，WebSocket連接以正常的HTTP連接開始，確保與現(xiàn)有基礎(chǔ)設(shè)施的兼容性。

WebSockets是一項(xiàng)引人入勝的技術(shù)（它們甚至有一個(gè)專門的網(wǎng)站），有很多東西需要學(xué)習(xí)。為了幫助您入門，以下是一些精選的資源：

• WebSocket.org上的關(guān)於WebSocket
• MDN上的WebSockets
• SitePoint上HTML5 WebSockets API簡(jiǎn)介

Web Workers

默認(rèn)情況下，所有JavaScript任務(wù)都在同一線程中運(yùn)行。這意味著頁面中的所有腳本都必須共享相同的處理時(shí)間隊(duì)列。當(dāng)處理器只有一個(gè)內(nèi)核時(shí)，這很好且簡(jiǎn)單。但是，現(xiàn)代CPU至少具有雙核，某些型號(hào)的CPU甚至達(dá)到4、6或8個(gè)內(nèi)核。如果可以將某些任務(wù)移動(dòng)到可以由可用額外內(nèi)核處理的單獨(dú)線程中，那不是很好嗎？這就是發(fā)明Web Workers的原因。

使用Web Workers API，開發(fā)人員可以將命名腳本文件委託給在單獨(dú)線程中運(yùn)行的worker。 worker只響應(yīng)創(chuàng)建它的腳本，通過消息進(jìn)行雙向通信，可以運(yùn)行XMLHttpRequest調(diào)用，並且不與DOM或窗口對(duì)象的某些默認(rèn)方法和屬性交互。在例外類別中，我們可以提到WebSockets（可以將WebSocket連接的管理分配給worker）或IndexedDB等數(shù)據(jù)存儲(chǔ)機(jī)制。擁有自己的助手來處理次要任務(wù)，而主線程專注於運(yùn)行整個(gè)應(yīng)用程序，沒有什麼比這更好的了。

要開始使用此功能（包括可用於Web worker的函數(shù)和類的列表），請(qǐng)查看以下資源：

• MDN上的Web Workers API
• MDN上可用於Web Workers的函數(shù)和類
• SitePoint上使用HTML5 Web Workers進(jìn)行JavaScript線程處理

XMLHttpRequest高級(jí)功能

XMLHttpRequest的採用預(yù)示著Web開發(fā)的新時(shí)代。現(xiàn)在可以在瀏覽器和服務(wù)器之間交換數(shù)據(jù)，而無需重新加載整個(gè)頁面。 AJAX是允許每個(gè)人都喜歡的單頁應(yīng)用程序存在的新標(biāo)準(zhǔn)。

這種有用的技術(shù)將得到進(jìn)一步發(fā)展，這很正常。這就是XHR獲得新功能的方式，例如文件上傳、傳輸進(jìn)度信息或直接發(fā)送表單數(shù)據(jù)的能力。所有這些功能（在IE11或舊版Android的情況下存在細(xì)微的例外）在老IE退役後都受到主流瀏覽器的支持。

有關(guān)更多詳細(xì)信息，請(qǐng)隨時(shí)查閱以下資源：

• MDN上的FormData
• SitePoint上使用HTML5 FormData接口簡(jiǎn)化Ajax

2. 其他功能

現(xiàn)代Web不僅僅是HTML、CSS和JavaScript。幕後還有許多看不見（和未被歌頌的）英雄辛勤工作，使我們的在線體驗(yàn)盡可能出色。下面，我們將討論一些此類功能，這些功能與上述功能一樣，不能在老IE瀏覽器上使用（它們因其安全漏洞和缺乏對(duì)現(xiàn)代功能的支持而臭名昭著）。

使用“async”和“defer”的非阻塞JavaScript加載

每個(gè)Web開發(fā)人員都會(huì)學(xué)習(xí)腳本是“加載阻塞”的，並且會(huì)一直阻止整個(gè)頁面，直到它們加載完畢。我們都記得在之前加載jQuery的建議。但是，在單頁應(yīng)用程序的情況下，這種方法是無用的，因?yàn)榫W(wǎng)站的所有行為都是由JavaScript驅(qū)動(dòng)的。這讓我們回到了原點(diǎn)。

但事實(shí)是，在大多數(shù)情況下，您的網(wǎng)站或應(yīng)用程序只需要它加載的所有JavaScript的一部分。其餘部分將在以後需要，或者它們正在執(zhí)行不會(huì)影響DOM的操作。顯而易見的方法是以常規(guī)方式加載只有關(guān)鍵腳本，而以不會(huì)以負(fù)面方式影響應(yīng)用程序的方式加載其餘腳本。實(shí)際上，有兩種這樣的加載方法。

第一種方法是使用defer屬性，用於標(biāo)記不會(huì)影響DOM並打算在解析文檔後執(zhí)行的腳本。在大多數(shù)情況下，這些腳本處理用戶交互，因此可以安全地以這種方式加載它們。第二種方法使用async屬性，並標(biāo)記一個(gè)腳本，該腳本雖然並行加載，但將在下載後立即執(zhí)行。但是，不能保證加載順序與執(zhí)行順序相同。

這兩個(gè)參數(shù)帶來的所有好處，它們正成為提高網(wǎng)站和應(yīng)用程序性能的重要工具。查看以下資源，了解有關(guān)如何以及何時(shí)使用此技術(shù)的更多信息：

• Google Developers上刪除渲染阻塞JavaScript
• SitePoint上使用HTML5 Async和Defer加載非阻塞JavaScript

內(nèi)容安全策略

從一開始，Web上的安全性就是圍繞“同源”模型構(gòu)建的，這意味著只有來自同一域的腳本才能與給定頁面交互。然而，隨著時(shí)間的推移，我們必須將第三方腳本集成到我們的頁面中：來自CDN的JavaScript庫、來自Facebook、Google 或Twitter的社交媒體小部件以及其他類似案例。這意味著我們打開了大門，並允許“來賓”腳本運(yùn)行到我們的隱喻庭院中。當(dāng)惡意腳本也潛入進(jìn)來並像其他腳本一樣被執(zhí)行時(shí)，問題就來了——我們都知道的一種攻擊方法，稱為跨站點(diǎn)腳本或XSS。

內(nèi)容安全策略是對(duì)抗XSS的主要武器。此機(jī)制包含一組策略和指令，這些策略和指令指定允許執(zhí)行哪些腳本，可以從哪裡加載資源，是否可以運(yùn)行內(nèi)聯(lián)樣式或腳本等等。 CSP基於白名單，這意味著默認(rèn)情況下所有內(nèi)容都被拒絕，只有指定的資源才能訪問。這意味著，當(dāng)規(guī)則微調(diào)後，即使惡意腳本插入到我們的站點(diǎn)中，它也不會(huì)被執(zhí)行。

以下是一些資源，可以幫助您更好地理解此機(jī)制：

• 內(nèi)容安全策略參考
• SitePoint上使用內(nèi)容安全策略提高Web安全性
• HTML5Rocks上內(nèi)容安全策略簡(jiǎn)介

HTTP/2協(xié)議

從一開始，Web就運(yùn)行在HTTP協(xié)議之上。然而，雖然第一個(gè)已經(jīng)發(fā)展得非?？?，但HTTP基本上保持不變。在現(xiàn)代網(wǎng)站和應(yīng)用程序的複雜生態(tài)系統(tǒng)中，HTTP可能成為性能瓶頸。當(dāng)然，有一些技術(shù)和實(shí)踐可以優(yōu)化此過程，但只能做這麼多。

這就是為什麼開發(fā)了協(xié)議的第二個(gè)迭代，名為HTTP/2，它基於Google的SPDY協(xié)議。它於2015年2月獲得批準(zhǔn)，規(guī)範(fàn)於2016年5月作為RFC 7540發(fā)布。到目前為止，主流瀏覽器僅通過加密連接支持HTTP/2，並且很有可能在可預(yù)見的未來它將保持這種狀態(tài)，以鼓勵(lì)站點(diǎn)所有者切換到HTTPS。

HTTP/2的採用不僅僅是更改一些配置設(shè)置的問題。一些用於增強(qiáng)HTTP性能的最佳實(shí)踐可能會(huì)影響HTTP/2上的性能。要確定您的網(wǎng)站是否已準(zhǔn)備好使用HTTP/2，您可以查閱以下資源：

• 為HTTP/2做準(zhǔn)備：面向Web設(shè)計(jì)師和開發(fā)人員的指南（Smashing Magazine）
• HTTP/2如何改變Web性能最佳實(shí)踐（New Relic博客）
• HTTP/2面向Web開發(fā)人員（Cloudflare博客）

資源提示：預(yù)取

Web性能是當(dāng)今的熱門話題，而且有充分的理由。正如該領(lǐng)域的所有工作人員都知道的那樣，頁面加載時(shí)間的很大一部分是由資源下載佔(zhàn)據(jù)的。如果可以在頁面加載後使用時(shí)間來預(yù)加載後續(xù)步驟的資源，那不是很好嗎？這就是資源提示的用途。

資源提示是一系列指令，它們告訴瀏覽器提前提供以後將需要的特定資源。該列表包含五個(gè)提示，如下所示：

• dns-prefetch
• preconnect
• prefetch
• preload
• prerender

在這五個(gè)可能的選項(xiàng)中，目前唯一具有良好瀏覽器支持的是prefetch。此提示告訴瀏覽器緩存用戶很可能在當(dāng)前頁面之後請(qǐng)求的文檔。這將其用途限制為可以緩存的元素。將其與其他類型的資源一起使用將不起作用。

如果您對(duì)此主題感興趣，以下是一些提供更多詳細(xì)信息的資源：

• Medium上的資源提示文章
• CSS-Tricks上的預(yù)取、預(yù)加載、預(yù)瀏覽
• KeyCDN博客上的資源提示

嚴(yán)格傳輸安全

HTTPS正成為新的瀏覽標(biāo)準(zhǔn)，越來越多的網(wǎng)站只接受安全連接。普通連接（在HTTP上）通常會(huì)重定向到HTTPS版本，事情照常進(jìn)行。但是，這種方法容易受到“中間人”攻擊，在這種攻擊中，重定向會(huì)改為發(fā)生到您想要的網(wǎng)站（通常是銀行網(wǎng)站）的欺騙克隆，以便竊取您的登錄憑據(jù)。

這就是嚴(yán)格傳輸安全標(biāo)頭髮揮作用的地方。第一次使用HTTPS連接到所需網(wǎng)站時(shí)，標(biāo)頭將發(fā)送到瀏覽器。下次連接時(shí)，即使您只使用URL的HTTP版本，瀏覽器也會(huì)直接轉(zhuǎn)到HTTPS版本，而不會(huì)經(jīng)過重定向周期。由於沒有在HTTP上建立連接，因此前面描述的攻擊將無法發(fā)生。

有關(guān)嚴(yán)格傳輸安全標(biāo)頭的更多詳細(xì)信息，請(qǐng)查看以下網(wǎng)站：

• MDN上的HTTP嚴(yán)格傳輸安全

設(shè)備像素比

Window.devicePixelRatio是一個(gè)只讀屬性，它返回當(dāng)前顯示設(shè)備上一個(gè)物理像素的（垂直）大小與一個(gè)CSS像素的大小之比。這樣，開發(fā)人員可以檢測(cè)高密度屏幕（例如Apple的Retina顯示屏或高端Android屏幕）。與媒體查詢和MatchMedia（我們上面討論過）一起使用時(shí)，此屬性允許為最佳體驗(yàn)提供優(yōu)化的資源。

• MDN上的Window.devicePixelRatio

Web視頻文本軌道

Web視頻文本軌道（或WebVTT）是一種用於標(biāo)記多媒體資源文本字幕的格式。它與HTML5<track></track>元素一起使用，並允許以同步方式向媒體資源（音頻或視頻）添加字幕、翻譯、標(biāo)題或描述。此文本信息的存在使媒體資源更容易訪問。

有關(guān)如何開始使用此功能的說明，請(qǐng)查看以下資源：

• MDN上的WebVTT
• Dev.Opera上WebVTT和<track></track>簡(jiǎn)介
• HTML5Rocks上Track元素入門

總結(jié)

我們?cè)谶@裡，在本系列文章的結(jié)尾，該系列文章始於一個(gè)簡(jiǎn)單的智力練習(xí)：“老IE消失了！讓我們慶祝吧?。ā瓗讉€(gè)小時(shí)後… …）現(xiàn)在怎麼辦？”。我們涵蓋了廣泛的主題，從不再需要的技術(shù)和實(shí)踐到我們現(xiàn)在可以自由地不做polyfill就能做到的所有新事物，無論是HTML、CSS還是原生JavaScript。我們甚至還涉及了更廣泛的主題，例如性能優(yōu)化和增強(qiáng)安全性。

您現(xiàn)在應(yīng)該立即開始重構(gòu)所有代碼嗎？很可能不會(huì)。必鬚根據(jù)重構(gòu)成本與技術(shù)債務(wù)成本之間的平衡來做出此類決定。但是，如果您要啟動(dòng)一個(gè)新項(xiàng)目，請(qǐng)務(wù)必為未來構(gòu)建它，而不是為過去構(gòu)建它。

Internet Explorer退役後關(guān)於原生JavaScript開發(fā)的常見問題解答（FAQ）

Internet Explorer退役後原生JavaScript開發(fā)的重要性是什麼？

Internet Explorer退役後原生JavaScript開發(fā)至關(guān)重要，因?yàn)樗试S開發(fā)人員創(chuàng)建更高效、更有效的Web應(yīng)用程序。隨著Internet Explorer的停用，開發(fā)人員不再受限於通常與該瀏覽器相關(guān)的約束和兼容性問題。他們現(xiàn)在可以使用JavaScript的全部功能，包括其最新功能和更新，來構(gòu)建更動(dòng)態(tài)、更交互式和更用戶友好的Web應(yīng)用程序。

如何在我的瀏覽器中啟用JavaScript？

在瀏覽器中啟用JavaScript是一個(gè)簡(jiǎn)單的過程。對(duì)於大多數(shù)瀏覽器，您可以在設(shè)置或首選項(xiàng)菜單中找到啟用或禁用JavaScript的選項(xiàng)。通常，這涉及導(dǎo)航到“安全”或“隱私”部分並查找與JavaScript相關(guān)的選項(xiàng)。確保啟用它以獲得更好的瀏覽體驗(yàn)。

Internet Explorer和其它瀏覽器中的JavaScript之間有什麼區(qū)別？

是的，Internet Explorer和其它瀏覽器中JavaScript的工作方式存在顯著差異。 Internet Explorer具有不同的JavaScript引擎，這經(jīng)常導(dǎo)致兼容性問題和限制。 Chrome、Firefox和Safari等現(xiàn)代瀏覽器使用更高級(jí)的JavaScript引擎，這些引擎支持JavaScript的最新功能和標(biāo)準(zhǔn)，從而提高性能並減少兼容性問題。

使用原生JavaScript而不是庫或框架的好處是什麼？

與使用庫或框架相比，使用原生JavaScript具有許多好處。它允許獲得更好的性能，因?yàn)闆]有加載和解析不必要代碼的開銷。它還提供了對(duì)代碼的更多控制，因?yàn)殚_發(fā)人員不受特定庫或框架的約束。此外，理解和使用原生JavaScript可以使您更深入地了解該語言及其功能。

Internet Explorer的停用如何影響JavaScript開發(fā)？

Internet Explorer的停用對(duì)JavaScript開發(fā)產(chǎn)生了重大影響。開發(fā)人員不再需要編寫額外或不同的代碼來確保與Internet Explorer的兼容性。這導(dǎo)致了更高效的開發(fā)流程以及能夠利用JavaScript的全部功能。它還導(dǎo)致了不同瀏覽器之間更一致的用戶體驗(yàn)。

我可以在開發(fā)中使用JavaScript的一些最新功能是什麼？

JavaScript不斷更新，並增加了新的功能和改進(jìn)。一些最新功能包括用於處理異步操作的async/await、用於擴(kuò)展數(shù)組或其它可迭代對(duì)象的擴(kuò)展語法以及用於更簡(jiǎn)潔函數(shù)語法的箭頭函數(shù)。這些功能可以極大地增強(qiáng)您的JavaScript開發(fā)，並允許您編寫更高效、更易讀的代碼。

如何確保我的JavaScript代碼與所有瀏覽器兼容？

確保瀏覽器兼容性是JavaScript開發(fā)的一個(gè)重要方面。實(shí)現(xiàn)此目標(biāo)的一種方法是使用特性檢測(cè)，這涉及在使用特定功能之前檢查用戶瀏覽器是否支持該功能。另一種方法是使用polyfill，polyfill是為不支持它們的舊版瀏覽器提供較新功能功能的腳本。

Internet Explorer退役後JavaScript開發(fā)的未來是什麼？

Internet Explorer退役後JavaScript開發(fā)的未來看起來很有希望。隨著Internet Explorer的停用，開發(fā)人員現(xiàn)在可以專注於利用JavaScript的全部功能，而無需擔(dān)心兼容性問題。這與語言的持續(xù)更新和改進(jìn)相結(jié)合，預(yù)示著JavaScript開發(fā)效率更高、功能更強(qiáng)大、用途更廣泛的未來。

學(xué)習(xí)更多關(guān)於原生JavaScript開發(fā)的一些好的資源是什麼？

有很多很棒的資源可用於學(xué)習(xí)更多關(guān)於原生JavaScript開發(fā)的知識(shí)。一些流行的在線平臺(tái)包括Mozilla Developer Network (MDN)、freeCodeCamp和Codecademy。這些平臺(tái)提供關(guān)於JavaScript的全面指南和教程，涵蓋從基礎(chǔ)知識(shí)到更高級(jí)主題的所有內(nèi)容。

如何有效地調(diào)試JavaScript代碼？

調(diào)試是JavaScript開發(fā)中必不可少的一部分。大多數(shù)現(xiàn)代瀏覽器都帶有內(nèi)置的開發(fā)工具，可用於調(diào)試。這些工具允許您逐步執(zhí)行代碼、檢查變量並查看發(fā)生的任何錯(cuò)誤或異常。此外，使用良好的編碼實(shí)踐，例如編寫清晰簡(jiǎn)潔的代碼並註釋代碼，也可以使調(diào)試過程更容易。

以上是Internet Explorer之後的本地JavaScript開發(fā)的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！