原生JS也要支持類型注解啦？
大家好，我卡頌。
在布達佩斯2022 JSConf[1]會議上，tc39[2]（ES標準委員會）成員「Gil Tayar」介紹了一份當前仍處于stage 1?階段的提案 —— Type Annotations?，意在讓原生JS支持類型注解。
Gil Tayar
換句話說，如果提案通過，很多.ts?文件將后綴改為.js后就能直接在瀏覽器中運行。
一份tc39提案通常會經歷5個階段：
- stage 0：被提出。
- stage 1：接受審議。
- stage 2：規范基本完成。
- stage 3：等待被實現。
- stage 4：納入語言標準中。
所以Type Annotations當前仍處于「接受審議」的狀態。
但是提案發起者「Gil Tayar」對這份提案的通過很有信心，本文我們來聊聊這份提案的相關內容。
為什么需要原生類型注解？
根據20年、21年state of JS[3]的統計，「靜態類型」高票當選「JS中當前最欠缺的功能」。
同時，在Github報告[4]中，TS被列為「第四大最常用的語言」
所以，對前端工程師來說，「類型注解」需求很大。
那么，既然已經有了TS?，為什么還需要原生JS支持「類型注解」呢？
通常來說，從「開發者編寫的源代碼」到「線上生產環境代碼」間需要經過「代碼編譯」。
「代碼編譯」主要包括兩個步驟：
- 降級編譯（包括高級語法轉換為低級語法，高級方法的polyfill）。
- 代碼轉譯（比如壓縮、混淆、tree-shaking、類型擦除）。
所謂「類型擦除」，是指擦除代碼中的「類型注解」，讓其變成符合原生JS規范的代碼，比如：
// 擦除前
function add(a: number, b: number): number {
return a + b;
}
// 擦除后
function add(a, b) {
return a + b;
}
隨著時間的推移，各主流瀏覽器兼容性越來越好，「步驟1」在可預見的未來重要性會逐漸降低。
對于TS開發者，從「源代碼」到「線上生產環境代碼」間可能只需要「類型擦除」。
如果原生JS支持「類型注解」，就能省去「類型擦除」對應的編譯流程，讓代碼更容易在宿主環境執行。
和TS的關系
這份提案的目的，并不是另起爐灶，獨立實現一套原生??JS??的類型注解。而是與「TS團隊」合作，提出一套合適的規范。
新的規范與「TS規范」的關系類似下圖：
一方面，Type Annotations?提案從TS中借鑒了很多特性，這就是圖中相交的部分。
你可以到grammar-conventions[5]看到規范當前定義的類型
另一方面，TS?迭代速度很快，新的特性產出很快。而Type Annotations?作為JS?語言的一部分，迭代會更加保守，所以TS?中一些特性在Type Annotations中并不支持。
此外，TS?中一些結構（比如Enums?、Namespaces?）存在運行時的語義，Type Annotations也不會支持。
這些就是TS?中存在，而Type Annotations中不存在的部分。
最后，Type Annotations?設計的初衷并不是與TS?強綁定，而僅僅是提供一套類型規范，開發者編寫代碼時的「類型檢查」還是由各種類型檢查器（比如TS?、Flow）實現。
所以，Type Annotations?還有一部分特性是TS?當前未定義的，這也是為了規范更廣泛的適用性考慮的，也就是圖中Type Annotations?存在，而TS不存在的部分。
這部分特性需要TS?后續實現，這也是為什么Type Annotations?要與TS團隊合作的一大原因。
對開發者意味著什么
如果Type Annotations最終出現在ES20xx版中，屆時開發者編寫代碼的步驟是：
- 選擇合適的類型檢查器（比如TS），這個類型檢查器需要完全遵循Type Annotations規范（而不是自己的規范，比如TS規范）。
- 編寫帶類型聲明的原生JS代碼。
- 類型檢查器會檢查類型錯誤，并給予報錯或提示。
對于如下原生JS代碼，如果開發者傳入了錯誤的類型，JS會報錯么？
function add(a: number, b: number): number {
return a + b;
}
// 錯誤的類型傳參
add('KaSong', 123);
答案是：不會。
Type Annotations僅僅是一套規范，該規范由各種類型檢查器執行。
JS的宿主環境（比如瀏覽器）在執行「帶類型聲明的JS代碼」時，會忽略類型聲明。
總結
有同學可能會問：就為了減少編譯時「類型擦除」這一步，就提出原生類型規范，有必要么？
甚至當Type Annotations落地后，開發者上線前在進行代碼壓縮時，「類型擦除」也會作為「代碼壓縮」的職責之一。
從這個角度看，甚至沒有減少編譯時的工作量。
所以提出原生的類型規范，有必要么？
前端的發展實際是一個「努力去編譯時流程」的過程。
比如，編譯時代碼需要降級，需要polyfill?？隨著IE11?停止服務，主流瀏覽器紛紛跟進標準落地，降級與polyfill的需求逐漸變少。
再比如，代碼需要打包？隨著ESM?規范落地，在當前，至少在開發環境中代碼已經不需要打包（使用Vite）。
Type Annotations的出現，就是遵循「努力去編譯時流程」這一趨勢的產物。
從這個角度看，還是很有必要的。
參考資料
[1]布達佩斯2022 JSConf:https://www.youtube.com/watch?v=SdV9Xy0E4CM&list=PL37ZVnwpeshGuMZrOZzEo8QLBjjpbtBGm&index=2。
[2]tc39:https://github.com/tc39。
[3]state of JS:https://stateofjs.com/en-us/。
[4]Github報告:https://octoverse.github.com/。
[5]grammar-conventions:https://tc39.es/proposal-type-annotations/grammar.html#grammar-conventions。
