什麼是 Doctype

任何 HTML 文件都必須以文件類型聲明（Document Type Declaration），簡稱 Doctype，開頭，該聲明告訴瀏覽器該頁面使用的 HTML 版本。 任何 HTML 文件都必須在第一行開始以 文件類型聲明 （簡稱doctype）開始，該聲明告訴瀏覽器該頁面使用的 HTML 版本。 這個文件類型聲明（不區分大小寫）： <!DOCTYPE html> 告訴瀏覽器這是一個 HTML5 文件。 瀏覽器渲染模式 有了這個聲明，瀏覽器可以以標準模式來呈現文件。 如果沒有它，瀏覽器將以怪異模式來呈現頁面。 如果你聽過怪異模式，你必須知道瀏覽器引入這種渲染模式是為了使以「舊風格」編寫的頁面與使用的新功能和標準兼容。如果沒有它，隨著瀏覽器和 HTML 的發展，舊的頁面將破壞其外觀，而網絡平台在這方面一直非常保護（這是我認為其成功的一部分）。 瀏覽器基本上在未識別頁面為標準模式的情況下默認使用怪異模式。 你希望使用標準模式，並且 <!DOCTYPE html> 是實現它的方法。 對於 Internet Explorer <= 10 的使用者，還需要額外注意避免怪異模式，方法是在頁面的 <head> 標籤中，在加載任何腳本之前，插入以下內容： <meta http-equiv="X-UA-Compatible" content="IE=Edge"> 舊的 HTML 版本 HTML 有一套奇怪的版本： HTML（1991） HTML 2.0（1995） HTML 3.2（1997） HTML 4.01（1999） XHTML（2000） HTML5（2014） HTML 4.01 Strict 文件的文件類型聲明為： <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> XHTML 類似：...

什麼是 JAMstack？

了解 JAMstack 的意義以及這組技術的優勢 你在過去幾年中一定聽過 JAMstack 這個詞語。 JAMstack 是一組技術，結合使用以實現目標，如果你熟悉 LAMP 和 MEAN 的話，你可能已經知道了。 JAMstack 是什麼意思？ JAM 表示 JavaScript、API 和 Markup。 它描述了在創建網絡應用程式和網站時具有以下特點的趨勢： 有一個“愚蠢”的網絡伺服器（或者CDN），傳送運行應用所需的 HTML，通常是使用靜態站點產生器生成的。HTML 不是在伺服器上生成。 應用程式可以載入一些 JavaScript，從 API 中接收數據。頁面互動，如導航，可以導致從 API 獲取更多數據。認證也是通過 API 完成的。 這種新的方法是一種新的方式，與傳統的方式不同： 傳統網站提供應用程序中已有的內容（如靜態站點）。 基於 CMS 的網站從後端的數據庫中加載信息。 使用任何種類的後端語言進行服務器渲染的應用程式。 它也不同於具有服務器渲染部分的客戶端渲染網站（例如使用 React 構建）。JAMstack 完全不涉及服務器渲染。 使用 JAMstack 的優勢是什麼？ 它快速。HTML 已經生成並且網絡伺服器只需提供它，而無需進行從數據庫查找數據或為每個請求生成頁面 HTML 等任何後端操作。它可以通過 CDN（內容傳遞網絡）輕鬆提供。 它高效。由於沒有後端，所以沒有瓶頸（例如沒有數據庫）。 它更便宜，因為通過 CDN 提供資源比通過後端伺服器提供資源要便宜得多。 它更安全，因為後端僅通過 API 公開。 傳統的動態服務器渲染網站應用程序的方式（如 WordPress、Laravel 和 Rails）在許多情況下正被一種較輕的方式所取代。 一個典型的 WordPress 網站在每次頁面加載時可能對數據庫進行30-100次請求，這取決於安裝的插件數量。除非頁面被大量緩存，否則當一個 WordPress 網站在 Hacker News、Reddit 或任何其他大型網站上變得流行時，你會看到一個空白頁面-這意味著伺服器上發生了故障，因為該網站無法應對所有的流量。這往往是一個失去的機會，因為當網站以其最高的流行度時它無法運作。 相比於這些情況，提供一個靜態 HTML 頁面要有效得多，並且在 HTML 載入後可以根據需要仍然獲取動態數據，使用獨立的 API 呼叫。...

什麼是 Node 模組中的對等依賴？

對 package.json 文件中的 peerDependencies 字段進行簡單解釋 在一些 package.json 文件中，你可能會看到以下幾行代碼： { //... "peerDependencies": { "libraryName": "1.x" } } 你可能已經看過 dependencies 和 devDependencies，但沒有看過 peerDependencies。 dependencies 是你的項目所依賴的包。 devDependencies 是在開發階段所需的包。比如測試框架像 Jest，或是其他像 Babel 或 ESLint 這樣的工具包。 在這兩種情況下，當你安裝一個包時，它的 dependencies 和 devDependencies 會被自動安裝。 然而，peerDependencies 不同。它們不會自動安裝。 當一個依賴被列為 peerDependency，它並不會自動安裝。相反，包含該包的程式碼必須將其列為自己的依賴。 如果你運行 npm install，但沒有找到這個依賴的話，npm 會給你一個警告。 舉個例子，假設包 a 包含依賴 b： a/package.json { //... "dependencies": { "b": "1.x" } } 包 b 又要求包 c 為其 peerDependency： b/package.json { //... "peerDependencies": { "c": "1.x" } } 在包 a 中，我們必須將 c 添加為依賴，否則當你安裝包 b 時，npm 會給出一個警告（並且代碼可能在運行時失敗）：...

什麼是 SWC？

SWC 是一個越來越被提到的工具。 它可以將任何 JavaScript 或 TypeScript 代碼轉換為同樣適用於較舊的瀏覽器和現代瀏覽器的 JavaScript。 簡而言之，它是新的 Babel。 但更快。 據說速度快了 20 倍以上。 作為一個「普通開發者」，你不會直接使用它。 但它被其他工具使用。 近來我們可以看到對速度的持續關注。主要是因為工具改用了更優化的系統語言，例如 Rust，而不是像 JavaScript 這樣不太優化的語言，後者在其他用例中更為優化。 在 2022 年 12 月發布的 Vite 4 現在支援 SWC 而不是 Babel。這反過來又使其更快。 SWC 也被 Turbopack 使用，後者是由 Vercel 提供的 JavaScript/TypeScript 打包器/構建系統，並作為 Vite 和 Webpack 的替代方案。

什麼是 Webhook？

在編寫整合不同服務的程式碼時，使用 Webhook 是很常見的。 什麼是 Webhook？ Webhook 是一個 POST 請求處理器，它會等待有人呼叫它，在有人呼叫時進行某些工作。 讓我舉個例子。我使用 Paddle 來銷售我的 Bootcamp，每當有人註冊時，我的 Webhook 會被呼叫並傳遞一些 JSON 資料。 這些資料包括客戶的電子郵件、客戶姓名和已購買的產品。 然後，Webhook 負責將客戶添加到 Airtable 底稿中，並向客戶發送歡迎郵件和一些資訊。 在我這個特定的案例中，Webhook 是使用 Express 所建構的 Node.js 應用程式，但它可以是任何能夠接受網路請求且可從互聯網訪問的東西。我將它放在了一個 VPS 上，但也可以是一個無伺服器函數。 支付平台提供 Webhook 是很常見的 - 它們處理付款，然後讓你執行你可能需要執行的「事情」。 Webhook 的另一個使用案例是在你想要時在一台機器上執行任務。例如，所有部署平台都提供 Webhook，你可以呼叫該 Webhook 來觸發新的部署。 我在 Netlify 或 Cloudflare Pages 使用它。我在 IFTTT 上設定了一個任務，每天早上 8 點觸發部署程序，所以我前一天安排的文章現在被發佈了，因為它的發佈日期已經過去了。 這對於我的一貫性非常重要，因為我知道每天早上 8 點我的靜態網站的文章都會被發佈。我不再需要手動執行此動作。 許多無代碼工具允許你使用它們來創建自動化。它們是非常酷的。 如果你思考一下，Webhook 就是讓互聯網保持連接的黏合劑。它們確實讓我能運行我的業務，所以我對它們的存在感到感激。

什麼是CDN？

了解什麼是CDN以及它的用途 CDN代表內容交付網絡。 它是一組分佈在全球各地並相互連接的伺服器。 在幫助加快網站速度的背景下，它們的工作是分發資源（例如圖像、JavaScript文件、CSS和HTML），以便這些資源可以物理上靠近每個可能想要訪問您網站的用戶，從而改善連接速度並減少延遲。 CDN是最終的快取網絡，也是以最便宜的方式在全球範圍內提供內容。 訪問者將永遠不會訪問存放您文件的實際網絡伺服器，而是會訪問這些CDN伺服器，從而減少負載。 CDN提供： 速度，靠近用戶網絡可以提高速度並減少延遲 冗餘性，如果CDN的某個節點失效，其他節點可以處理流量 與從集中位置提供所有流量相比，帶寬和伺服器功率消耗較低的成本 在CDN節點級別增加額外的保護層的安全性。並非所有CDN都這樣做，但大多數CDN都這樣做，並且還引入了DDoS攻擊保護措施。 CDN從源伺服器獲取原始資源，並且只要源資源沒有更改，它將繼續提供其資源的本地副本。 每個CDN伺服器位於不同的大陸，並且根據CDN的建立方式，在大陸的不同地區也有分佈。 每家大型公司都使用CDN來提供資源，您也可以透過利用像Cloudflare、Amazon CloudFront、Google Cloud CDN、Azure CDN等公司的服務來使用CDN。 CDN也可以直接由您的網站主機集成。例如，我使用的是Netlify，他們集成了自動CDN，使我的網站在世界各地的每個位置都運行快速。

什麼是GB秒？

在AWS的術語中，了解什麼是GB秒。 AWS Lambda 使用一個稱為GB秒的度量方式來計算您的使用時間。 每個月您可以享有100萬次免費請求和400,000個GB秒。 GB秒是您的函數運行時間（以秒為單位）乘以消耗的RAM內存的數量。 它是一種計算出來的度量方式，通過將兩個其他的度量方式相乘來計算，這是一種合理的方式來衡量您的無伺服器函數在時間和內存方面消耗了多少資源。

什麼是JavaScript前端框架？

對前端框架的簡要介紹 網際網路在過去的幾十年中迅速發展，我們在網絡上可以建立的體驗的需求和複雜性也隨之增長，因此我們必須建立起以與移動應用和桌面應用競爭為目標的應用程式。 隨著時間的推移，組織和個人創建了大量的工具和庫，我們可以利用這些工具來簡化開發工作。 有些工具從未受到大眾的喜愛。 有些工具則被廣泛採用並廣泛使用。 這就是React，Vue.js，Angular，Ember，Svelte，Preact等工具的例子。 JavaScript框架幫助我們創建現代化的應用程式。現代化的JavaScript應用程式主要用於網絡，同時也支援大量的桌面和移動應用程式。 到2000年代初，瀏覽器的功能還不如現在強大。它們的性能要差得多，無法在其內部構建複雜的應用程式，並且當時人們甚至都不考慮開發工具。 一切都改變了，當Google推出Google Maps和GMail兩個在瀏覽器內運行的應用程式時。Ajax使非同步網絡請求成為可能，而隨著時間的推移，開發人員開始在Web平台的基礎上進行構建，同時工程師們致力於開發平台本身：瀏覽器，Web標準，瀏覽器API和JavaScript語言。 像jQuery和Mootools這樣的庫是第一批基於JavaScript開發的大型項目，並且一度非常流行。它們基本上提供了一個更好的API，用於與瀏覽器進行交互，並提供了解決各種瀏覽器之間錯誤和不一致性的方法。 Backbone，Ember，Knockout和AngularJS等框架是現代JavaScript框架的第一波浪潮。第二波浪潮，也就是現在的波浪潮，主要由React，Angular和Vue構成。 要注意的是，jQuery和我提到的其他項目仍然被廣泛使用，並且仍在積極維護，數百萬的網站都依賴它們。也就是說，技術和工具在不斷進化，作為一個JavaScript開發人員，你現在可能需要瞭解React，Angular或Vue，而不是那些較老的框架。 框架抽象了與瀏覽器和DOM的交互。我們不再通過在DOM中引用元素來操作它們，而是以一個更高的抽象層次以聲明式的方式來定義和交互元素。 使用框架就像使用C編程語言而不是使用彙編語言編寫系統程式。就像使用電腦撰寫文件而不是使用打字機。就像擁有一輛自動駕駛汽車而不是自己開車。 嗯，也不遠，但你明白我的意思。與使用低級API來操作元素並構建複雜系統來編寫應用程式不同，你現在可以使用由非常聰明的人所建立的工具來簡化我們的生活。

什麼是RFC?

RFC，全名為Request for Comments，是技術社區發表的文件。 在幾篇博客文章中，我提到“這項技術在RFC xxxx中定義”，或者“有關細節請參閱RFC yyyy”。 什麼是RFC？ RFC代表Request for Comments，現在在各種環境中都可以找到RFC，但在互聯網上，RFC通常指的是由工程師和計算機科學家撰寫的、針對在互聯網領域工作的專業人士的出版物。 RFC有著悠久的歷史，可以追溯到1969年的ARPANET時代。互聯網就是通過這種方式創建的，RFC是討論的起點，或者是人們用來實現實際軟件的協議實現細節。 名為Request for Comments的名稱，鼓勵社區就這些文件進行討論，最初這些文件以印刷形式傳播。 今天的RFC在成為正式的RFC之前，需要經過多個步驟，這可能需要數月甚至數年的討論。這是因為今天的RFC一旦發布，就不能再修改了。整個過程由IETF（互聯網工程任務組）管理。 RFC文件的修訂需要作為獨立的RFC發布，而舊的RFC則被標記為被新的修訂版取代。其他RFC則補充了舊的RFC所指定的內容。 例如，1992年的RFC 1349標題為“互聯網協議套件中的服務類型”，於1998年被RFC 2474標題為“IPv4和IPv6標頭中區分服務字段（DS字段）的定義”取代。 以下是一些非常有價值的經典RFC文檔。這些內容將在很長一段時間內保持相關性（我自己在20年前就在高中時期打印了其中一些，現在仍然保留著），並且是互聯網的基礎： RFC 791: IP RFC 793: TCP RFC 1034: DNS RFC 4291: IPv6 RFC 6749: OAuth 2.0 還有一些RFC是較少技術性的，比如RFC 1855 網絡禮儀指南，還有一些只是工程師間的有趣笑話，比如RFC2324，即Hyper Text Coffee Pot Control Protocol。 總之，RFC是經過嚴格的討論和技術驗證過程後被加入IETF認可的官方協議列表的技術文件，作為一個標準，它們可以由軟件供應商來實現。

什麼是反向代理？

了解什麼是反向代理以及其有什麼用處！ 在談到伺服器時，聽到「反向代理」這個詞是很常見的。 在本文中，我想解釋什麼是反向代理，以及它的作用。 首先，讓我們談一下「代理」這個詞。代理是一個伺服器，接受客戶端的連接，這些客戶端在其網絡設置中主動配置了代理伺服器。 當客戶端與伺服器建立連接時，請求始終通過該代理伺服器傳遞。 這種做法有幾種用途。公司和組織可以設置代理伺服器來過濾連接、提供更高的安全性並記錄流量。如果不使用代理，客戶端無法連接到外部網絡。代理伺服器還有助於提供隱私並避免國家政府對網絡的限制。 另一方面，反向代理是由伺服器設置的。對於客戶端而言，它是完全透明的，他們不知道這個中間人的存在，但它在伺服器上做了一個非常有用的工作，過濾請求並將它們發送到處理這些請求的相應服務。 常常使用Nginx作為反向代理（也可以參考我們的nginx反向代理文章），並且運行在內部端口上的Node.js服務不可以外界訪問。 在這種情況下，Nginx充當主要的請求處理程序，並將相應的請求發送到特定的服務，例如將特殊子文件夾或URL鏈接到特定服務。 我們可以有兩個完全不同的Node.js應用程序，而用戶不需要知道該信息。 除了我們開發人員主要使用的路由功能之外，反向代理還非常適合過濾和保護避免攻擊，作為防火牆，引入緩存，配置SSL，處理負載平衡，AB測試等等。