如果有看過我的部落格的話，應該會知道我一直都是寫 React，完全沒有碰過 Vue，也沒有碰過 Angular。自從 2015 年接觸到 React 後，工作上就一直是用 React 了。

然而，最近因為工作上的需求，所以開始寫 Vue 了，而剛好也有讀者來問我從 React 跳到 Vue 的心得，因此這邊就簡單寫一篇來分享。

閱讀更多

你知道嗎，當你跟朋友在討論 SSR 的時候，很有可能你們對 SSR 的認知其實是不一樣的。直接舉個例子，底下這幾種情境，你覺得哪些算是 SSR？

1. 由後端 PHP 產生畫面
2. 前端是 React 寫成的 SPA，但後端如果偵測到搜尋引擎，就會切換另一種 template，輸出專門針對搜尋引擎的模板，而非 React 渲染出的頁面
3. 前端是 React 寫成的 SPA，但透過 Prerender 先把頁面 render 成 HTML，再交給搜尋引擎（一般使用者依然是 SPA），跟上一個的差別是使用者跟搜尋引擎看到的畫面基本上一致
4. 前端是 React 寫成的 SPA，在後端用 renderToString 把 React 渲染成字串，但是沒有資料，資料會在前端拿
5. 前端是 React 寫成的 SPA，後端會針對每個 page 先呼叫 API 拿資料，拿完以後才呼叫 renderToString 輸出 HTML，在 client 端時會做 hydration 讓頁面可以互動

有一種人認為只要是由後端產生出畫面，就叫做 SSR，所以 1 ~ 5 全部都是 SSR。也有一種人認為前端必須先是 SPA，此時搭配的後端才能叫做 SSR，所以 2~5 都是 SSR；而另一種人則認為 SSR 的重點是 hydration，所以只有 5（或是 45）是 SSR。

閱讀更多

有些網站會用 GIF 來做一些圖檔，畢竟會動嘛，看起來就比一些靜態的圖片還要厲害，還要來得更吸引人。或其實不只是因為吸引人，而是有些需求本來就需要一個會動的圖，例如說貼圖，會動是很正常的。

但是 GIF 的缺點之一眾所皆知，就是檔案很大，真的很大。尤其是手機上因為解析度比較高，可能會需要用到三倍大小的圖片，就算只顯示 52 px，也要準備 156px 的圖檔，佔的空間就更多了。以網頁來說，當然是要載入的資源越少越好，越小也越好。

閱讀更多

這陣子在 Front-End Developers Taiwan 臉書社團上有一系列關於 Tailwind CSS 的討論，起因是另一篇已經刪除的貼文，那篇貼文我有看過，因為怕原文內容跟記憶內容有落差，因此這邊就不講我記憶中的原文大概是在寫什麼了，畢竟這也不是這篇所關注的重點。

總之呢，那篇貼文引起了臉書上前端社團的熱烈討論，在短短兩三天內迅速多出許多討論相關技術的文章。

而有許多人在討論的議題，其實比起 Tailwind CSS 這個工具，更多的是在討論 Atomic CSS 這個概念本身。

閱讀更多

如果你的網站想要搶先體驗瀏覽器還沒有正式上線的新功能，該怎麼做呢？

通常這些功能已經做好了，只是沒有開放而已，因此瀏覽器都會提供一些可以開關的 flag，只要把開關打開，就能夠搶先體驗到新功能，但我們通常不太可能叫使用者自己把開關打開。

因此，Chrome 提供了一個機制叫做 origin trials，你可以在網站上註冊，取得一組 token，接著只要設置好以後，如果使用者是用 Chrome 造訪你的網站，那就會開啟新功能，讓你的網站可以使用。

這篇就來簡單介紹一下這個機制該如何使用。

閱讀更多

Same site 跟 same origin 雖然看起來有點像，但其實差別不小，而這個差別也會影響到瀏覽器如何看待這兩個網站的關係還有給予的權限。

這篇文章將會談到：

1. Origin 是什麼？怎樣是 same origin？
2. Site 是什麼？怎樣是 same site？
3. same origin 跟 same site 的差別是什麼？
4. 如何把 same site 變成 same origin？

事不宜遲，就讓我們開始吧！

（開始之前先回答一個疑問。是的，標題的靈感來自於忍者哈特利）

2022-01-20：修改「細究 same site」段落，補充 scheme 相關歷史，感謝 @littlegoodjack

閱讀更多

前言

之前在公司內接到了一個需求，需要產生出一份 PDF 格式的報告。想要產一份 PDF 有很多種做法，例如說可以先用 Word 做，做完之後再轉成 PDF。但我聽到這需求時，最先出現的想法就是寫成網頁，然後再利用列印功能轉成 PDF。

我在前公司的時候看過一個用 JS 來產生 PDF 的專案，是用 PDFKit 來做，自由度極高，但我覺得滿難維護的。原因是用這一套的話，就有點像是把 PDF 畫出來，你要指定 (x,y) 座標去畫東西，可能改一個小地方，就要改很多行程式碼。

那時候我想說怎麼不直接用最簡單的 HTML + CSS 就好，切好版之後再轉成 PDF，如果不想手動轉，也可以透過 headless chrome 去轉，因為是網頁的關係所以應該滿好維護的。而且排版的話因為是用 HTML 跟 CSS，應該會比用畫的簡單許多才對。

直到我後來接觸到網頁轉 PDF，才發現事情不像我想的這麼簡單。

閱讀更多

前言

CSS 寫一陣子之後，大家對於常見的屬性應該都很熟了，例如說最基本的 display、position、padding、margin、border、background 等等，在寫 CSS 的時候不需要特別查什麼東西，很順的就可以寫出來。

這些屬性之所以常見，是因為許多地方都用得到所以常見，而有些 CSS 屬性只能使用在某些特定地方，或者是只有某個特定的情境之下才會出現。我很常會忘記這些沒那麼常用到的屬性，但在某些時候這些屬性其實特別重要。

因此這篇想來介紹一些我覺得不太好記但是卻很好用的 CSS 屬性，也是順便幫自己留個筆記。

閱讀更多

前言

只要是開發 JavaScript 相關的專案，我的起手式通常都是 ESLint + Prettier，如果你沒有聽過這兩套的話我稍微講一下，Prettier 是幫你格式化程式碼用的，用了之後不必再跟其他人爭論到底要不要加分號，if 區塊的 { 要不要換行，一行最多到底能幾個字。只要用 Prettier，就是讓它幫你全權決定（雖然也有設定檔可以調整就是了）。

這其實對團隊滿有幫助的，因為程式碼格式可以統一，要空幾格也可以統一，在基本的 coding style 上面會長差不多。而 ESLint 雖然也有些跟格式相關的部分，但更多的是寫程式時候的一些 best practice，例如說使用變數前要先宣告、不會更改的變數用 const 之類的，這已經脫離了格式的範圍。

所以 ESLint 搭配 Prettier，就可以讓整個 codebase 的品質有最低限度的保障，至少不會出現排版很慘烈的狀況。而使用 ESLint 時最多人搭配的規則應該就是 Airbnb JavaScript Style Guide，裡面有每一條規則的詳細解釋。

之前在寫 code 時我突然想到一個地方好像很適合用 ESLint，就嘗試了看看，發現要做一個「堪用」的 plugin 比想像中簡單一些，就以這篇文章記錄一下過程跟心得。

閱讀更多

前言

這篇技術含量比較少一點，來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。

如果你還沒看這系列文的話，傳送門如下：

• CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？
• CORS 完全手冊（二）：如何解決 CORS 問題？
• CORS 完全手冊（三）：CORS 詳解
• CORS 完全手冊（四）：一起看規範
• CORS 完全手冊（五）：跨來源的安全性問題
• CORS 完全手冊（六）：總結、後記與遺珠

閱讀更多