为什么开发Web应用越来越多人选择TypeScript？

JS

杰克伦敦尘仍在评论区回复我，可我已无法回应他。明明他拉黑了我还来回复，这是为何？索性我把想说的话补充在此：我没有拉黑你，有话就到这里说吧。（引用的均为他创作的内容）确实是我的问题。2011年我开始学习JS时，VBScript早已不再流行，尽管当时不少网站仍在使用ActiveX，但VBScript已不被推荐。我的表述存在错误，在此承认并修正这一观点。回复：成本确实存在，但不算高。大多数职业前端并不会觉得成本高，或许对非前端人士来说有些难度。如果觉得成本非常高，那可能是个人问题导致的。没人逼你用 typescript，成本高就继续写 JavaScript 啊。确实有人不适合用 TS，TS 也不是用来取代 JS 的。这句话很有趣，要结合我下面这张图一起看，十分幽默。这个回答是针对@杰克伦敦尘的观点撰写的，他将VBScript与typescript类比，认为TS由商业公司推出，而非国际标准，因此不应采用。

这句话单独看没错，但需前提条件，并不适合用在 typescript 里。在具体讨论之前，我想先吐槽这位前辈，并非因为他拉黑了我，而是另有原因。起初我真不想评价他，毕竟他提到自己在 JavaScript 和 VBScript 之间做过选择。而我学前端时，VBScript 已经过时了，这表明他的从业经验比我早很多，年纪估计也有四十多岁了，资历摆在那里，不好轻易置评。起初我以为他是那种曾经有一定水准，但多年脱离一线的人，仅凭过时经验评判问题，就像有人评价真阿当2016年前端技术观察时所提到的类型。我点开他的主页，好奇这位高手是谁，却发现了这样的一件事：

啊？就这点本事？不会吧，大哥（还是该叫大叔？）您没出全力吧？这可能是连前端的入门都没达到吧？凡是写JS超过两周的人，都不会再去研究这种demo了。这样就出来高谈阔论，指导别人做技术选型了吗？这不就像过年回村，村里长辈给你传授人生经验那样吗？在技术选型时，标准技术和私有技术应优先考虑前者，但前提是两者差距较小，或标准技术虽暂时落后，预计未来几年可赶超。例如，CoffeeScript 最终被 ES6 和 typescript 取代，就是典型例子。因此，选择时需综合评估现状与发展趋势。typescript 与 JavaScript 不同，它具备显著的优势——类型系统。这一优势在未来的若干年内不会消失，除非 JavaScript 也引入类型支持。类型为 typescript 带来了更强的开发保障和效率提升。typescript 的优势具体有哪些，并非此处讨论的重点。这类内容网上已有很多回答和文章，如果通过简单搜索相关资料仍无法理解，那么即便继续阐述再多，也可能难以真正领会。需要亲自实践，在真实项目中尝试。使用后，你或许能感受到 TS 的优势，也可能觉得类型检查限制过多，更偏爱自由的方式。这些都是正常的感受，无需担心。typescript 当然也有一些不足之处，例如学习成本相对较高，其类型系统较为复杂，特别是要写出完全不使用 any 和 as 的代码更具挑战性。此外，与工具链的集成以及 TSConfig 配置文件的理解难度较大。不过，如果不想自己深入研究，也可以直接借助第三方脚手架工具或生成器来简化开发流程。所谓「typescript 非标准」，其实是它诸多缺点里最不值一提的一个。不说大家都知道的「typescript 是 ECMAScript 的超集」，说了他们也不明白，理解不了。我想谈一谈选择。面临两难抉择时，往往是因为一旦选定其一，再想更改将付出较大代价。譬如选择专业时。例如，后端项目选用 Java 或 Go，前端项目采用 React 或 Vue 等。无论是把后端从 Java 改为 Go，还是将前端组件从 React 替换为 Vue，都会产生较为显著的成本。技术选型需权衡利弊，避免频繁改动带来的资源消耗与风险。这便是所谓的沉没成本。在大多数技术选型里，选择 typescript 的沉没成本极低。对多数项目而言，将 typescript 替换为 JS 仅需完成两项操作：其余工作可能涉及调整 ESLint 配置等内容。不过我从未见过有人这么做，也不清楚原因。生成的代码高度可读且符合标准 JS 规范，但使用旧版装饰器或装饰器元数据时，可读性可能会稍逊一些。通常情况下，整个操作流程（不含ESLint配置）不会超过一分钟。学习 typescript 有一定的沉没成本，但这是成为程序员的必要投入。如果连这点代价都不愿承担，或许编程并不适合你。