Forking the Web：Dillo 瀏覽器對現代 Web 的哲學批判
Dillo Browser Lab · 2026-05-09
Dillo 瀏覽器團隊發表長文〈Forking the Web〉，提出將現代 Web 「分叉」為兩條路徑的構想：一條是現有的複雜 Web（完整 JavaScript、巨大 CSS、SPA 框架），另一條是回歸 HTML 靜態文件精神的簡化 Web，在 HackerNews 獲得 103 則回應，Lobsters 累積 43 票。
核心論點
文章認為，現代 Web 的複雜性已超出任何一個瀏覽器開發者或小型組織能夠跟上的範圍，維護 Chromium 或 Firefox 的完整規格相容性需要數千名工程師與數億美元年度預算。這個複雜性並非技術必然，而是商業利益驅動的累積。
Dillo 提出的分叉構想不是要「打倒」現有 Web，而是在其旁邊建立一個具備穩定規格、完整可實作的替代棲息地，讓文件型內容（文章、文件、說明書）能夠在輕量瀏覽器上被正確呈現。
技術背景
Dillo 本身以 C++ 撰寫，可執行檔約 500KB，啟動時間在毫秒級。它不支援 JavaScript，CSS 支援有限，但對於純文字與圖片為主的內容表現良好。文章引用了多個近年出現的類似計畫——Ladybird（SerenityOS 分支出的新瀏覽器）、NetSurf——作為社群中對輕量 Web 實作需求的佐證。
影響範圍
這場討論觸及一個長期存在的工程矛盾：Web 作為通用應用平台所需的能力，與 Web 作為文件媒介所需的簡單性，兩者之間的張力從未消解。HackerNews 討論串中，有開發者提到以 Gemini 協議（gemini://）作為平行實驗，另有人認為 RSS 的復興也是同樣衝動的另一個出口。
原始來源：Dillo Browser Lab
「我禁止了查詢字串」：URL 設計的激進主義實驗
chrismorgan.info · 2026-05-10
開發者 Chris Morgan 發表〈I've banned query strings〉，記錄他在個人專案中完全禁用 URL query string（?key=value），改以路徑片段（path segments）或 POST body 傳遞參數的實驗，文章在 HackerNews 引發 117 則討論，Lobsters 上同一主題的對應文章〈I Will Not Add Query Strings to Your URLs〉獲得 38 票。
核心論點
作者認為 query string 的問題在於它混淆了資源識別（resource identity）與動作參數（action parameters）的語意邊界。以過濾條件為例：/products?category=books&sort=price 將篩選狀態嵌入 URL，使得書籤、快取、以及 HTTP 語意（GET 的冪等性）都變得模糊。
替代方案依場景分為：一、搜尋與過濾改用 POST + body；二、資源子集以路徑表達（/products/category/books/sorted/price）；三、狀態切換用獨立端點。
技術取捨
禁用 query string 最直接的代價是破壞瀏覽器的分享連結語意：過濾後的搜尋結果頁面無法以單一 URL 表達。作者認為這個代價是可接受的，因為搜尋結果的「永久連結」概念本就模糊。但評論區指出：OAuth、OIDC、email 確認連結等都高度依賴 query string，完全禁用在實際系統中不可行。
影響範圍
此文的工程意義不在於倡導廣泛採用，而在於它迫使開發者重新思考：我們在 URL 裡放的東西，是資源的一部分，還是操作的參數？ 這個問題在 REST API 設計、GraphQL endpoint 命名、以及 SPA routing 的實作中反覆出現但鮮少被明確回答。
OpenAI 的 WebRTC 困境：MoQ 為何是即時媒體傳輸的更好選擇
MoQ Dev Blog · 2026-05-09
MoQ（Media over QUIC）的 blog 發表〈WebRTC is the Problem〉，藉由 OpenAI 在即時音訊串流上遭遇的問題，系統性地論證 WebRTC 作為即時媒體協議的結構性缺陷，以及以 MoQ over QUIC 取代的動機，在 HackerNews 獲得 139 則討論，Lobsters 獲得 17 票。
WebRTC 的結構性問題
WebRTC 設計於 2011 年，預設場景是瀏覽器對瀏覽器的點對點通訊。當應用場景轉變為伺服器側的 AI 語音串流時，WebRTC 的幾個假設開始失效：
- NAT traversal（ICE、STUN、TURN）對伺服器端應用無意義，增加延遲與複雜度
- SDP（Session Description Protocol）的協商語意複雜，實作間相容性問題頻繁
- SRTP 在高丟包環境下的恢復機制（NACK、PLI）設計給瀏覽器到瀏覽器，不適合 CDN 或伺服器中繼架構
MoQ 的方法
MoQ（IETF 工作組草案 draft-ietf-moq-transport）建立在 QUIC 之上，以發布/訂閱（pub/sub）語意取代 WebRTC 的點對點模型。QUIC 的多路復用（multiplexing）與不依賴 HOL blocking 的 stream 機制，使其在高延遲、高丟包網路下的表現優於 WebRTC 的 RTP/UDP 組合。中繼（relay）節點的加入也更自然，不需要 SFU/MCU 的複雜信令。
影響範圍
OpenAI 的 WebRTC 問題引發了對「即時 AI 語音 API 的正確底層協議」的討論。MoQ 尚在 IETF 草案階段，瀏覽器原生支援有限，但已有 Cloudflare、Meta 等公司在試驗。下一代即時 AI 互動應用的傳輸層仍在醞釀中，此文是當前討論的重要基準點。
原始來源：MoQ Dev Blog