機器翻譯 https://scriptingplanet.com/can-you-run-typescript-directly-in-the-browser/
我正在開發一個使用 TypeScript 作為選擇語言的新 React 應用程序。我很清楚，對於大多數（如果不是全部）應用程序，TypeScript 被轉換為 JavaScript。但這引出了一個問題。你可以直接在瀏覽器中運行 TypeScript 而不需要額外的轉換成 JavaScript 的步驟嗎？能夠在開發過程中節省一個步驟並只加載 TypeScript 文件肯定會很好，尤其是在構建大型應用程序時。
那么可以直接在瀏覽器中運行 TypeScript 嗎？ 目前，Web 瀏覽器不支持在沒有將代碼轉換為 JavaScript 的額外步驟的情況下運行 TypeScript。 大多數現代 Web 瀏覽器都支持在各種版本的 ECMAScript 中定義的某些功能，這是 JavaScript 標准定義，可幫助確保瀏覽器以類似方式處理代碼。但是由於 TypeScript 是 JavaScript 的超集並且支持更多功能，因此瀏覽器並不直接支持 TypeScript。
對於 TypeScript 的新老用戶來說，這個想法絕對令人沮喪。特別是因為 TypeScript 和 JavaScript 似乎密切相關。他們是誰。但是這些問題比語言本身要深刻得多。
瀏覽器中 TypeScript 的未來
如果您查看 JavaScript 標准定義（稱為ECMAScript ）的演變，您可能會推斷出，該定義最終會趕上 TypeScript 的功能。那時，能夠在瀏覽器中運行 TypeScript 是有意義的。
雖然這是我們的一個非常美好的夢想，但實際上，這種情況發生的可能性很小。有幾個主要原因你不應該為瀏覽器中的 TypeScript 支持而屏住呼吸。
這是一個移動的目標
這種思路的問題在於，雖然正在定義的標准在向前發展，但 TypeScript 也在向前發展。TypeScript 本身作為一種語言在不斷發展，也在不斷發展和變化。如果它保持足夠長的時間，ECMAScript 標准肯定會趕上它的特性列表。
但就像技術中的任何其他事物一樣，如果它放緩至停滯狀態，它最終會消亡並被新的和不斷增長的事物所取代。
瀏覽器功能采用
JavaScript 和瀏覽器支持的特性甚至有一個標准定義，這一事實絕對值得稱贊。
但這正是問題所在。 功能支持。
ECMAScript 的版本通常由它們出現的年份定義。ECMAScript 2015、2016 等很常見。它們也有縮寫，如 ES5、ES6 等。因此，您可能會認為，由於我們進入 2020 年代，瀏覽器將支持之前十年定義的所有功能。
但你會錯的。
瀏覽器開發人員並不打算支持今年或前一年發布的任何版本的標准。就像任何其他公司一樣，他們通常有一項業務要開展，一項產品要發貨。
因此，他們通常會通過標准並實施對他們最有意義的支持以及他們的客戶想要的功能。
那是什么意思呢？
這意味着即使特定版本的現代瀏覽器可能支持 2016 年發布的標准定義的所有功能，但它可能只支持 2015 年發布的一兩個。
瀏覽器添加對 TypeScript 的支持
既然瀏覽器開發人員花費了大量時間來添加功能，他們為什么不直接添加 TypeScript 支持呢？
傷口很深，恐怕。
多年來，對瀏覽器的需求呈指數級增長。想想你花在互聯網上的時間。如果您的瀏覽器開始變慢或頁面開始加載非常緩慢，您要做的第一件事是什么？
你責怪你正在看的網站嗎？
你坐下來耐心等待頁面加載嗎？
可能不是。
您可能關閉瀏覽器並重試。如果這種情況發生太多次，您甚至可以考慮購買新的瀏覽器。
這是一場戰爭！
瀏覽器開發人員沒有時間和資源來停止他們正在做的事情並添加對 TypeScript 的支持，主要有以下幾個原因：
成本
錢使世界運轉。
這只是生活中的一個事實。
但是當談到功能成本和對瀏覽器的增加支持時，這究竟意味着什么？如果您考慮為瀏覽器添加對 TypeScript 的支持所需的時間，讓我們做一些粗略的數學計算。
想象一下，為流行的現代瀏覽器（Chrome、Firefox、Safari、IE/Edge）完全添加對 TypeScript 的支持需要一年時間。
根據這些公司的中級軟件工程師、產品經理和 QA 工程師的估計工資，這大致是每家公司添加該支持所需的成本。
| 公司 | 中級工程師薪資待遇 | 工程師人數 | 總消耗 |
| 谷歌 | $160,000 | 10 | $1,600,000 |
| Mozilla | $150,000 | 10 | $1,500,000 |
| 蘋果 | $150,000 | 10 | $1,500,00 |
| 微軟 | $140,000 | 10 | $1,400,000 |
基於levels.fyi數據的平均工資
| 公司 | 產品經理薪資待遇 | 產品經理人數 | 總消耗 |
| 谷歌 | $180,000 | 2 | $360,000 |
| Mozilla | $130,000 | 2 | $260,000 |
| 蘋果 | $170,000 | 2 | $340,000 |
| 微軟 | $140,000 | 2 | $280,000 |
基於levels.fyi數據的平均工資
| 公司 | 質量工程師 | 質量保證工程師人數 | 總消耗 |
| 谷歌 | $140,000 | 3 | $420,000 |
| Mozilla | $120,000 | 3 | $360,000 |
| 蘋果 | $130,000 | 3 | $390,000 |
| 微軟 | $120,000 | 3 | $360,000 |
基於levels.fyi數據的平均工資
如果您將每個公司作為一個整體來看，我們談論的是 2 到 300 萬美元之間的任何地方！
我什至沒有考慮到設計師、建築師、項目經理等的時間。正如你所看到的，這可能會變得非常昂貴！
時間
那么當 TypeScript 被添加到組合中時，這些公司已經構建和支持的現有瀏覽器發生了什么？
不多，就是這樣。
是的，我知道有 10 多名軟件工程師在這些公司工作。但是，當您嘗試添加對 TypeScript 的本機支持時，您不能繼續向這些瀏覽器添加更多功能。
為什么不？
我們回到我之前提到的整個移動目標類比。
如果您開始添加對 TypeScript 的支持，並繼續向瀏覽器添加這些工程師必須使用 TypeScript 支持的新功能，那么他們的兩端將永遠不會相遇。
更不用說對於這些公司來說，對於他們產品的用戶來說，什么更重要？最終用戶還是開發商？我相信你可能知道這個問題的答案。
解決方法
因此，如果當前瀏覽器中沒有對 TypeScript 的原生支持，並且這些公司在不久的將來不會隨時添加對它的支持，那么至少有解決方法嗎？
嗯……有點。
歸根結底，瀏覽器需要您的代碼使用 JavaScript，以便它可以“正確”運行。但這並不一定意味着您必須向它提供 JavaScript。
這意味着什么？
實際上，您可以通過多種方式在瀏覽器中處理將 TypeScript 轉換為 JavaScript的繁重工作。
Web 應用程序的典型流程如下所示：
Web 應用程序是用 TypeScript 編寫的。構建過程發生在開發機器上，或者更常見的是在某個地方的構建服務器上，生成的應用程序被轉換為 JavaScript，托管在某個地方的 CDN 中。
然后，當用戶在瀏覽器中打開應用程序時，瀏覽器從 CDN 下載應用程序代碼，加載到瀏覽器中，每個人都很高興。
此流程可以更改為如下所示：
其中 TypeScript 代碼沒有提前轉譯，直接加載到 CDN 中。從那里，當用戶在瀏覽器中打開應用程序時，瀏覽器從 CDN 下載應用程序代碼，將其轉換為 JavaScript，加載生成的 JavaScript，每個人都很高興。
這似乎不是一個很大的飛躍，但 Web 瀏覽器從來沒有被設計為處理這種類型的處理，在這種處理中，它需要轉換潛在的數十萬行代碼，然后運行它。
我相信你可以想象這樣的事情需要多長時間。
用戶會不高興。
作為 TypeScript 開發人員該做什么
那么，作為 TypeScript 開發人員，我們究竟該怎么做才能解決我們陷入的這個爛攤子？
等待…
耐心地…。
並堅持到底。
多年來，一些非常好的工具和構建過程就是為這樣的時代創建的。可能會有一段時間我們不必執行將代碼轉換為 JavaScript 的額外步驟，但不幸的是，這個時間看起來並沒有那么近。
所以在那之前，我會在這里做同樣的事情。
我希望能繼續在這里見到你。