微軟、伊加利亞和彭博 他們幾天前宣布 已經主動加入了語法 對於規範中的顯式類型定義 JavaScript，類似於 TypeScript 語言中使用的語法。
目前，提議包含在 ECMAScript 標準中的原型更改已提交進行初步討論（第 0 階段）。
今天，我們很高興地宣布我們對新的 Stage 0 提案的支持和合作，為 JavaScript 帶來可选和可擦除的類型語法。 因為這種新語法不會改變周圍代碼的執行方式，所以它們實際上就像註釋一樣。 我們認為這有可能使 TypeScript 更容易、更快地用於各種規模的開發。 我們想談談我們為什麼要追求這個，以及這個提案在高層次上是如何運作的。
提到在 t擁有明確的類型信息將防止開發過程中出現許多錯誤， 它將提供使用額外優化技術的機會，簡化調試，並使代碼更具可讀性，更易於第三方開發人員修改和維護。
除此之外 建議將類型支持實現為可選功能： 不支持類型檢查的 JavaScript 引擎和運行時將忽略帶有類型信息的註釋並像以前一樣處理代碼，將類型數據視為註釋。 但是類型檢查工具將能夠根據可用信息檢測與錯誤使用類型相關的錯誤。
背景
我們的團隊在 JavaScript 世界中看到的最近趨勢是對更快迭代時間和減少構建步驟的需求。 換句話說，“讓它更快更簡單”。在某種程度上，這已經在發生了。 由於常青瀏覽器的成功，開發人員通常可以避免編譯較新版本的 JavaScript 以在較舊的運行時上運行。 在某種程度上，捆綁也是如此：大多數瀏覽器都內置了對使用模塊的支持，因此捆綁更多地被視為一種優化步驟，而不是必需品。 這種情況越來越多，那麼 TypeScript 是如何堅持的呢？
同時 不同於指定的類型信息 通過指定為註釋的 JSDoc 註釋， 直接規範 直接在變量定義結構中的類型 它將使代碼更直觀、更易於理解且更易於編輯.
例如，支持 TypeScript 的 IDE 將能夠立即突出顯示編寫的 JavaScript 代碼中的錯誤，而無需額外的轉換。 此外，內置的類型支持將使運行以腳本化 JavaScript 方言（如 TypeScript 和 Flow）編寫的程序成為可能，而無需從一種語言轉換為另一種語言。
在這些類型中，建議添加“string”、“number”和“boolean”，可以在定義變量、函數參數、對像元素、類字段、類型化數組（“number[]”）時使用。 還建議為混合類型（“字符串|數字”）和泛型提供支持。
鑑於所有這些，我們計劃在 1 年 2022 月的 TC39 全體會議上提交第 XNUMX 階段的提案。 我們將在該提案的共同擁護者、彭博的 Rob Palmer 和 Igalia 的 Romulo Cintra 的支持和指導下這樣做。
達到第 1 階段意味著標準委員會認為 ECMAScript 的兼容類型語法值得考慮。 這不是一個確定的事情：委員會中有許多有價值的觀點，我們預計會有一定程度的懷疑。 像這樣的提案會得到很多評論和適當的審查。 在此過程中可能涉及大量設計更改，並且可能需要數年才能獲得結果。
在下次會議上 三月的 TC39委員會，計劃進入第一階段 在 ECMA 專家社區的參與下審議該提案。
終於 如果您有興趣了解更多信息， 您可以在中查看詳細信息 以下鏈接。