使用Vue時，你可能會問自己“為什麼必須使用返回物件的函數來定義data，而不僅僅是一個物件呢？" 特別是考慮到在某些地方，data 並不是一個函數，比如在一些示例中的App組件中。 答案是，當組件被多次使用時，如果data不是一個函數，而是一個普通的物件，如下所示： data: { counter: 0 } 那麼根據JavaScript的工作方式，每個組件實例將共享這個屬性。 這在99.9%的情況下都不是你想要的，相反你應該這樣做： data: function() { return { counter: 0 } } 一開始可能不直觀，但一旦你接受這個解釋，並了解它對你的應用程式是有害的，也是可能引發錯誤的潛在來源，你就會記住總是使用一個函數來定義資料。

Web Components 自訂元素初學教學 我使用了一個叫作 CSS Doodle 的 CSS 函式庫創建了我的第一個自訂元素。這是一個很棒的應用，它使用自訂元素讓你創建令人驚艷的 CSS 動畫效果。這激發了我對於了解底層原理的慾望。所以我決定更深入地研究 Web Components，這是一個很多人請我寫的主題。 自訂元素讓我們可以創建新的 HTML 標籤。 我一開始無法想像這有什麼用處，直到我使用了 CSS Doodle 函式庫。畢竟，我們已經有很多標籤了。 這篇教學涵蓋了 Custom Elements 第 1 版，也就是寫作時間的最新版本。 使用自訂元素，我們可以創建一個自訂的 HTML 標籤，並與 CSS 和 JavaScript 相關聯。 這不是 React、Angular 或 Vue 等框架的替代方案，而是一個全新的概念。 window 全局物件暴露了 customElements 屬性，這讓我們可以訪問 CustomElementRegistry 物件。 CustomElementRegistry 物件 這個物件有幾個方法可以用來註冊自訂元素和查詢已註冊的自訂元素： define() 用於定義新的自訂元素 get() 用於獲取自訂元素的構造函數（如果不存在則返回 undefined） upgrade() 用於升級自訂元素 whenDefined() 用於獲取自訂元素的構造函數。類似於 get()，但它返回的是一個 promise，當該項目可用時解析。 如何創建自訂元素 在我們呼叫 window.customElements.define() 方法之前，我們必須通過創建一個新的類來定義一個新的 HTML 元素，並繼承 HTMLElement 內建類： class CustomTitle extends HTMLElement { //....

Web Storage API 提供了一種在瀏覽器中儲存數據的方式。它定義了兩種非常重要的儲存機制：會話儲存和本地儲存，它們是 Web 平台上提供的一套儲存選項的一部分。 介紹 如何訪問儲存 方法 setItem(key, value) getItem(key) removeItem(key) key(n) clear() 儲存大小限制 桌面 移動設備 超過配額 開發者工具 Chrome Firefox Safari 介紹 Web Storage API 定義了兩種非常重要的儲存機制：會話儲存和本地儲存。 它們是 Web 平台上提供的一套儲存選項的一部分，包括： Cookies IndexedDB 緩存 API Application Cache 已被棄用，Web SQL 在 Firefox、Edge 和 IE 中沒有實現。 會話儲存和本地儲存提供了一個私有區域來存儲數據。您存儲的任何數據都無法被其他網站訪問。 會話儲存在頁面會話的期間保持存儲的數據。如果多個窗口或選項卡訪問同一個網站，它們會有兩個不同的會話儲存實例。 當一個選項卡/窗口關閉時，該選項卡/窗口的會話儲存將被清除。 會話儲存旨在允許在同一個網站上獨立處理不同的進程，這在 cookie 中是不可能的，因為它們在所有會話中共享。 相反，本地儲存會保存數據直到它被明確刪除，無論是您還是用戶刪除。它不會自動清理，並且在所有訪問網站的會話中共享。 本地儲存和會話儲存都是協議特定的：在使用 http 訪問頁面時存儲的數據在使用 https 服務頁面時不能訪問，反之亦然。 網絡儲存只能在瀏覽器中訪問，不像 cookie 那樣發送到服務器。 如何訪問儲存 本地和會話儲存都可以在 window 對象上使用 sessionStorage 和 localStorage 進行訪問。 它們的屬性和方法集完全相同，因為它們返回的是同一個對象，即 Storage 對象。...

學習使用 Web Workers 在背景中運行 JavaScript 代碼的方法。 介紹 Web Workers 的瀏覽器支持 創建 Web Worker 與 Web Worker 通信 使用 Web Worker 物件中的 postMessage 傳回訊息 多個事件監聽器 使用 Channel Messaging API Web Worker 的生命週期 在 Web Worker 中加載庫 Web Worker 可用的 API Introduction JavaScript 是單線程的，無法同時並行運行。 這很好，因為我們不需要擔心並發編程中可能發生的一系列問題。 由於這個限制，JavaScript 代碼從一開始就被迫高效，否則用戶會有不好的體驗。昂貴的操作應該是異步的，以避免阻塞線程。 隨著 JavaScript 應用程序的需求越來越多，這在某些場景中開始成為一個問題。 Web Workers 在瀏覽器內引入了並行執行的可能性。 它們有幾個限制： 無法訪問 DOM：Window 對象和 Document 對象 它們可以通過消息與主 JavaScript 程序進行通信 它們需要從相同的源頭（域名、端口和協議）加載 如果使用文件協議（file://）提供頁面，它們就不能工作 Web Worker 的全局作用域是一個名為 WorkerGlobalScope 的對象，而不是在主線程中的 Window。 Browser support for Web Workers 非常好！...

這是我將寫的一系列關於 Swift 和 iOS 應用程式開發的新教程的開端。 幾個月前，我已經做了一系列關於 Swift 的入門教學，你可以在這裡 連結文字找到。 對於 iOS / Mac 開發我並不陌生。在 Swift 出現之前的 2011 年左右，我使用 Objective-C 開發了幾個 iOS 應用程式和遊戲，以及一些在 Swift 初期開發的應用程式。Swift 只有六年的歷史。 我還開發了幾個基於 Web 技術堆疊（HTML + CSS + JavaScript）的 Mac 應用程式，但我不把它們算作原生應用程式。 創建運行原生程式碼的應用程式真的很特別。 相比於 JavaScript，Swift 是一種更低層次的語言，因此本質上更加複雜，但它也讓我們有機會做到在 JavaScript 和網頁上無法實現的事情。整個 iOS 框架和基礎設施生態系統更加廣泛和複雜。 這並不意味著其中一個比另一個更好。它們是完全不同的工具，存在於完全不同的環境中。讓我們來簡單比較一下網頁和 iOS 之間的差異。 網頁是開放的。沒有任何阻止你創建網站或網頁應用程式並在網頁上發布的限制。而 iOS 應用程式則存在於 Apple 的圍牆園地中。這提高了平台的品質和安全性，但代價是牽制了一些自由（以及每年的開發者費用）。Apple 可能會認為你的應用程式不符合其質量要求或政策。 他們可以拒絕發佈，或在未來下架應用程式。每次你想要發布更新，你必須等待他們的審核，這可能需要幾天的時間。 在網頁上，我們不需要處理這些。在網頁上，我們是我們作品的主人。 網頁不是一個單一的組件，而是由不同公司擁有並追求不同目標的一系列工具組成的生態系統。你無法掌控用戶的設備和瀏覽器。在 iOS 上，你可以決定支援哪些設備，而且只有一個供應商：Apple。 使用原生代碼的一個無價之處是你的應用程式會以第一類公民的身份運行在 iPhone、iPad 或 Apple Watch 上。在這些精美的設備上運行你的應用程式和代碼感覺很棒。 另外，在網頁上有很多不同的供應商獨立開發一個特定領域的功能。有瀏覽器按照不同的路線圖實現功能。有組織制定標準。 在 Swift/iOS 開發中，只有 Apple 為我們決定 Swift 的未來，設備的未來以及未來幾年中的新功能。...

Webpack是一個在過去幾年引起了很多關注的工具，現在幾乎在每個項目中都被使用。了解一下它吧。 什麼是Webpack？ 安裝Webpack 全局安裝 本地安裝 Webpack配置 入口點 輸出 載入器 插件 Webpack模式 運行Webpack 監聽變化 處理圖片 處理SASS代碼並轉換為CSS 生成源代碼映射 什麼是Webpack？ Webpack是一個工具，可以讓你編譯JavaScript模塊，也稱為模塊打包工具。 它可以將大量的文件生成一個（或多個）運行應用的文件。 它可以執行多種操作： 幫助你將資源打包。 監聽變化並重新執行任務。 可以運行Babel將代碼編譯為ES5，讓你在不擔心瀏覽器支持的情況下使用最新的JavaScript特性。 可以將CoffeeScript轉換為JavaScript。 可以將內聯圖像轉換為數據URL。 允許你使用require()導入CSS文件。 可以運行開發Web服務器。 可以處理熱模塊替換。 可以將輸出文件分成多個文件，以避免首次頁面載入時需要加載大型JavaScript文件。 可以執行樹狀抖動。 Webpack不僅僅用於前端，它在後端Node.js開發中也非常有用。 Webpack的前身，以及仍然廣泛使用的工具，包括： Grunt Broccoli Gulp 這些工具與Webpack的功能有很多相似之處，但主要區別在於這些被稱為任務運行器，而Webpack則是作為模塊打包工具誕生的。 它是一個更加專注的工具：你只需要指定應用程序的入口點（甚至可以是帶有腳本標籤的HTML文件），Webpack就會分析文件並將運行應用所需的所有內容打包到一個單獨的JavaScript輸出文件（或多個文件如果使用了程式碼分割）中。 安裝Webpack Webpack可以全局安裝，也可以在每個項目中本地安裝。 全局安裝 以下是如何使用Yarn全局安裝： yarn global add webpack webpack-cli 使用npm全局安裝： npm i -g webpack webpack-cli 一旦安裝完成，你就可以運行以下命令： webpack-cli 本地安裝 Webpack也可以在項目中進行本地安裝。這是建議的安裝方式，因為Webpack可以按項目進行更新，且對於小型項目使用最新功能的抵抗力較小，而不需要更新使用Webpack的所有項目。 使用Yarn： yarn add webpack webpack-cli -D 使用npm： npm i webpack webpack-cli --save-dev 安裝完成後，將以下代碼添加到你的package.json文件中： { //....

WebP是由Google開發的開源圖像格式，它承諾生成比JPG和PNG格式更小、外觀更好的圖像。 介紹 有多小？ 生成WebP圖像 瀏覽器支持 如何使用WebP？ 介紹 WebP是由Google開發的開源圖像格式，它承諾生成比JPG和PNG格式更小、外觀更好的圖像。 WebP支持像PNG和GIF圖像那樣的透明度。 WebP支持像GIF圖像那樣的動畫。 使用WebP，您可以設置圖像的質量比率，因此您可以決定是獲得更好的質量還是更小的大小（就像JPG圖像中發生的那樣）。 因此，WebP可以做到GIF、JPG和PNG圖像所能做的一切，並生成更小的圖像。聽起來很不錯。 如果您想比較各種格式中圖像的外觀，這裡有一個由Google提供的很棒的圖庫。 WebP並不是新的，它已經存在了很多年。 有多小？ 生成更小的圖像的前提非常有趣，尤其是當您考慮到大多數網頁大小是由用戶需要下載的圖像資源的數量和大小來確定時。 Google發布了一份比較研究，對100萬幅圖像的結果如下： “WebP的整體壓縮比比JPEG或JPEG 2000更高。在文件大小最小化方面，對於那些在網頁上很常見的較小的圖像來說，縮小文件大小的收益尤其高。” 您應該根據您打算提供的圖像類型進行測試，並根據此形成自己的觀點。 在我的測試中，與PNG相比，無損壓縮生成的WebP圖像要小50%。只有在使用有損壓縮時，PNG才能達到那樣的文件大小。 生成WebP圖像 所有現代圖形和圖像編輯工具都可以導出為.webp文件。 還有命令行工具可以直接將圖像轉換為WebP。Google 提供了一套工具。 cwebp是將任何圖像轉換為.webp的主要命令行實用程序，使用方式如下： cwebp image.png -o image.webp 使用cwebp -longhelp查看所有選項。 瀏覽器支持 WebP目前受到以下瀏覽器的支持： Chrome Opera Opera Mini UC Browser Samsung Internet 然而，只有桌面版的Chrome和Opera 19+實現了WebP的所有功能，包括： 有損壓縮 無損壓縮 透明度 動畫 其他瀏覽器只實現了一部分功能。Safari和IE根本不支持WebP，也沒有迹象表明它們將在短期內實現WebP。 但是，自Firefox的65版（2019年1月）起，Firefox支持WebP，自Edge的18版起，Edge也支持WebP。 因此，如果我們可以為這些用戶提供優化的圖像，以加快為他們提供服務並節省帶寬，那就太好了。但是，請檢查它是否實際上可以減小圖像的大小。 檢查您的JPG/PNG圖像優化工具的結果，看看WebP引入的額外複雜性是否有用。 如何使用WebP？ 有幾種不同的方式可以使用WebP。 您可以使用服務器級機制，根據HTTP_ACCEPT請求標頭內容包含image/webp時，提供WebP圖像而不是JPG和PNG圖像。 第一種方式是最方便的，因為對您和您的網頁來說是完全透明的。 另一種選擇是使用Modernizr並檢查Modernizr.webp設置。 如果您不需要支持Internet Explorer，一種非常方便的方法是使用<picture>標籤，它現在被除了Opera Mini和IE（所有版本）外的所有主要瀏覽器支持。 <picture>標籤通常用於響應式圖像，但我們也可以將其用於WebP，正如HTML5 Rocks的這篇教程所解釋的那樣。 您可以指定一系列圖像，它們將按順序使用，因此在以下示例中，支持WebP的瀏覽器將使用第一張圖像，如果不支持，則回退到JPG： <picture> <source type="image/webp" srcset="image.webp"> <img src="image.jpg" alt="一張圖像"> </picture>

如何使用WebRTC創建直接的視訊通信應用程序 WebRTC是Web實時通信的縮寫。 它允許在瀏覽器之間建立直接的數據通信。 您可以使用它來 流式傳輸音頻 流式傳輸視頻 共享文件 視頻聊天 創建點對點數據共享服務 創建多人遊戲 等等。 它是一個致力於使即時通信應用程序易於創建的努力，利用Web技術，因此除了Web瀏覽器之外，不需要任何第三方插件或外部技術。 未來在執行RTC時應該不再需要插件，而是應該依賴於標準技術-WebRTC。 它受到所有現代瀏覽器的支持（Edge僅部分支持RTCDataChannel-請參見後面）: WebRTC實現了以下API： **MediaStream**獲取用戶端的數據流，例如攝像頭和麥克風 **RTCPeerConnection**處理同行之間的音頻和視頻流傳輸 RTCDataChannel：處理其他類型的數據（任意數據） 使用視頻和音頻通信時，您將使用MediaStream和RTCPeerConnection。 其他類型的應用程序（例如遊戲、文件共享等）依賴於RTCDataChannel。 在本文中，我將通過使用Node.js上的Websockets服務器來創建一個使用WebRTC連接兩個遠程攝像頭的示例。 提示：在您的項目中，您可能會使用抽象出許多這些細節的庫。這個教程旨在解釋WebRTC技術，以便您知道底層的運作原理。

WebSockets是Web應用程序中HTTP通信的替代方案。它們提供了一個客戶端和服務器之間長期存在的、雙向的通信通道。讓我們來了解如何使用它們來進行網絡交互。 WebSockets是Web應用程序中HTTP通信的替代方案。 它們提供了一個客戶端和服務器之間長期存在的、雙向的通信通道。 一旦建立，該通道保持打開，提供了非常快速的連接和低延遲和開銷。 WebSockets的瀏覽器支持 WebSockets在所有現代瀏覽器中都得到支持。 WebSockets和HTTP的區別 HTTP是一種非常不同的協議，也是一種不同的通信方式。 HTTP是一種請求/響應協議：當客戶端請求時，服務器返回一些數據。 而WebSockets這樣： 服務器可以在客戶端不明確請求的情況下向客戶端發送消息 客戶端和服務器可以同時交談 傳送消息時只需交換非常少的數據開銷。這意味着低延遲通信。 WebSockets非常適合實時和長期存在的通信。 HTTP非常適合偶爾的數據交換和客戶端發起的交互。 HTTP實現起來要簡單得多，而WebSockets則需要更多的開銷。 安全的WebSockets 請始終使用安全、加密的WebSockets協議，即wss://。 ws://是不安全的WebSockets版本（WebSockets的http://），出於明顯原因應該避免使用。 建立新的WebSockets連接 const url = 'wss://myserver.com/something' const connection = new WebSocket(url) connection是一個WebSocket對象。 在連接成功建立時，將觸發open事件。 通過將回調函數賦值給connection對象的onopen屬性來監聽它： connection.onopen = () => { //... } 如果出現任何錯誤，將觸發onerror回調函數： connection.onerror = (error) => { console.log(`WebSocket error: ${error}`) } 使用WebSockets將數據發送到服務器 一旦連接打開，您可以向服務器發送數據。 您可以在onopen回調函數內部輕松地這樣做： connection.onopen = () => { connection.send('hey') } 使用WebSockets從服務器接收數據 通過在onmessage上設置回調函數來監聽message事件，當接收到該事件時將調用此函數： connection.onmessage = (e) => { console.log(e.data) } 在Node.js中實現服務器 ws是Node.js的一個流行的WebSockets庫。...

＃寫下你不知道的事情 對於撰寫自己尚未了解的事情的一些思考 我正在結束一天的工作，剛剛打開了 Tim Ferris 的《賽博幫》一書。 這本書非常酷，收錄了許多非常成功的人的見解、引文和偉大建議。 有時這些建議是實用的，有時它們是值得遵循的偉大建議，有時它們能帶來啟發。 我翻閱了一些用螢光筆標註的頁面，以獲得每日智慧的補給。然後我翻到了一個我尚未閱讀過的隨機頁面，我找到了這樣的內容。 你經常聽到的最糟糕建議是什麼？「寫下你所知道的事情。」為何我想要寫關於我所知甚少的事情？難道我不想透過寫作來學習更多嗎？ 這真是太神奇了。 我覺得我應該早就想到這句話了。不過不知道為什麼，我們通常不會深入思考我們每天所做的事情，對不對？ 所以讓我告訴你這個。在這篇小小的博客中，在我談論的這個小小的技術/編程領域中，我所有的博客文章一直都是關於學習的，而不是談論我已經知道的事情。 從開始的那些日子開始：這個博客以其現在的形式存在的全部原因是，2017年我開始記錄自己學習 Go 的步驟。 有時我會發現一些東西，馬上在忘記之前寫下來，留下一個痕跡。也許一個月後我需要做同樣的事情，我會找到自己的文章。如果我記得我寫過那個東西的話。 有時我只是瀏覽了筆記中的數十億個主題之一，然後寫下自己對該主題的理解。 我最喜歡寫的是我個人感興趣的事情。我想我從來沒寫過我覺得無聊的主題。當我可以選擇一個有趣的主題時，我不必選擇一個無聊的主題。 有機會你自己的寫作將有助於正在努力學習的人。 現在，我經常為他人創作內容，讓他們也享受到這些內容，因為我的博客很幸運地被一些人閱讀，所以我努力創造有用的內容。 有時，當我寫關於一個主題時，我會暫時成為該主題的專家，因為為了寫作，我會閱讀很多關於它的內容。 我覺得我的記憶是一種"後進先出"（Last In First Out）的記憶，所以我可能會在今天學習的東西之後忘記它，也許一個月後，誰知道呢？ 但是我不在乎，因為我已經把它寫下來了，以防以後可能需要它。