這是一個很好的問題。有利有弊。我討論這個話題，讓您可以對此做出自己的意見。 應該在 Git 中提交 node_modules 文件夾嗎？ 我提到了 Git，但同樣的原則也適用於您所使用的任何版本控制系統。 這是一個很好的問題。有利有弊。 我建議的默認選擇是不提交 node_modules 文件夾，而是將其添加到您的.gitignore文件中。 您可能有特殊的需求，反過來改變這個決定。 我討論這個話題，讓您可以對此做出自己的意見。 以下是不提交 node_modules 的一些論點： 您可以保持 Git 歷史純淨。當您添加新的套件時，您只需存儲package.json和package-lock.json文件的更改。當您決定更新套件版本時，只需存儲package-lock.json的文件更改。 package-lock.json是 npm 的一個相對較新的功能，它取代了以前使用的“shrinkwrap”命令。 您避免將數百MB的依賴項放入您的存儲庫中，這意味著隨著時間的推移，工作速度將更快。切換分支和檢出代碼是受存儲庫大小影響很大的2個操作。 在使用分支時，您可能會遇到超出您的代碼範圍的合併衝突，而是涉及依賴代碼。這對您處理來說並不好，可能會浪費很多時間。避免提交更改依賴項後的合併請求或合併操作，將有更多的文件涉及到這個過程。工具變得更慢，甚至可能決定不顯示完整的差異（例如 GitHub）。 如果您在部署到與開發機器不同的平台時（常見情況是在 Mac 上開發，在 Linux 上部署），需要重新編譯原生的 Node 模塊。您需要調用npm rebuild，這會使服務器與開發機器不同步。 不提交 node_modules 意味著您需要將所有模塊列在package.json（和package-lock.json）中，這是必須的步驟。這很好，因為您可能不會很注意這樣做，如果您不這樣做，某些 npm 操作可能會出錯。 提示：在package.json文件中不需要使用具體版本，自從引入了package-lock.json文件以後不再需要了。 如果您使用單獨的dependencies和devDependencies集合，通過提交node_modules文件夾，您基本上提交了devDependencies，而生產構建無法（輕易）去除它們。 可能會導致您提交 node_modules 的原因，以及如何解決它們： npm套件可能被其作者從 npm 注冊表中刪除。在 2016 年發生過著名的left-pad事件（了解更多）。這在受歡迎的套件中非常少見。如果發生這種情況，您可能無法再使用那個特定的功能。 您還可以主張npm不能保證無限期存在，它可能會消失，所以確保將完整的代碼與您的應用程序一起提交，是確保將來擁有的一種簡單方法。 每次使用套件時，在 GitHub 上創建一個 fork。偶爾保持它與原始庫同步（可以自動化）。 這在某些情況下並不實用，因為套件可能有數十個它們自己的依賴項。 您可以為項目使用私有存儲庫服務器，並將其用於托管所有依賴項。 選項包括： sinopia npm_lazy npm-lazy-mirror artifactory npm Enterprise（來自 npm 公司） 提交依賴項的另一個原因是能夠快速編輯代碼，如果您發現錯誤或者想要向庫添加某些內容。 這是一把雙刃劍：如果這樣做，您就失去了升級套件的能力，如果有新版本發布，這只對於快速的臨時修復有好處。 最佳的解決方案是要麼向原始項目提交要求的 PR，要麼 fork 它並將您的 fork 用作依賴項。

如果你是自由工作者、獨立工作的人，或者是只有一個人的公司，那麼你可能面臨一個艱難的決定：是建立個人部落格還是公司部落格？ 在這個問題上有一個很大的區別。在我看來，個人部落格更好，因為公司和項目都有可能會來來去去。也許三年後你就會賣掉你的公司。 然而，你的個人品牌將與你在哪裡都保持一致。我認為個人品牌的優勢在於你有能力進行實驗並進行轉變，如果需要的話。 如果你創建的品牌與產品或領域過於緊密相聯，那麼在不更改名稱和域名的情況下，你將無法輕鬆地進行轉換，這可能對人們來說很混亂，也很難使它運作得順利。 而且，很可能在一開始時你會很難找到一個好主意，所以最好有不止一個選項。這樣你就不必從零開始了。

許多人問我對於 React 和 Vue.js 的意見。以下是我的想法。 作為對 Vue 和 React 製作電子書和課程的經驗者，我也在許多小型專案中使用它們，因此我認為我可以回答這個問題，幫助你在這兩者之間作出選擇。 下面是我的印象。 兩者都很好且快速 在技術細節上沒有差別，它們都達到相同的目的，且都執行得很好。 Vue 更適合初學者 這是我的印象。 React 正試圖追趕 Vue.js 最大的賣點，即 Vue 的初學者友善性。反之，React 針對略有不同的受眾，這在其文件中得以體現。 相較於 Vue，React 需要相當程度的現代 JavaScript 知識。 JSX 比模板語言更難理解。另一方面，Vue 與 Angular 相似，這使得從 Angular 遷移更加簡單。 Vue 更像一個完整的套件，React 則有大量可供選擇的庫 在 Vue 中，擁有官方套件來滿足主要需求（如路由或狀態管理），而 React 則讓庫自由競爭最受歡迎解決方案的位置。這可能從不同的觀點來看是好或壞。 我認為擁有官方套件來滿足常見需求非常方便，尤其是這意味著所有事物都保持同步，而系統的整體變更也被整體思考。 React 擁有較大的使用者群和就業機會 React 的市場份額很大。我不會提及任何形式的調查或研究，因為在Google上輕鬆搜尋即可找到最新資訊。 Vue 也在不斷增長，但若你想專攻某項技術以獲得工作或自由工作機會，React 絕對是更大的池塘。當然，這個池塘中有更多開發人員，而較不熟悉的 Vue 可能也會有更多機會，因為開發人員相對較少。很難說。 Vue 是獨立的，React 受 Facebook 支援 有什麼不同呢？我有時在 React 的發行說明中（或其他地方）看到類似「在 Facebook，我們有 XXXXX 個 React 組件」或「在 Facebook，嘀嘀咕咕…」的語句。React 是 Facebook 工程師的副產品。它並非獨立產品，也永遠不會是。如果 Facebook 需要某種特定需求導致對 React 進行修改或變更，那會被引進。這也意味著有時會進行變更，而你應該跟上快速的發展，否則就「落伍了」。...

火焰存在時真讓人興奮，否則我就無法在不燒壞的情況下進行創造性和有成果的工作。那麼，什麼是火焰呢？ 我訂閱了Paul Jarvis的電子報，他是一本出色的 Company of One 書的作者。在最近的一封電子郵件中，他提到了火焰： […] 有些日子我覺得我可以很努力地推進[…] 我稱之為火焰。當我擁有火焰時，我可以通過艱難的運動或者完成我正在寫的內容找到動力。火焰給了我能量、動力和決心。 我非常能感受到這個概念。在擁有火焰的日子裡，我可以連續寫5篇博客文章，並且一整天都可以寫程式。我對一切都有充沛的精力。 在這張照片中，正是我寫作時的火焰。 有些日子，我卻一無所能。 問題是，火焰並不總是存在。而且我無法隨心所欲地召喚它。[…] 火焰無法按需點燃。你可以營造出完美的環境，但你無法像它在那些自然存在的日子一樣燃燒。 維持火焰燃燒是一個平衡之舉。如果我不讓它重新充電，火焰將會熄滅；但如果我一直追求火焰，它將燒毀一切。今年，我致力於保持火焰以健康的熊熊火焰形式燃燒。 那些擁有火焰的日子，我可能會在桌前坐上14個小時，幾乎沒有活動。我真的很感激火焰並不每天都存在，否則這將對健康造成嚴重影響。 我有非常活躍的生活方式，體重60公斤（約132磅），所以體重並不是我的問題。但是，長時間待在桌前，即使椅子非常符合人體工學，你晚上肯定會感到疲倦。 火焰存在時很棒，否則我將無法在不燒壞的情況下進行創造性和有成果的工作。這是我非常注意的事情，因為我過去經歷過高度壓力的時期，我知道那是什麼樣子。 所以，我同樣對火焰不存在時感到感激，我正在學習在缺乏火焰時如何識別它，這樣我可以做一些不那麼緊張但仍然有用的事情，比如聽播客、看一些我標記為“稍後觀看”的視頻，做一些不那麼有壓力的工作，如回復郵件、做家務或整理家裡的東西。由於我的時間安排靈活，我也可能只是去散個步。

＃Push API指南 推送API允許網絡應用程序接收由服務器推送的消息，即使該Web應用程序在瀏覽器中沒有打開或者不在設備上運行。 是否受到支持？ 它是如何工作的 總覽 獲取用戶權限 檢查是否支持服務器工作者 檢查是否支持推送API 註冊服務器工作者 向用戶請求權限 訂閱用戶並獲取PushSubscription對象 將PushSubscription對象發送到服務器 服務器端如何工作 註冊新的用戶端訂閱 發送推送消息 在現實世界中… 接收推送事件 顯示通知 推送API允許網絡應用程序接收由服務器推送的消息，即使該Web應用程序在瀏覽器中沒有打開或者不在設備上運行。 使用推送API，您可以向用戶發送消息，從服務器推送到客戶端，即使用戶未在瀏覽站點。 這使您能夠提供通知和內容更新，從而使受眾更加參與。 這是巨大的，因為與本機應用程序相比，移動網絡的一個缺失的基礎是能夠接收通知的能力，以及離線支持。 是否受到支持？ 推送API是瀏覽器API的最新添加，目前Chrome（桌面和移動平台），Firefox和Opera支持自2016年以來，Edge自17版（2018年初）開始支持。查看有關當前瀏覽器支持狀況的更多信息，請訪問https://caniuse.com/#feat=push-api IE不支持它，Safari有自己的實現方式。 由於Chrome和Firefox支持它，大約60％的桌面瀏覽器用戶可以使用它，所以使用它是相對較安全的。 它是如何工作的 總覽 當用戶訪問您的Web應用程序時，您可以觸發一個面板要求許可權來發送更新。安裝了服務器工作者（Service Worker），並在後台運行，監聽推送事件（Push Event）。 推送和通知是一個獨立的概念和API，有時由於在iOS中使用“推送通知”詞彙而混淆。基本上，當使用推送API接收到推送事件時，調用通知API。 如果給予權限，您的服務器將通知發送到客戶端，服務工作者（Service Worker）接收到**推送事件（Push Event）**後將對此事件做出反應，觸發通知。 獲取用戶權限 使用推送API的第一步是獲取用戶允許從您接收數據。 許多網站在第一次頁面加載時執行此面板時錯誤，用戶還沒有確定您的內容是否好，他們將拒絕授權。請明智地運用。 有6個步驟： 檢查是否支持服務器工作者 檢查是否支持推送API 註冊服務器工作者 向用戶請求權限 訂閱用戶並獲取PushSubscription對象 將PushSubscription對象發送到您的服務器 檢查是否支持服務器工作者 if (!('serviceWorker' in navigator)) { // 不支持服務器工作者，返回 return } 檢查是否支持推送API if (!('PushManager' in window)) { // 不支持推送API，返回 return } 註冊服務器工作者 此代碼註冊位於域根目錄的worker.js文件中的服務器工作者。 window.addEventListener('load', () => { navigator....

在 JavaScript 中，探索與鍵盤事件的基礎互動。 在與鍵盤事件互動時，有3種類型的事件： 「keydown」鍵盤按鍵已按下。 「keyup」鍵盤按鍵已釋放。 當鍵盤按鍵保持按下並且重複時，也會觸發「keydown」事件。 雖然通常會在特定元素上監聽滑鼠和觸控事件，但在文件上監聽鍵盤事件很常見： document.addEventListener('keydown', event => { // 按下按鍵 }) 傳遞給事件監聽器的參數是KeyboardEvent。 此事件物件除了事件物件屬性外，還提供了其他一些獨有的屬性： altKey：如果事件觸發時按下了 Alt 鍵，則為 true。 code：按下的按鍵的代碼，以字串形式返回。 ctrlKey：如果事件觸發時按下了 Ctrl 鍵，則為 true。 key：按下的按鍵的值，以字串形式返回。 locale：鍵盤區域化值。 location：按鍵在鍵盤上的位置。 metaKey：如果事件觸發時按下了 Meta 鍵（例如 Command 鍵），則為 true。 repeat：如果該按鍵已重複（例如該按鍵尚未釋放），則為 true。 shiftKey：如果事件觸發時按下了 Shift 鍵，則為 true。 這個示例是一個按鍵記錄器，它會顯示我列出的部分屬性的值： 查看Key logger demo（@flaviocopes）在CodePen上的示例。

有一句古老的義大利諺語： L’ospite è come il pesce: dopo tre giorni puzza 它可以追溯到公元前250年至公元前184年的提托·馬佐·普勞托時期。 這句話的英文翻譯為「魚和訪客三天後都發臭」，雖然不知道為什麼，這句話被歸於本傑明·富蘭克林，而富蘭克林出生於這句諺語在「舊世界」已經流行的20世紀以後。 不管怎樣！ 當我說「點子就像魚」時，我指的是一旦你得到一個點子，它看起來就像是史上最偉大的東西。 我將這種觀念應用在新應用程式的點子上。 這肯定會很受歡迎！ 每個人都會使用我的應用程式！ 這也適用於新功能： 我確定我的用戶會認為這是一個很棒的新功能！ 等待三天，讓它沉淪。 三天後，這個點子就會開始發臭。你會看到它的所有失敗和缺陷。 這樣你就能更好地了解它。

瀏覽器開發工具是前端開發者工具箱中的基本元素，並且在所有現代瀏覽器中都可用。了解它們對您有什麼幫助的基礎知識。 瀏覽器開發工具 HTML結構和CSS HTML面板 CSS樣式面板 控制台 執行自定義JavaScript 錯誤報告 模擬器 網絡面板 JavaScript調試器 應用程序和存儲 存儲 應用程序 安全選項卡 審計 瀏覽器開發工具 我認為網站和 Web 應用程序的建構從來都不是一個容易的任務，就像後端技術那樣，但是總的來說，客戶端開發相對較容易。 一旦你弄清楚了 Internet Explorer 和 Netscape Navigator 之間的差異，並避免了專屬的標籤和技術，你所需要使用的只有 HTML，稍後是 CSS。 JavaScript 是一種用於創建對話框等功能的技術，但絕對不像今天這樣普及。 雖然許多網頁仍然是純 HTML+CSS 的形式，就像這個頁面一樣，但是許多其他網站則是在瀏覽器中運行的真正應用程序。 僅僅提供網頁的源代碼，像瀏覽器一樣過去一樣的那樣，是不夠的。 瀏覽器需要提供關於它們如何呈現頁面以及頁面當前正在做什麼的更多信息，因此它們引入了一個用於開發人員的功能：它們的開發人員工具。 每個瀏覽器都不同，所以它們的開發人員工具也略有不同。在撰寫本文時，我最喜歡的開發人員工具是由 Chrome 提供的，這也是我們在這裡討論的瀏覽器，儘管 Firefox 和 Edge 也有很好的工具。 HTML結構和CSS 最基本和常見的用法是檢查網頁的內容。打開開發人員工具時，你會看到的是元素面板： HTML面板 在左側是組成頁面的HTML。 在HTML面板上將鼠標懸停在元素上會突顯該元素在頁面中的位置，點擊工具欄中的第一個圖標可以點擊頁面中的元素並在檢查器中進行分析。 您可以將元素拖放到檢查器中，即時更改它們在頁面中的位置。 CSS樣式面板 在右側是應用於當前選中元素的CSS樣式。 除了編輯和禁用屬性之外，您可以通過點擊“+”圖標添加新的CSS屬性，並為所需的任何目標添加。 您還可以觸發選定元素的狀態，以便在活動、懸停或焦點時查看應用的樣式。 在底部，選中元素的框模型可以讓您快速查看邊距、填充、邊框和尺寸: 控制台 開發工具的第二個最重要的元素是控制台。 可以單獨查看控制台面板，也可以在元素面板中按下 Esc 鍵，它將顯示在底部。 控制台主要有兩個用途：執行自定義JavaScript 和錯誤報告。 執行自定義JavaScript 在控制台底部有一個閃爍的光標。您可以在這裡輸入任何JavaScript，它將立即執行。例如，嘗試運行： alert('test') 特殊標識符 $0允許您引用當前在元素檢查器中選中的元素。如果要將其作為 jQuery 選擇器引用，請使用 $($0)。 您可以使用 shift-enter 來編寫多行。在腳本的末尾按 enter 鍵運行它。...

＃ 什麼是資料 URL 資料 URL 是一種 URI 方案，提供了一種將資料嵌入到文件中的方法，它通常用於在 HTML 和 CSS 中嵌入圖像。 簡介 資料 URL 的外觀 瀏覽器支援 安全性 簡介 資料 URL 是一種 URI 方案，提供了在 HTML 文件中直接嵌入資料的方法。 假設您想要嵌入一個小圖像。您可以按照通常的方式，上傳圖像到一個文件夾，然後使用 img 標籤讓瀏覽器通過網路請求它： <img src="image.png" /> 或者您可以將其編碼為一種特殊格式，稱為資料 URL，這樣就可以直接將圖像嵌入到 HTML 文件中，這樣瀏覽器就不必再發送單獨的請求來獲取它。 資料 URL 可能會為小文件節省一些時間，但對於較大的文件，它們的缺點在於增加的 HTML 文件大小，特別是如果圖像在所有頁面都重新加載，那麼它們將成為一個問題，因為您無法利用瀏覽器的緩存功能。 此外，作為資料 URL 編碼的圖像通常比二進制格式的圖像稍大。 如果您的圖像經常編輯，那麼使用資料 URL 將不太實用，因為每次圖像更改時都需要再次進行編碼。 儘管如此，它們在 Web 平台上有其應用之處。 資料 URL 的外觀 資料 URL 是以 data: 開始的字串，後面跟著 MIME 類型格式。例如，PNG 圖像的 MIME 類型是 image/png。 接下來是逗號，然後是實際的資料。 文本通常以純文本方式傳輸，而二進制資料通常以 base64 編碼的方式進行傳輸。 以下是資料 URL 的示例：...

SwiftUI是開發iOS、iPadOS、watchOS和macOS應用程序的現代化方式。 它從“舊有”方式轉變，使許多現有的蘋果框架（UIKit，AppKit和WatchKit）變得過時。 這些框架有一個共同點：它們是命令式的。 作為程序員，您可以確定事物應該以每個像素為單位如何顯示。然後，您會對用戶事件作出響應並手動更新數據。在每次更改時，您還需要決定UI應該如何更改。 SwiftUI是一個完全的變革，因為它是反應式的，UI反映了數據的狀態。不再像在UIKit中“連接事物”。 而且，您需要編寫的代碼要少得多。如果以前曾使用UIKit編寫過iPhone應用程序，您將一直在想“就這樣嗎？”。 談到代碼，使用SwiftUI，您只需編寫代碼即可。不再使用StoryBoard或Interface Builder。 我認為這很完美，因為我可以將我的代碼存儲在Git中，並可以立即看到隨時間所做的更改，而不是一些XML的亂碼。 現在，如果您以前從未使用過UIKit，您可能不明白我的意思。這對您來說是好事，不用擔心。 由於蘋果能夠從頭開始使用SwiftUI，我們有很多優勢。 第一次接觸SwiftUI應用程式令人著迷。 以下是Hello World應用程式的代碼： import SwiftUI struct ContentView: View { var body: some View { Text("Hello World") } } 您導入SwiftUI模塊，並聲明一個符合View協議的結構。 該協議要求該結構具有一個名為“body”的計算屬性，該計算屬性返回“some View”。 這就是我們在結構內部做的事情。 “body”計算屬性返回一個類型為“Text”的單個視圖，其中包含內容“Hello World”。 由於您將始終在SwiftUI中看到“some View”使用，現在是解釋為什麼使用它而不僅僅是“View”的好時機。 該聲明強制“body”始終返回相同類型的視圖，這對於SwiftUI的工作方式至關重要。 其中一個原因是性能。為了具有高性能，SwiftUI需要將某些事情視為理所當然。其中之一是每個結構始終返回相同類型的視圖，以便可以輕鬆檢查是否需要在屏幕上重繪。 在這種情況下，我們返回一個“Text”視圖，這是我們的結構始終返回的視圖，而不管其狀態如何。