中小型系统开发中，使用typeScript很有必要吗

Question

中小型系统开发中，使用typeScript很有必要吗，这个typescript感觉很麻烦，在中小型系统开发过程中，有什么优势

Answer 1

这个问题其实是是否熟悉TS的问题。
如果你熟练使用ts，那么除了在浏览器环境下直接跑的代码，你都会愿意使用ts的。

function tsOrJs(isBigSystem: boolean) {
    if (团队现状是绝大部分人不熟悉ts) {
      return 'js'
    } else {
      return 'ts'
    }
}

ts中，这段代码会提示：已声明isBigSystem，但从未读取其值

Answer 2

不知道，但我很愿意用ts。
上半年写的js现在已经看不明白了，除非写一大堆注解。通常不敢随便改，很多数据结构都忘记了。
有个类型申明，就比较明确传递的内容

Answer 3

如果我们只是写个helloWorld或是简单的写个 DEMO，那用ts没有太大的必要（但实际上写helloWorld我都会用ts ---- 配置简单的工具它就能够自动编译，自动更新，自动重启浏览器，自动查看新的结果，这不香吗？)。

但如果是你提到的系统开发，那就太有必要了。既然是系统开发，就必然涉及到多个模块间的耦合，也必然会涉及到多种数据类型。而我们之所以学习各种开发理论，实际上都是在解决软件迭代及变更的问题。而 TS 能够在某个依赖的模块发生变化时，在第一时间通知你，配置着一些好用的 IDE 开发工具，甚至可以一键修改变量名，方法名，参数名等。

ts的强大作用在于它并不需要你将系统部署到生产环境，就可以告诉你哪有语法错误。而不是像以往 JS 的时候，只有等上线后用户在使用过程中发现，TS 会把这些错误直接扼杀在编译阶段。

另外它也能够帮助你减少由于不小心产生的拼写错误，比如：testComponent.label与testComponent.lable，或是比如: UserFormData与UserFromData，或是 userFormData与userFormDate

它还可以在后台的接口数据变更的时，快速地完成适应变更的过程。

当然还不止这些，相信随着你对它的了解与熟悉，过一段时间你将感谢今天开始尝试用 TS 的自己。

Answer 4

我现在写ts写习惯了，现在即便是小型项目，我也会配置上ts。

真香！

Answer 5

我觉得和系统复杂度、后续维护复杂度有关。使用ts可以有效的将交互和业务逻辑解耦，前后端分开迭代可以最大程度降低复杂度。当然，如果你的系统是一个软件产品，一旦售卖出去后基本不会更改，那不管使用那种前端技术都可以，只要能满足快速交付的目标就好。（但是，一旦需要修复bug或是有大的变更，那将是灾难）。当然使用ts还有性能、开发友好、社区活跃等等一系列的好处，我不是专业的前端开发人员，了解到的好处就这么多。

Answer 6

先给答案。根据实际情况需要，但比较建议使用Typescript实践。

---

对于没使用过或刚入门Typescript的前端开发者而言，其实是比较难以理解强类型语言的。特别是对于一些强类型语言没有过多实践的开发者，经常会觉得Typescript难写，甚至有些问题根本无法解决。所以经常会将类型写成Any，但是这样即时写了，也没有任何价值。

稍微用过一段时间Typescript语言的，就会喜欢上Typescript，觉得什么都应该使用Typescript去写。这样的开发者可能是大多数，他们利用已经维护好的三方库类型，在此基础上做业务类型扩展和开发。对于他们而言，Typescript提供了易用的接口提示和类型错误检查，可以提前避免一些不经意间的问题，同时能够解决团队间协作的问题。

随着这些开发者对Typescript的不断深入，他们会开始写一些泛型和帮助函数，渐渐开始形成他们自己的依赖库和定义。但在此过程中会渐渐发现Typescript的一些问题。虽然Typescript仍然在高速发展中，但它受限于EcmaScript语法，很多扩展难以实现。这些开发者会越发觉得复杂类型定义的困难，这种困难是Typescript本身功能受限导致的，是无法解决的。而对于另一些开发者，他们可能需要使用到一些标准的新特性，因为Typescript标准库里通常不会有非常新的特性，三方依赖库的类型也依赖作者或社区，所以有时类型的不一致会让开发者非常痛苦。开发者通常会选择自己实现覆盖原有定义，但也造成了另一个问题，那就是可能会和未来更新的类型冲突。

随着项目的增长，和Monorepo的实践，仓库代码体积将不断变大。这时候除了Typescript本身之外，需要有对于整体工程良好的架构设计。但即便如此，当不同的包之间需要不断地重复引用时，就会造成大量的内存占用。因为Typescript设计的问题，它会尝试去加载所有作用域下的类型定义文件，从而占用大量资源，大幅增加完整编译时间。此时通用的做法是，在编译时将编译和类型检测分开进行。但又会由于一些工具的不一致，导致无法完美地发现问题。

上述问题会一直伴随着开发者，而Typescript的迭代更新虽然会引入一些功能，解决一些问题，但也会引进一些新的问题。一些复杂的问题，是无法通过Typescript的错误描述知道原因的，只能通过跟踪Typescript源码发现问题，特别是在工程特别复杂的时候。

还有一部分开发者会追求前端用户的极致性能。因为Typescript最终还是要被编译成Javascript文件的，所以压缩文本可以减少IO，而其中利用EcmaScript的语法特性进行压缩是有必要的。但是Typescript的强类型会强制一些类型要求。开发者不得已在书写Typescript的时候使用类型转换，无谓地增大了最终编码的体积。

于是，这些开发者会寻求一些新的出路。Typescript主要的用途还是在于类型检查和提示。翻篇整本Typescript手册，官方提供了一种基于JSDoc的类型提示方法，而利用一些静态代码工具，我们也可以完成类型检查的任务，对于一个类型的实现细节却不必关心每个堆值的类型。于是，这些开发者会只标注接口的输入和输出，而将具体实现变成黑盒，利用其他的手段诸如单元测试保证程序的健壮。

到这个阶段虽然仍然利用了Typescript的能力，但已经基本摆脱了Typescript的束缚，可以在享受Typescript的收益时又自由创作。但历史总是循环往复的。当这些开发者开始摆脱EcmaScript时，又会遇到新的问题。

这时的问题似乎与Typescript已经无关，因为它已经超出了Typescript一开始设计的范围，甚至EcmaScript的范围。当WebAssembly变得越来越流行时，我们亟需一种适合前端开发者的开发方式。最完美的开发一定是通过WebAssembly Text创建WebAssembly模块，但类汇编的语言总是让人觉得麻烦易出错。通过高级语言编译的方式中，可能只有使用AssemblyScript比较适合前端开发者，而且编译时可以尽量排除不需要的库和帮助函数，从而减小WebAssembly的体积。AssemblyScript语言是Typescript语言的超集。不过对于这些开发者而言，他们只是重拾了Typescript。

再往后，可能已经远远超出了本问题的关注范围，但还是不得不提的是：随着开发者对计算机知识的深入和知识覆盖的广度增长，很多问题殊途同归，回归了本质。他们会寻求开发效率和用户体验之间的一种平衡。任何一种语言都可以作为开发语言，也没有任何一个问题可以阻挡他们，总是可以在不同的语言和实现方式之间实现互补，而最差的情况也只不过是自己实现底层逻辑。Typescript对于他们而言，与EcmaScript是一样的，只是众多语言中的一种，是解决问题的一种手段。

金无足赤。任何一件事物都无法满足所有场景需求，语言也是如此。

回归本问题，其实原本是没有一个必然确定的答案的。这也是为什么会有这么长一个回答的原因。
但本问题有一个前提“中小型系统”，由此可以推论，在大多数情况下，开发人员有一定规模，但却不会是大量的、跨多地区、有较多习惯差异的情况，也不会需要进行过于复杂的设计和开发，极少涉及底层。在这种推论前提下，使用Typescript是比较合适的。虽然仍然会有上述提及的一些问题存在，但在寻求团队协作、提高开发效率和质量的平衡思考下，选择Typescript仍然是比较合适的。

话虽如此，但还是要根据实际情况选择哦，说不定你们的工程就是万中无一的独角兽呢？

Answer 7

如果项目是开发完成交付出去给其他人维护使用，且项目不大，使用JavaScript。万一对方不会ts你还得写文档说明怎么才能跑起来。
如果这个项目是你们长期维护的，那就用ts。