身為每天都要與網頁打交道的前端工程師，熟悉 DevTools 的使用是相當合理的。每當接 API 出問題時，就按下快捷鍵打開 DevTools，切到 Network 分頁，找到紅色的那一行，右鍵複製成 cURL 貼到群組裡面，讓後端自己找找問題。

但不曉得大家有沒有碰過 DevTools 不夠用的狀況，這時該怎麼辦？

閱讀更多

以前當我想要部署一個簡單的服務時，我會去 Heroku 上面，因為簡單而且免費，雖然說還是有些使用限制，但整體而言還是很方便的，甚至還有一些簡單的 DB 可以用。如果是靜態網頁，會選擇 Netlify 或是 GitHub Pages，也都是簡單方便的選擇。

但 Heroku 從 2022 年年底之後就不再提供免費方案了，因此那時一堆人在尋找替代方案，包括 Render 或是 fly[dot]io 等等，都是很多人跳槽的新選擇。而我自己以前其實在 Heroku 上也有三四個專案，從 Heroku 改變方案之後就再也沒也動過了。

前陣子收到 Zeabur 創辦人的來信，希望有機會能跟我合作推廣這個平台，我自己試了之後發現體驗確實很不錯，因此就寫了這篇文章介紹一下。

閱讀更多

前言

說身為一個前端工程師，理所當然會知道很多與前端相關的知識，像是 HTML 或是 JS 相關的東西，但那些知識通常都與「使用」有關。例如說我知道寫 HTML 的時候要 semantic，要使用正確的標籤；我知道 JS 應該要怎麼用。可是呢，有些知識雖然也跟網頁有關，卻不是前端工程師平常會接觸到的。

我所謂的「有些知識」，指的其實是「資訊安全相關的知識」。有些在資訊安全裡面常見的觀念，雖然跟網頁有關，卻是我們不太熟悉的東西，而我認為理解這些其實是很重要的。因為你必須懂得怎麼攻擊才能防禦，要先知道攻擊手法跟原理，才知道該怎麼防範這些攻擊。

閱讀更多

前言

如果你想把東西存在網頁前端，也就是存在瀏覽器裡面，基本上就是以下這幾個選項：

1. Cookie
2. LocalStorage
3. SessionStorage
4. IndexedDB
5. Web SQL

後兩者應該滿少用到的，而最後一個 Web SQL 也早在幾年前就被宣告已經不再維護了。因此在談到儲存資料的時候，大部分的人提的還是前三種，其中又以前兩種最多人使用。

畢竟在前端儲存資料時，大部分資料都希望能儲存一段時間，而 cookie 跟 localStorage 就是被設計在這種情形下用的，可是 sessionStorage 不是，它只適合儲存非常短期的資料。

不知道大家對 sessionStorage 的理解是不是跟我一樣，先說說我的理解好了：

sessionStorage 跟 localStorage 最大的差別在於前者只會存在於一個分頁當中，你分頁關掉之後資料就清除了，所以新開分頁，就會有新的 sessionStorage，在不同分頁不會共用。但後者如果是相同的網站，可以共用同一個 localStorage

但我想問大家的是：有沒有可能有一種情況，我在分頁 A 的 sessionStorage 存了一些東西，然後有一個新的分頁 B，也可以讀到分頁 A 的 sessionStorage？

你可能以為沒有，我以前也以為沒有，我同事也這樣認為。

但偏偏就是有。

閱讀更多

前言

會寫這篇是因為我相信一定很多人都碰到過這個問題，簡單一句話總結就是：「用console.log 印出物件時，印出的值跟想像中不一樣」，我們來看看底下的程式碼：

閱讀更多

前言

最近 YDKJS（You Don’t Know JS 的縮寫，中譯版翻成：你所不知道的JS）有了第二版，名叫 YDKJSY，Y 是 Yet 的意思（中文版可能可以翻叫：你還是不知道的 JS）。這個第二版還沒全部完成，但在 GitHub 上面已經公開了最前面的一些章節。

搶先讀了一下第一章，在講與 JS 相關的歷史，其中提到一段讓我很感興趣的議題：

As such, sometimes the JS engines will refuse to conform to a specification-dictated change because it would break that web content.

In these cases, often TC39 will backtrack and simply choose to conform the specification to the reality of the web. For example, TC39 planned to add a contains(..) method for Arrays, but it was found that this name conflicted with old JS frameworks still in use on some sites, so they changed the name to a non-conflicting includes(..). The same happened with a comedic/tragic JS community crisis dubbed “smooshgate”, where the planned flatten(..) method was eventually renamed flat(..).

大意是在說有時候 JS 的規格必須跟現實（已經存在的那些舊的實作）妥協。例如說原本 Array 要加上一個叫做 contains 的 method，但因為會有問題所以改叫 includes，flatten 也改名叫做 flat。

還有一個上面特別標起來的詞「smooshgate」，用這個當關鍵字去找才發現是去年三月左右發生的事件，至於發生了什麼，底下會詳述，跟上面提的 flatten 有關。看到有這件事的時候我第一個反應是：「咦，我怎麼什麼都不知道？」，查了一下繁體中文的資料，大概也只有這篇有提到：SmooshGate，以及[筆記] 3 種 JavaScript 物件屬性的特性這篇有擦到邊而已。

在仔細研究了一下事情的來龍去脈之後，覺得是個滿有趣的議題，因此寫了這篇跟大家分享。

閱讀更多

前言

這是一系列共三篇的文章，我稱之為 Session 與 Cookie 三部曲。系列文的目標是想要由淺入深來談談這個經典議題，從理解概念一直到理解實作方式。這是系列文的最後一篇，三篇的完整連結如下：

1. 白話 Session 與 Cookie：從經營雜貨店開始
2. 淺談 Session 與 Cookie：一起來讀 RFC
3. 深入 Session 與 Cookie：Express、PHP 與 Rails 的實作

第一篇以白話的方式來談 Session 與 Cookie，全篇沒有談到太多技術名詞；第二篇直接去看 Cookie 的三份 RFC 來理解到底什麼是 Session，也補齊了一些 Cookie 相關的知識。而這一篇則是要深入 Session，一起帶大家看看三種不同的 Session 實作方式。

這三樣分別是 Node.js 的 Web 框架 Express、PHP 以及 Ruby on Rails。會挑選這三個是因為他們對於 Session 機制的實作都不同，是我覺得很適合拿來參考的對象。

閱讀更多

前言

這是一系列共三篇的文章，我稱之為 Session 與 Cookie 三部曲。系列文的目標是想要由淺入深來談談這個經典議題，從理解概念一直到理解實作方式。這是系列文的第二篇，三篇的完整連結如下：

1. 白話 Session 與 Cookie：從經營雜貨店開始
2. 淺談 Session 與 Cookie：一起來讀 RFC
3. 深入 Session 與 Cookie：Express、PHP 與 Rails 的實作

閱讀更多

前言

有許多的 HTTP Status Code 大家都耳熟能詳，例如說 404 Not Found、500 Internal Server Error 以及 200 OK 等等。

在眾多的狀態碼之中，有一個擺明就是來搞笑的：418 I’m a teapot。

但你知道嗎，它不在 HTTP 標準裡面，所以根本不是標準的 HTTP 狀態碼。你可能會想說：「我都看過 RFC 了，怎麼會不是？」。但那份 RFC 也跟 HTTP 一點關係都沒有，不過滿多人都沒注意到這點。

我一開始也沒注意到這件事，以為 418 是 HTTP 標準的其中一部分，一直到 2017 年 8 月時有人在 Node.js 的 GitHub 發了一個 Issue：418 I’m A Teapot 我才注意到。

Issue 裡面提到希望能移除對 418 的 support，而發起 Issue 的作者在被人告知 Go 也這樣搞的時候，也跑去 Go 發了一個 Issue。

那時候這起要求移除 418 狀態碼的事件其實引發了不小的風波，而大部分人其實是反對移除這個狀態碼的。甚至還有人做了一個 save418.com，想要拯救 418。

前陣子花了點時間研究一下整件事情的來龍去脈，在整理的過程中也發現無論贊成或是反對，這其中的理由都很值得我們去思考，因此在此總結成一篇文章跟大家分享。

閱讀更多