各家首頁 JavaScript 的大小

看到「JavaScript Bloat in 2024 (tonsky.me)」這篇在講各家首頁 JavaScript 的大小,原文在「JavaScript Bloat in 2024」這邊。

作者 Nikita Prokopov 創造了很多 open source project,我比較有印象的是 Fira Code,這篇比較像是他在抱怨現在的網站...

裡面站台一堆都是 10MB+ 的 JavaScript 在跑的,突然提到 P 站只有 1.4MB 的時候笑了出來 (在 Hacker News 的 comment 裡面也有人提到這個):

Compare it to people who really care about performance — Pornhub, 1.4 MB:

另外 Jira 也被拿出來鞭:

Here, Jira, a task management software. Almost 50 MB!

但趨勢看起來不可逆?現在開發網站一堆都搞前後端分離,用 JavaScript 產生出所有頁面,然後再想辦法補 SEO...

展開所有 GitHub comment 的 Bookmarklet

看到 Eric Meyer 弄了一個可以展開 GitHub comment 的 bookmarklet:「Bookmarklet: Load All GitHub Comments」。

分析他的程式碼,稍微手動排一下,可以看出來邏輯蠻簡單的,就是去找出對應的 button,然後模擬按下去的 event:

javascript:function start() {
  let buttons = document.querySelectorAll('button');
  let loaders = [];
  for (let i = 0; i < buttons.length; i += 1) {
    if (buttons[i].textContent.trim() == 'Load more%E2%80%A6') {
      loaders.push(buttons[i]);
      buttons[i].dispatchEvent(new MouseEvent('click', {
        view: window,
        bubbles: false
      }))
    }
  }
  if (loaders.length > 0) {
    setTimeout(start, 5000)
  }
}
setTimeout(start, 500);
void(20240130);

意外可以看到一些應該是作者以前寫習慣的寫法 (畢竟 Eric Meyer 這個名字二十年前就聽過了?),現在 for 拿來當 iteration 應該會用 of 的語法了,另外是 letconst 的差異...

還好這邊還是用 querySelectorAll(),而不是直接看到 getElementsByTagName(),不然就更有考古感了...

拿「Quadratic time internal base conversions #90716」這個測了一下還行,不過我不是那麼常用到,大概不會掛到 bookmark bar 上面...

作者有提到考慮過寫成 userscript,不過看起來是懶 XD

jQuery 4.0.0 Beta (啊,居然)

看到 jQuery 的公告「jQuery 4.0.0 BETA!」這篇,有種「啊,居然」的感覺冒出來...

要注意這個版本放掉了 IE10 以及更早的版本,但還是有支援 IE11,目前計畫到 jQuery 5.0 才會拔掉:

jQuery 4.0 drops support for IE 10 and older. Some may be asking why we didn’t remove support for IE 11. We plan to removes support in stages, and the next step will happen in jQuery 5.0.

另外一個頗大的改變是 source 端改成 ES module 了,這樣對 jQuery 團隊開發上應該會方便不少 (很多現代工具的引入):

jQuery source migrated to ES modules

It was a special day when the jQuery source on the main branch was migrated from AMD to ES modules. The jQuery source has always been published with jQuery releases on npm and GitHub, but could not be imported directly as modules without RequireJS, which was jQuery’s build tool of choice. We have since switched to Rollup for packaging jQuery. And we also run tests on the ES modules before packaging them.

這有種古蹟改建的味道啊...

SQLite 官方提供的網頁版 playground

Hacker News 上看到「Sqlite3 Utility in the Browser (sqlite.org)」這個,看了一下是官方提供的 playground:「SQLite3 Fiddle」。

https://sqlite.org/fiddle/fiddle.js 這邊可以看到 2022 年就有的東西,在 Internet Archive 上也可以看到也是差不多時間被記錄下來的:「Saved 21 times between August 12, 2022 and January 24, 2024.」。

看起來是用 WebAssembly 包起來的,不過如果是自己的機器,本機跑 sqlite3 好像會方便一些...

修好 Trac 1.6 上的 TracSubtickets

Trac 1.6 總算從死了三年的 Python 2.7 換成了 Python 3,所以算是蠻強大的升級動力,但也可以想像到相關的 plugin 其實因此爛了不少,加上 Trac 現再用的人愈來愈少,沒有人會修這些問題,所以你就得當「沒有人」跳下去修...

標題上提到的 TracSubtickets 算是這樣的一個套件,他的概念很好用,但大概從 Trac 1.2 以後就沒什麼更新了,先前有遇到 MySQL 8.0 的資料庫搭配起來會撞到關鍵字而出錯,得自己修。

而這次遇到的問題是 TracSubtickets 在頁面輸出子票資訊時用到 ITemplateStreamFilter 這個功能,而從官方文件開頭也可以看到問題:Trac 1.4 的時候內部的 template engine 就從自家研發的 Genshi 換成了 Python 社群用的更廣泛的 Jinja2,但當時只是先標成 deprecated,還沒到不能用,直到 Trac 1.5.1 時拔掉了,所以接下來的 Trac 1.6 就沒得用了。

在官方的「Replacing the ITemplateStreamFilter interface」有提出建議的方法,是用 JavaScript 改 DOM:

The only way left to alter the generated content is to perform these modifications dynamically on client-side using JavaScript.

我看了半天 Trac 1.6 的程式碼,看起來的確沒有什麼比較好的方法可以處理... 只能回來照官方的方法走,後續的問題就是看要處理的多乾淨 (或是多髒)。

因為 Trac 本身沒有 client template engine (像是 React 或是 Vue 之類的),我決定這邊還是讓 server 端全部把 html string 都產生出來,再由 client 端生一個 div 直接用 innerHTML 塞進去:這樣就不用傳一包 JSON 到 client 端慢慢組了...

於是就出現了這包 diff/patch:「Comparing cae40fb..master · gslin/trac-subtickets-plugin」。

基本的思路是,既然以前的 filter_stream() 是產生 html tree 的程式碼,那就重複拿來用,把結果輸出轉成 html string,用 add_script_data 丟到 window 下的 global variable (喔耶),再寫一段 javascript 把這串東西塞進本來在的 DOM 位置。

這樣至少就能動了...

uBlock Origin 可以修改 DOM event

Hacker News 上看到的「Just normal web things (heather-buchel.com)」這篇,原文「Just normal web things.」本來在抱怨一些 SPA 年代常遇到的問題,但我注意到的反而是討論裡的 id=37018421 這則,介紹了 uBlock Origin 可以修改特定的 DOM event:

New Reddit also messes with text selection with unnecessary JS crap. Wherever you select some text, they show an "Embed" button that prevents you from dragging the text to a new tab to perform a web search.

Thankfully this behaviour can be blocked with uBlock Origin by adding these rules:

  www.reddit.com##+js(aeld, mousedown, isSelectionOutOfRange)
  www.reddit.com##+js(aeld, mouseup, shouldShowButton)

翻了 uBlock Origin 的 wiki 文件,這應該是 aeld.js / addEventListener-defuser.js 這個功能:

Prevents attaching event listeners.

aeld 可以阻止某些事件掛到 DOM 元素上,這感覺好像可以少寫不少 userscript,單純用 uBlock Origin 設條件就可以做到了?

另外在同一頁上 (Resources Library 這頁) 也有其他有趣的東西,像是拔掉 timeout 設定或是某些 attribute 的內容,另外也可以對 API 傳回來的 JSON 或 XML 內容進行刪除某些欄位...

算是意外注意到,後續希望遇到的時候可以想起來...

透過 mDNS 建立內部網路的 fingerprint

Hacker News 上看到透過 mDNS 建立 fingerprint 的方式,進而定位使用者身分:「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」,原文在「Demo: Brute-forcing a macOS user’s real name from a browser using mDNS」。

利用發 HTTP(s) request 出去時,雖然都是傳回 Failed to fetch 錯誤,但因為 hostname 存在時會是 connection timeout,而不存在時會直接因為 DNS 查不到而很快 failed 掉,這個時間差異產生了 side channel,可以透過時間差異知道某個 hostname 是否存在。

這個技巧配合字典就可以大量掃描 *.local 的 mDNS 網段,進而產生出內部網路的 fingerprint。

這個問題應該是有標準解法 (或是有被提案過的解法),就是不讓 internet domain 存取 local domain 的東西,像是避免 internet 上的網站透過 JavaScript 碰到 http://127.0.0.1:xxx/ 的機制。

應該是把 *.local 用同樣方式對待就能避開這個問題?

改善 Wikipedia 的 JavaScript,減少 300ms 的 blocking time

Hacker News 首頁上看到「300ms Faster: Reducing Wikipedia's Total Blocking Time」這篇,作者 Nicholas RayWikimedia Foundation 的工程師,雖然是貼在自己的 blog 上,但算是半官方性質了... 文章裡面提到了兩個改善都是跟前端 JavaScript 有關的。

作者是透過瀏覽器端的 profiling 產生火焰圖,判讀裡面哪塊是大塊的問題,然後看看有沒有機會改善。

先看最後的成果,可以看到第一個 fix 讓 blocking time 少了 200ms 左右,第二個 fix 則是少了 80ms 左右:

第一個改善是從火焰圖發現 l._enable 吃掉很多 blocking time:

作者發現是因為 find() 找出所有的連結後 (a 元素),跑去每一個連結上面綁定事件造成的效能問題:

The .on("click") call attached a click event listener to nearly every link in the content so that the corresponding section would open if the clicked link contained a hash fragment. For short articles with few links, the performance impact was negligible. But long articles like ”United States” included over 4,000 links, leading to over 200ms of execution time on low-end devices.

但這其實是 redundant code,在其他地方已經有處理了,所以解法就比較簡單,拔掉後直接少了 200ms:

Worse yet, this behavior was unnecessary. The downstream code that listened to the hashchange event already called the same method that the click event listener called. Unless the window’s location already pointed at the link’s destination, clicking a link called the checkHash method twice — once for the link click event handler and once more for the hashchange handler.

第二個改善是 initMediaViewer 吃掉的 blocking time,從 code 也可以看到問題也類似,跑一個 loop 把事件掛到所有符合條件的元素上面:

這邊的解法是 event delegation,把事件掛到上層的元素,就只需要掛一個,然後多加上檢查事件觸發的起點是不是符合條件就可以了,這樣可以大幅降低「掛」事件的成本。

這點算是常用技巧,像是 table 裡面有事件要掛到很多個 td 的時候,會改成把一個事件掛到 table 上面,另外加上判斷條件。

算是蠻標準的 profiling 過程,直接拉出真實數據來看,然後調有重大影響的部分。

瀏覽器裡同一個節點上 JavaScript 的事件觸發順序

瀏覽器裡 JavaScript 的事件觸發順序是先 capture 再 bubble,這個在「Event order」這邊就有一些歷史解釋,IE8 以前只有 capture 模式,到了 IE9+ 才支援,在「Event API: bubbles」這邊也可以看到。

但如果是同一個節點上面的事件觸發順序 (假設同樣是 capture 或是同樣是 bubble),在「Are event handlers in JavaScript called in order?」這邊有些整理資料。

2000 年的「Document Object Model (DOM) Level 2 Events Specification」這邊提到沒有定義順序:

When the event reaches the target, any event listeners registered on the EventTarget are triggered. Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget.

在早期的 draft「Document Object Model (DOM) Level 3 Events Specification」裡面可以看到:

Next, the implementation must determine the current target's candidate event listeners. This must be the list of all event listeners that have been registered on the current target in their order of registration. [HTML5] defines the ordering of listeners registered through event handler attributes.

但在最新的「UI Events」(要注意這還是 draft,在 2016 年更新的) 則是拿掉了這段。

所以在設計架構時,正常還是得保守的假設沒有保證執行順序...