typescript+nodejs是否适合开发大型项目？

都说nodejs不适合开发大型业务类的项目，如果用typescript+nodejs是否适合开发大型项目？原因是什么？

热心回应 · 2019-8-12 00:09:07

首先定义「大型项目」。我认为大型项目的标准是：业务问题和工程问题的复杂多样。
如果我们认为一个项目中可能遇到的业务问题和工程问题是一个封闭的问题空间，那么技术选型能覆盖多少这个空间中的问题，就成了最重要的考量。
代码行数太多？人太多不好沟通和维护？——工程问题
并发量太大读取数据库速度太慢？——业务问题
自动发布总挂？测试用例覆盖不够导致 quality degradation？——工程问题
I/O 密集型 app 需要大量频繁和第三方通信？——业务问题
等等不一而足。每个项目都会占据这些问题中的不同种类和数量，提前预估问题空间，就是架构师和技术经理的责任了。
所以我说，说合适的怕是不理解什么叫大型项目。在问题空间不明确的情况下，这个问题就变成了在普遍意义下，TypeScript + Node.js 的技术选型，能否 cover 到足够多的工程问题和业务问题总和。答案显然是不能啊盆友们！TypeScript 只解决了一部分工程问题，对业务问题的解决几乎没有任何贡献。Node.js 在大多数后端项目中只能做非常靠上层的业务，比如 Node.js 天然的异步特性虽然提供了很好的 I/O 性能，但对严重依赖事务操作的业务非常不友好，对稍微有那么一点点规模的服务端应用可能就会用到的跨库、跨业务的分布式事务解决方案，在哪里？
有人举例 VSCode 和 Slack 这样的客户端应用——没错他们很复杂，而且 VSCode 的负责人 Erich Gamma 是曾经负责过 Eclipse 和 Visual Studio 的人，他们当然是大型项目，但是这只能说明 Electron 能适用「工程问题和业务问题总和」中复杂客户端这一领域。VSCode 最大的优势就是快，Electron 是 GitHub 的项目，GitHub 自家用 Electron 做的 Atom 性能被 VSCode 吊打，你能说是 GitHub 的工程师不够优秀么？为什么要 Erich Gamma 这样级别的人负责才有 VSCode 的性能？这还不说明点什么问题吗？
在不明确的「工程问题和业务问题总和」这个前提下，100 个复杂的大型项目中，TypeScript + Node.js 也许可以胜任 10 个，Python 也许可以胜任 20 个（原为 40，不懂这个根本不是重点的信息为什么会那么多人在意，语文都是体育老师教的么？），Golang 也许可以胜任 30 个，Java 也许可以胜任 70 个。你非用可以胜任的那 10 个来说明 TypeScript + Node.js 适合大型项目......对 Java 来说，某些场景和业务你用 Java，最后的感受可能是「真特么麻烦」；对另外一些场景和业务，你用 Node.js 结果可能是根本做不出来啊...
真正的大型项目一定是多个服务组合起来的应用集群，Node.js 可能非常适合这个应用集群中的个别场景，从而作为复杂系统的一部分而存在，但他自己在非常庞大的问题空间中，真的称不上「大型项目」。
=============================
给读不懂那几位翻译一下：

Node.js 在一些业务场景和大型项目中适用，在个别能发挥自身优势的场景下还能完爆其他技术选型
问题没有明确的指出是何种应用场景下的大型项目，那么我理解是想问普遍意义的大型项目中是否能够适合
在 2 的前提下，用个例推导出结论是不科学的
在 2、3 的前提下，以全世界「工程问题和业务问题总和」为样本，统计意义上 Node.js 能 cover 的场景在所有可能的技术选型里绝称不上「多」

热心回应 · 2019-8-12 00:09:08

无数程序员整天就沉溺于“大型项目”跟什么“高性能”上无法自拔，患得患失，昼不能食，夜不能寐。最终死就死在了这个“大”和“高”字上。
多少人的项目大到了 PHP、Python、Node / Express 撑不住了？相反，大多数创业公司根本来不及换技术栈就死了吧？
数据要大，项目要大，你啥都要大大大。还不如少操点心，多花点时间专注于一门技术来得实在吧？
况且复杂项目根本不是什么一个 TypeScript + Node.js 就能撑起来的，也不是一个 Spring MVC + MyBatis 就能搞定的。这么说的话，Java 语言也有力所不逮之时嘛。
多花点心思在业务上，根据业务发展的需要，选择匹配的技术栈——其实解决问题就应该这样呐。

热心回应 · 2019-8-12 00:09:09

这个问题有点本末倒置了。
大型项目开发的好不好，我觉得重要程度有以下排序人>架构>>语言。人的问题不好评判，但架构可以搭建的更好。架构都在推崇服务化，组件化。很大的原因就是即使这个组件或服务被人写坏了，只需要重构这个组件或服务，而不需要重构整个架构。
而问语言则不一样，假设之前是用js写项目把项目写坏了，可能你换ts会对代码理解有一定的帮助，但对于复杂的逻辑杂合的业务，该杂合的还是杂合在了一起。遇到难以解决的问题最终结果还是重新整个都重构一遍，所以ts绝对不是救命稻草。
我觉得大型项目开发还是要从架构入手，而架构则有两个重要目的，一是方便开发，二是增加约束。如现在流行的组件化和服务化也是一种约束。
所以我认为越大型的项目开发，只有架构的约束越多才越不容易做烂。当然ts也算是一种约束，在小型到中型项目这种约束或许重要，但上升大型项目设计中，这种约束绝对不是最重要的，反而将服务颗粒度约束到更细化才更为核心。

热心回应 · 2019-8-12 00:09:10

不专业就不要回啦，误导他人。

什么样的算大型项目，是按puv算，还是代码复杂程度。我觉得都适合大型项目开发的。

ts没啥毛病，非多人合作项目我是不用的，不够折腾的。简单的commonjs写法，写个模块简单应用还是特别爽的。
问题在于，用的人可能会玩坏，所以需要类型。
当然，oop肯定面相过程要更加适用于大型复杂项目。
至此，ts是满足的。

下一个问题，node是否适合大型项目，反复的讲过node应用场景，前端渲染，api proxy，后端服务。这三部分都行，但一般推荐做前端渲染和api proxy。其实缓存，rpc真的都玩烂了。
c端和b端哪个也没少的了node，阿里的node应用几乎覆盖了所有场景的，量和复杂度都有，我认为它是适合大型项目的。
再说node操作数据库，支持的很好，但不一定能用好，这不是简单的模块调用，还藏着大量后端只是的，比如db分库分表等，java里玩烂了，node里玩溜的不那么多。这种比较不厚道的
node里企业级web框架首推egg，用过的都说好。nest这种ts写的框架还没真正火起来，路还很长，它代表不了node。如果是非要ts，淘宝的midway不错，基于egg生态，ioc等支持极好。
express和koa黑的不在点上，如果他们不好，java里干嘛搞spring boot类的。简单够用，有egg不用，非要自己定制一个egg，当然没egg好用。
再说大型项目，谁用一门语言写吗？不懂架构吗？
从微服务，到云原生，到serverless，都是多语言的。今天造web框架轮子的人越来越少，不是技术凉凉了，而是架构升级的必然结果。
举个简单例子，node做前端渲染，除了react这种纯前端外，自己组装rpc缓存（node世界里rpc实现不多，但rpc client是极多的）。rpc一般是java提供的，他们也是包裹过好多服务，整个链路非常好。大家在项目里找到平衡点就好，争来争去的没啥意思。

最后总结，ts+node适合做大型项目。指的是应用级别的，如果是模块，无所谓ts的。未来没有运维，不用担心qps才是node的未来，未来已经不远了。

热心回应 · 2019-8-12 00:09:11

适合

typescript+nodejs是否适合开发大型项目？

5 个回复