盡可能不設定 line-height 為 1 與 ellipsis 的原因
本文探討了為何在網頁設計中不建議將 line-height 設為 1，以及使用 ellipsis 時遇到的語言問題
目前分類：前端
近況
想跟大家分享一下自己接下來想要做的一些實驗，我進入軟體開發跟前端也已經快要邁入第一個十年了。經歷前端百花齊放的戰國時代，對於後續前端的變化和體悟都很有幫助。雖然部落格上已經分享了很多篇文章，但其實也還有很多想分享的事情沒有寫出來
與程式有關的遊戲三選 (1) – A=B
本篇為 IT 2023 鐵人賽文章：與程式有關的遊戲三選 (1) – A=B
比語意化標籤更重要的事
身為一位前端工程師，雖然我們不需要把全部的 HTML 標籤背得滾瓜爛熟，但是常見的 HTML 標籤與使用場景還是要有一定程度的了解，根據不同場景使用。 但是，使用語意化標籤的目的是什麼？我發現很多文章對於語意化標籤往往只停在表面，也就是討論某某標籤應該使用在哪裡，導致網頁上的標籤看似多彩繽紛，但使用者體驗卻沒有得到相對的提升。
用 Astro 寫電子報網站
探討在建立電子報網站的需求，最後選擇了 Astro 來建立網站。這篇文章會探討與其他靜態網頁生成器的比較以及最後選 Astro 的原因。
2022 Advent Of Code: Cathode-Ray Tube
突然想到要紀錄自己覺得有趣的題目，尤其是可以視覺化的東西。如果有多餘的力氣就把每天的題目都寫成筆記。總之，我覺得 Advent Of Code Day10 的題目還蠻有趣的，所以就先記錄一下。
HTML 和 CSS 能解決很多問題，但 JS 也很重要
在 2017 年時曾經讀過一篇文章，主要是分享各種用 HTML/CSS 就能達成的排版技巧。第一次閱讀時覺得深有同感，也學到很多當時還不熟的技巧，很推薦大家看看。雖然 JavaScript 幾乎可以解決大部分問題，但從無障礙設計的角度、效能跟 bundle size 的角度來看，能夠用 CSS 解決一定是比較好的。然而，盡量不要用 JS 不代表完全不用 JS，這兩者還是有些差別的。這篇文章會重新閱讀一次上面提到的文章，並且點出一些我覺得能夠改善的地方。
排版時有用的 Pseudo 類別
用 CSS 排版時，我們會根據樣式使用對應的 CSS 處理，有時甚至需要使用 JavaScript 來完成，不過在 CSS 其實有許多 pseudo classes 只要善加利用可以簡化 CSS，也可以減少不必要的 JavaScript 實作，而且不再像過去一樣只有少數的瀏覽器有支援。
用 Next.js 重寫整個部落格
記錄了將部落格從 Gatsby 遷移到 Next.js 的過程與感想。包含使用的技術以及實作細節等等。
探討 remix 的表單與資料讀取機制
雖然說可能不少人又會覺得「哎呀，怎麼又一個框架」，不過 remix 的確有它的獨特之處，如果有翻過文件而且追過最顯而易見的是
node.js 讀取檔案時的細節
在 node.js 當中透過 fs 模組來操作檔案是相當常見的操作，然而如果在吞吐量比較大的情況下，任何有關 IO 的操作都應該非常小心
將 Sentry 的 Web Vitals 整合到 slack
現在許多網站都會導入測量 Web Vitals 的流程，透過量化指標找到可以改善的地方。不過比較少人知道的是其實 sentry 在之前也推出了 Web Vitals 的統計功能，能夠統計 Web Vitals 的各個指標如 LCP、FP、CLS，讓開發者可以在後台看到相關的圖表，甚至把平均值都標好了，相當貼心。
從前端視角看 SwiftUI
從 UI 的角度來看，前端與手機開發會遇到問題是類似的，儘管使用的語言或是開發手法不盡相同，我們都需要打造一個易用的使用者介面。既然如此，彼此也會遇到類似的問題，元件化開發、狀態管理、資料流、管理副作用（API 或是 IO）等等，對我來說是個很適合互相學習的領域。
用 WebGL 畫線比我想像中地還難
WebGL 不支援 lineWidth 大於 1 的線條，連 Three.js 也沒有支援可調整寬度的線條實作，於是開始了自製線條的實作
如何判斷兩個網域的擁有者是否相同？
在瀏覽網頁時，我們時常透過 subdomain 來區分服務的內容，然而要區分一個網站是否為 subdomain，或是兩個網站是否為 SameSite 似乎沒有想像中的簡單。
useMemo 的幾個使用場景
在前端應用當中，很常會遇到一個情形是在畫面上顯示的值是透過其他的值複合計算而成；或是先經過某種計算再放入畫面當中。通常這類型的處理都可以用 useMemo 來簡化程式碼
從 prismjs 改為 shiki
shiki 是一個將程式碼語法做高亮的套件，跟其他套件（highlightjs, prismjs）算是比較新一些，也比較少人知道。主要是因為它支援的語法更多也比較好設定，內建的主題也蠻多的，就順手把原本的 prismjs 換掉。
前端焦慮症
本篇文章僅為表達自身觀點與想法，對於同行業人員沒有任何批判之意。我認為目前前端領域（此處指網頁開發）逐漸趨於成熟，前端框架採用元件化的中心思想與響應式機制，搭配框架特有的語法、開發手法與哲學，可以應付大部分的使用場景。
在瀏覽器上透過 Arduino 讀取溫濕度 - Web Serial API
Google Chrome 89 推出了 Web Serial API 讓外接設備透過瀏覽器 API 直接互動，包含 USB 設備或是有 Serial 介面的藍牙設備。這樣一來瀏覽器就能與硬體直接溝通。
form 標籤與 FormData 的應用
本篇文章會介紹瀏覽器背後會怎麼處理 form 標籤，以及在 JavaScript 上怎麼運用 FormData 來簡化表單操作
一起理解 HTML 當中的 Form Data
表單在網頁中是相當常見的應用，不只能夠傳輸純文字，也能夠達到檔案上傳的功能。不過也因為 form 的行為跟其他傳輸方式較為不同，有時候也產生疑惑與誤解。 這篇文章試著從閱讀規範理解來龍去脈後，深入理解 form 背後到底做了哪些事情，以及表單與其他傳輸方式的不同之處，最後再提及 HTML 的 form 標籤背後做了哪些事情。
深入理解 Svelte（2）— 分析 Svelte 生成程式碼
從 Svelte 的核心理念可以得知，Svelte 希望從編譯過程中盡可能地獲取必要資訊，減少在動態的 overhead。上一篇文章中說明了 Svelte 從編譯到生成程式碼是如何運作的，今天要來觀察一下 Svelte 生成的程式碼是怎麼運作的。
2022 年值得學習 Svelte 的四個理由
Svelte 關注度逐年攀升，這篇文章整理了幾個 2022 年值得學習 Svelte 的理由，同時也會來談談 Svelte 使用上的缺點。
深入理解 Svelte（1）— Svelte 編譯過程
為了生成最後的程式碼，Svelte 必須將元件編譯一次獲取必要資訊，Svelte 的編譯過程到生成程式碼主要會通過幾個階段，在本篇文章會一一介紹
深入理解 Svelte（0）— 什麼是抽象語法樹？
這一系列的文章以探討 Svelte 原理實作為主，希望能讓讀者對於 Svelte 的編譯機制與程式碼生成有更深入的理解。由於 Svelte 編譯過程涉及程式碼解析，因此這一篇文章主要會先討論抽象語法樹是什麼，並進一步說明抽象語法樹扮演的角色與重要性。
Hotwire 與 Turbolinks
Turbolinks 是一個 JavaScript 套件，通常會搭配 Ruby on Rails 一起使用（單獨當作函式庫使用也可以），主要是透過 fetch HTML 直接抽換的方式來避免直接換頁要重新發送請求、CSS 的成本。其實說「不需要使用 JavaScript」不完全正確，JavaScript 還是在，只是在函式庫那邊已經幫你處理好，所以開發上可以不用寫 JavaScript 而已。
linaria - 不需要 runtime 的 CSS-in-JS 解決方案
linaria 是一個強調沒有 runtime 的 css-in-js 的函式庫，可以用與 styled-components 類似的語法，但是在編譯時期生成 CSS，進而減少動態修改樣式的 overhead
資料視覺化 — 台灣性侵害統計簿
這次想實作這個主題是因為看到新聞加上資料也相對齊全的關係，想說剛好也可以推廣 Svelte 本身，就一邊構想一邊把他實作出來了。
對於 SSR 的思考與使用場景
在瀏覽器爬取網頁的時候，爬蟲會將網頁的 HTML 內容爬過後產生內容，也會作一份快取在資料庫當中並且定時更新。也就是說如果沒有實作 SSR 的話，那麼 html 檔案本身會是一片空白，需要等到 JavaScript 被解析且執行後才能看到實際頁面
Vue ref 語法糖與 Svelte
Vue 作者尤雨溪最近提出了一個 RFC，是關於 ref 宣告的語法中可以用 JavaScript 的 label statement 來進一步做簡化。這個語法跟 Svelte 如出一徹，在這邊紀錄一下自己的想法。