你可以在浏览器中直接运⾏TypeScript吗？
javascript程序设计软件
我正在开发⼀个使⽤ TypeScript 作为选择语⾔的新 React 应⽤程序。我很清楚，对于⼤多数（如果不是全部）应⽤程序，TypeScript 被转换为 JavaScript。但这引出了⼀个问题。你可以直接在浏览器中运⾏ TypeScript ⽽不需要额外的转换成 JavaScript 的步骤吗？能够在开发过程中节省⼀个步骤并只加载 TypeScript ⽂件肯定会很好，尤其是在构建⼤型应⽤程序时。
那么可以直接在浏览器中运⾏ TypeScript 吗？⽬前，Web 浏览器不⽀持在没有将代码转换为 JavaScript 的额外步骤的情况下运⾏TypeScript。⼤多数现代 Web 浏览器都⽀持在各种版本的 ECMAScript 中定义的某些功能，这是 JavaScript 标准定义，可帮助确保浏览器以类似⽅式处理代码。但是由于 TypeScript 是 JavaScript 的超集并且⽀持更多功能，因此浏览器并不直接⽀持 TypeScript。
对于 TypeScript 的新⽼⽤户来说，这个想法绝对令⼈沮丧。特别是因为 TypeScript 和 JavaScript 似乎密切相关。他们是谁。但是这些问题⽐语⾔本⾝要深刻得多。
浏览器中 TypeScript 的未来
如果您查看 JavaScript 标准定义（称为的演变，您可能会推断出，该定义最终会赶上 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,00010$1,600,000
Mozilla$150,00010$1,500,000
苹果$150,00010$1,500,00
微软$140,00010$1,400,000
基于数据的平均⼯资
公司产品经理薪资待遇产品经理⼈数总消耗
⾕歌$180,0002$360,000
Mozilla$130,0002$260,000
苹果$170,0002$340,000
微软$140,0002$280,000
基于数据的平均⼯资
公司质量⼯程师质量保证⼯程师⼈数总消耗
⾕歌$140,0003$420,000
Mozilla$120,0003$360,000
苹果$130,0003$390,000
微软$120,0003$360,000
基于数据的平均⼯资
如果您将每个公司作为⼀个整体来看，我们谈论的是 2 到 300 万美元之间的任何地⽅！
我什⾄没有考虑到设计师、建筑师、项⽬经理等的时间。正如你所看到的，这可能会变得⾮常昂贵！
时间
那么当 TypeScript 被添加到组合中时，这些公司已经构建和⽀持的现有浏览器发⽣了什么？
不多，就是这样。
是的，我知道有 10 多名软件⼯程师在这些公司⼯作。但是，当您尝试添加对 TypeScript 的本机⽀持时，您不能继续向这些浏览器添加更多功能。
为什么不？
我们回到我之前提到的整个移动⽬标类⽐。
如果您开始添加对 TypeScript 的⽀持，并继续向浏览器添加这些⼯程师必须使⽤ TypeScript ⽀持的新功能，那么他们的两端将永远不会相遇。
更不⽤说对于这些公司来说，对于他们产品的⽤户来说，什么更重要？最终⽤户还是开发商？我相信你可能知道这个问题的答案。
解决⽅法
因此，如果当前浏览器中没有对 TypeScript 的原⽣⽀持，并且这些公司在不久的将来不会随时添加对它的⽀持，那么⾄少有解决⽅法吗？
嗯……有点。
归根结底，浏览器需要您的代码使⽤ JavaScript，以便它可以“正确”运⾏。但这并不⼀定意味着您必须向它提供 JavaScript。
这意味着什么？
实际上，您可以通过多种⽅式的繁重⼯作。
Web 应⽤程序的典型流程如下所⽰：
Web 应⽤程序是⽤ TypeScript 编写的。构建过程发⽣在开发机器上，或者更常见的是在某个地⽅的构建服务器上，⽣成的应⽤程序被转换为 JavaScript，托管在某个地⽅的 CDN 中。
然后，当⽤户在浏览器中打开应⽤程序时，浏览器从 CDN 下载应⽤程序代码，加载到浏览器中，每个⼈都很⾼兴。
此流程可以更改为如下所⽰：
其中 TypeScript 代码没有提前转译，直接加载到 CDN 中。从那⾥，当⽤户在浏览器中打开应⽤程序时，浏览器从 CDN 下载应⽤程序代码，将其转换为 JavaScript，加载⽣成的 JavaScript，每个⼈都很⾼兴。
这似乎不是⼀个很⼤的飞跃，但 Web 浏览器从来没有被设计为处理这种类型的处理，在这种处理中，它需要转换潜在的数⼗万⾏代码，然后运⾏它。
我相信你可以想象这样的事情需要多长时间。
⽤户会不⾼兴。
作为 TypeScript 开发⼈员该做什么
那么，作为 TypeScript 开发⼈员，我们究竟该怎么做才能解决我们陷⼊的这个烂摊⼦？
等待…
耐⼼地…。
并坚持到底。
多年来，⼀些⾮常好的⼯具和构建过程就是为这样的时代创建的。可能会有⼀段时间我们不必执⾏将代码转换为 JavaScript 的额外步骤，但不幸的是，这个时间看起来并没有那么近。
所以在那之前，我会在这⾥做同样的事情。
我希望能继续在这⾥见到你。