在 JavaScript 的幾個資料型別中，Number 是非常常用的一個，而且有些小地方需要特別注意，不然很容易寫出有 bug 的程式碼。

這篇會帶大家看一些案例，有些是假想的情境，也有些是我自己碰過的問題，在每個案例繼續往下講解之前，大家也可以試著把自己帶入情境，想想看自己知不知道問題的成因，又該如何避免。

閱讀更多

JavaScript 裡面一共有幾個資料型別？又分別是哪些？

要談型別之前，我們應該要先知道 JavaScript 中一共有幾種型別，並且對每一種型別都有最基本的理解。在文章開始之前，你也可以自己先數數看，再來跟我對答案，看是不是正確的。

由於 JavaScript 是會進化的，這篇的型別會以本文寫作時最新的 ECMAScript 2021 為準，底下如果有提到「spec」，指的都是 ECMAScript 2021 language specification。

閱讀更多

我認為在理解 JavaScript 這個程式語言的時候，還需要認識到「執行環境（runtime）」這件事情，你心中的架構圖才會完整。有許多人並沒有意識到這一環，導致對於 JavaScript 或是一些技術的理解有認知上的差異；因此這一篇，就讓我們好好來談談執行環境。

附註：除了 runtime 叫做執行環境以外，execution environment 也叫做執行環境，但這兩個是完全不同的東西。為了避免歧義，底下會盡量用原文 runtime 這個詞。

另外，runtime 有許多意思，這邊的 runtime 比較像是 runtime environment 的意思。

閱讀更多

談完了 JavaScript 的歷史以及包袱以後，我們來談談 JavaScript 本身。

不知道大家有沒有想過一個問題，當你看到一本 JavaScript 書籍或是教學文章的時候，你要怎麼知道作者沒有寫錯？要怎麼知道書裡講的知識是正確的？就如同標題所說，會不會你以前知道的 JavaScript 知識其實是錯的？

因為作者常寫技術文章，所以就相信他嗎？還是說看到 MDN 上面也是這樣寫，因此就信了？又或是大家都這樣講，所以鐵定沒錯？

有些問題是沒有標準答案的，例如說電車難題，不同的流派都會有各自認可的答案，並沒有說哪個就一定是對的。

但幸好程式語言的世界比較單純，當我們提到 JavaScript 的知識時，有兩個地方可以讓你驗證這個知識是否正確，第一個叫做 ECMAScript 規格，第二個大家可以先想想，我們待會再提。

閱讀更多

我認為想要真正認識 JavaScript 的話，要從歷史開始。為什麼？因為從它的歷史，可以知道為什麼某些部分是這樣子設計，為什麼會有這些看似奇怪的行為。雖然有些古早的知識可能沒什麼實際用途，但對我來說是很有趣的。

學習它的歷史，並不是死背它出現的年代或是當初花了幾天開發設計，而是要去理解它出現的脈絡，去理解為什麼需要它，又為什麼它是這樣子被設計的。

想了解 JavaScript 的歷史，我最推薦的是這個資源：JavaScript: The First 20 Years，因為 JavaScript 之父 Brendan Eich 也是作者之一，想看中譯版的話在這邊：JavaScript 二十年。

這本書紀錄了從 1995 年到 2015 年，一共二十年的 JavaScript 歷史，如果有時間的話我強烈建議你把它全部看完，會對 JavaScript 有不同的體會（還會知道很多冷知識）。

底下我會挑一些我覺得比較重要的東西來寫，資料來源沒有特別講的話，都是來自於上面提到的那本書，所以若是覺得似曾相似是正常的。

由於我跟 JavaScript 差不多時候出生，因此這些早期的歷史我並沒有親身體會過，若是寫得好像我有親身參與的話，全都是想像而已。

閱讀更多

前言

部落格需要顯示發佈時間，餐廳網站要顯示訂位時間，拍賣網站則是要顯示訂單的各種時間，無論你做什麼，都會碰到「顯示時間」這個很常見的需求。

這問題看似簡單，不就是顯示個時間嗎？但如果牽扯上「時區」的話，問題就會變得再更複雜一些。以時區來說，通常會有這幾個需求：

1. 網站上的時間需要在某個固定時區顯示，我在美國跟在台灣要在網站上看到同樣的時間
2. 網站上的時間會根據使用者的瀏覽器設置不同，我在美國跟在台灣看到的時間會不一樣
3. PM 根本沒想過這問題，只考慮到當地的使用者，所以暫時不用擔心這個

而這還只是顯示的部分而已，還有另外一個部分是與後端的溝通，這個我們可以待會再提，但總之呢，要正確處理時間跟時區並不是一件簡單的事。

在最近這一兩份工作剛好都有碰過相關的問題，因此對這一塊有點小小心得，就寫了這一篇來跟大家分享一下。

閱讀更多

前言

最近公司的同事修了一門資安相關的課，因為我本來就對資安滿有興趣的，所以就會跟同事討論一下，這也導致了我這兩週一直在研究相關的東西，都是一些以前聽過但沒有認真研究過的，例如說 LFI（Local File Inclusion）、REC（Remote code execution）、SSRF（Server-Side Request Forgery）或是各種 PHP 的神奇 filter，也能複習原本就已經相對熟悉的 SQL Injection 跟 XSS。

而 CTF 的題目裡面常常會出現需要繞過各種限制的狀況，而這就是考驗對於特定協定或者是程式語言的理解程度的時機了，要想想看怎麼在既有的限制之下，找出至少一種方法可以成功繞過那些限制。

原本這一週不知道要寫什麼，想寫上面提的那些東西但還沒想好怎麼整理，之前的 I Don’t know React 後續系列又還沒整理完，就想說那來跟大家做個跟「繞過限制」有關的趣味小挑戰好了，那就是標題所說的：

在 JavaScript 當中，你可以做到不用英文字母與數字，就成功執行 console.log(1) 嗎？

換句話說，就是程式碼裡面不能出現任何英文字母（a-zA-Z）與數字（0-9），除此之外（各種符號）都可以。執行程式碼之後，會執行 console.log(1)，然後在 console 印出 1。

如果你有想到以前聽過什麼有趣的服務或是 library 可以做到，先不要。在這之前可以自己先想一下，看有沒有辦法寫出來，然後再去查其他人的解決方法。

若是能從零到有全都自己寫出來，就代表你對 JS 這個程式語言以及各種自動轉型的熟悉程度應該是滿高的。

底下我就提供一下我自己針對這一題的一些想法以及解題過程，有雷，還沒解完不要往下捲動。

==防雷==
==防雷==
==防雷==
==防雷==
==防雷==

閱讀更多

前言

如果有先寫過其他 function 不是 first-class 的程式語言，在寫 JavaScript 的時候應該會經歷一些陣痛期，想說到底在做什麼——至少我是這樣的。

我當初發現可以把 function 當作參數到處傳遞的時候，對於比較複雜的 code 就要想很久，而 function 的其他行為也是讓我一頭霧水，例如說 function 居然也是 object，還有 this 到底是什麼鬼東西。

這一篇主要是想分享一些我覺得 function 比較有趣的地方。可是呢，直接開始講一大堆知識太無趣了，我希望能引起大家對這些知識的好奇程度，而想要引起好奇，最好的方法就是提供一個「你也會感興趣的問題」，你就會有動力繼續往下看了。

因此底下就以幾個小問題作為開場，雖然是問題的形式，但答不出來也完全沒有關係，如果你對這些問題的答案有興趣的話再往下看，沒興趣的話出口直走到底左轉。

話說這篇標題本來想取叫：「JavaScript function 知多少」或是「有趣的 JavaScript function」，但這種標題太無趣了，所以才想到這種輕小說式（？）的標題。

閱讀更多

前言

在我以前寫過的兩篇文章：我知道你懂 hoisting，可是你了解到多深？以及所有的函式都是閉包：談 JS 中的作用域與 Closure 裡面，都談到了 let 與 var 作用域的不同。

let 的作用域是 block，而 var 則是 fucntion，像這個就是經典案例：

for(var i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

原本預期會依序輸出 1~10，沒想到卻輸出了 10 個 11。背後原因就是因為第三行那個 i 永遠都只有一個，就是 for 迴圈宣告的那個 var i，從頭到尾都是同一個變數。

而經典解法也很簡單，把 var 改成 let 就搞定了：

for(let i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

搞定的原因是，可以把上面程式碼看作是下面這種形式：

{
 let i=1
 setTimeout(function() {
    console.log(i)
  })
}

{
 let i=2
 setTimeout(function() {
    console.log(i)
  })
}

...

{
 let i=10
 setTimeout(function() {
    console.log(i)
  })
}

由於 let 的作用域是 block，所以在每一圈迴圈裡面，其實都是一個新的 i，因此迴圈跑 10 圈就有了 10 個不同的 i，最後當然是輸出 10 個不同的數字。

因此 var 跟 let 在這個範例最大的區別就在於變數的數量，前者只有 1 個，後者卻有了 10 個。

好，既然知道了 let 與 var 的差別以後，就可以來看看這篇最主要想討論的問題。

其實這問題是來自於 YDKJS（You Dont Know JS，中譯本翻做：你不知道的JavaScript） 的作者 @getify 在他的推特上所提出的：

question for JS engines devs…
is there an optimization in place for this kind of code?

for (let i = 0; i < 10; i++) {
  // no closure
}

IOW, where the behavior of creating a new i per iteration is not needed nor observable… does JS skip doing it?

若是沒有看得很懂，可以繼續看延伸的另外一則推：

here’s a variation on the question… will JS engines exhibit much performance difference between these two loops?

for (var i = 0; i < 100000000; i++) {
   // do some stuff, but not closure
}

for (let i = 0; i < 100000000; i++) {
   // do the same stuff (no closure)
}

簡單來說呢，平常用 let 搭配迴圈的時候，不是如我們上面所說的，每一圈都會有一個新的i嗎？既然是這樣的話，那 var 與 let 應該就會有效能上的差異，因為 let 必須每一圈都 new 一個新的變數出來，所以 let 會比較慢。

那如果迴圈裡面並不需要每一圈都有新的 i，JS 引擎會做優化嗎？這個問題就是這樣，主要是想探討 JS 引擎會不會針對這種行為去做優化。

那要怎麼知道呢？要嘛你是 JS 引擎的開發者，要嘛你去看 JS 引擎的原始碼，但這兩種難度都有點太高。不過別擔心，還有第三種：看 JS bytecode。

閱讀更多

前言

如果要舉出一個在 JavaScript 裡面很重要也很常用，但新手常常搞混的概念，那「非同步（Asynchronous）」當仁不讓，絕對是第一名。跟其他那些 this、closure、prototype 或是 hoisting 比起來，非同步在實際開發的時候用到的頻率高太多了，而且是初學者常常會踩坑的地方。

非同步真的那麼難嗎？

我相信不是的。只要循著一個正確的脈絡前進，就可以循序漸進理解為什麼需要非同步，也能知道在 JavaScript 裡面是怎麼處理這種操作的。

類似的主題我其實在四年前就寫過，但現在回頭看實在是寫得滿差的，所以四年後重新挑戰這個主題，希望能寫出一篇品質不錯的文章，把非同步這件事情講清楚。

在寫這篇文章之前，參考了 Node.js 的官方文件，發現在非同步的講解上其實做得不錯，因此本文會以類似的切入點開始談這個問題。如果不會 Node.js 也沒關係，我底下會稍微做點介紹。

建議閱讀本文以前需要具備 JavaScript 基礎，知道如何使用 JavaScript 操作 DOM，也知道什麼是 ajax。

接著就讓我們開始吧！

閱讀更多