從 pretext 看 AI 如何帶給前端開發新典範

這兩天在網頁前端開發界最熱門的話題，莫過於 pretext 這個協助做多行文字排版的開源專案，在作者公開分享後第三天，GitHub 上面已經超過一萬五千顆星星，原作者的貼文超過一千九百萬次瀏覽。在社群當中，也可以看到非常多基於 pretext 做出來的酷炫展示。

很多人看到這些展示 (例如截圖是原作者最開始發的貼文，可以看到當畫面中的球位置改動，環繞的文字要跟著改變位置)，可能直觀的反應是「這不是原本的技術就做得出來嗎?」，這樣 pretext 這個開源函式庫提供了什麼額外價值?

雖然說在不用 pretext 的狀況下，前端工程師還是可以直接呼叫瀏覽器的 DOM API (例如 getBoundingClientRect) 來拿到相關資訊，藉此來調整文字的排版，但是這種做法可能讓瀏覽器得同步重新計算版面配置(俗稱 reflow)，這對瀏覽器的性能有極大的負擔，特別是畫面中元素多的時候。

當瀏覽器的 CPU 被用來計算頁面中不同元素的長寬與間距，在計算的期間，可能會無暇處理其他任務。例如使用者在點擊按鈕，可能需要等一陣子才有回應，因為瀏覽器無暇處理，進而傷害使用者體驗。對 reflow 有興趣的讀者，我們把先前寫過的技術文放在下方留言。

pretext 的突破之處

Pretext 這個專案做的突破在於，該專案提供函式，讓前端開發者不用呼叫 DOM API，就能夠計算多行文字高度，藉此做到動態的排版，卻又不會觸發回流，也就不會造成瀏覽器的卡頓。因此，社群中那些酷炫展示，看點不是既有技術能否實作出來，而是在於非常流暢不會有卡頓。

更進一步說，pretext 讓前端工程師可以在畫面實際渲染之前，就知道文字排版結果，這讓很多原本很難實作的 UI 變得容易許多，從虛擬化列表、自適應寬度元件，到文字環繞動畫，都能用比以前更簡易的方式實作。

在理解 pretext 做的事情後，有一個我們覺得最值得討論的點，那就是「為什麼這個專案現在才有」? 或者換個角度問，pretext 就只是個 TypeScript 函式庫，本身沒有依賴任何近期才出現的東西，那為什麼以前沒人寫相關的函式庫呢?

之所以過去沒有，是因為要做好這件事非常麻煩。各種不同的語言在文字處理上有非常多眉角，很可能出現各種想不到的極端案例 (edge case)，讓排版整個炸掉。在過去看過利用 canvas 的 measureText 的函式庫，也有排版計算的解決方案，但沒有到 pretext 這種程度。

如果要做到像 pretext 這種能處理多語言的不同斷句規則、混語言排版 (例如同時有右到左，又有左到右的句子)、Emoji，然後又要 Chrome、Safari、Firefox 都能兼顧 (UI 因為換瀏覽器炸掉，是很多前端開發者的痛)，要處理非常非常多細節，這些細節多到 pretext 的作者用「從地獄爬回來」形容。

AI 協助測試極端案例

而該作者之所以能順利從無止盡的極端案例地獄爬出來，正是透過 AI。該作者 Cheng Lou 分享，他透過 Claude 與 Codex 建立一個讓 AI 跑驗證的迴圈，在不同案例下，對比呼叫瀏覽器實際渲染出來的結果，然後如果有案例沒通過，就讓 AI 修正排版的演算法。假如看 pretext 原始碼，每個瀏覽器對應的測試案例都有七千多個案例 (長達七萬多行)。而這個極端案例地獄不是作者自己爬，而是 AI 幫忙爬出來的。

AI 幫忙處理各類讓人類覺得麻煩的案例，讓好的想法能夠最終被實踐出來，也讓網頁前端開發的文字排版有了新典範。在看到 pretext 作者的分享，沒有覺得 AI 取代掉前端工程師，反而是感謝 AI 幫忙解決那些人不想做的苦差事。

備註：如果對於用 AI 協助開發感興趣，我們最近推出了《AI Coding 從實戰到最佳實踐》線上課，從實戰延伸，講解有哪些最佳實踐能幫助大家在使用這些 AI 工具時，以更精準、有效且節省成本的方式讓開發做得更好。感興趣的讀者，歡迎加入 E+ 觀看 (連結)