在大型项目上，JavaScript 是个烂语言吗？

这里的大型项目包括使用 JS 开发大型Web客户端软件， 和用Node做应用服务。
类似问题：

很多年前参与过一个JavaScript后端项目，lint用了苛刻的Airbnb规则，要求写完善的JSDoc和80%以上的单元测试覆盖率，有严格的分层设计和代码评审，使用WebStorm做IDE。在这样的条件下，代码开发到九万行，驾驭起来游刃有余。
虽然这个项目是单一仓库，但内部做了模块划分，有点像现在go语言提倡的cmd、internal目录，一个仓库包含多个微服务，共用一些通用模块，伸缩性良好，架构放到现在来看也不过时。
所以JavaScript在大型项目上是烂语言吗？个人觉得不是。如果项目基础打得好，从一开始就贯彻语言的最佳实践、编程的最佳实践、乃至软件工程的最佳实践，那么代码行数的增长并不会制约项目的发展。而JavaScript社区在最佳实践方面一直有着丰富的工具供开发者选用：eslint、prettier、ava、sinon、supertest…如果你去看其他传统语言，例如c++，在clang-format出来之前连个像样的格式化工具都没有，lint也只有勉强可用的cpplint，而cpplint的开发并不活跃。
当然，现在JavaScript有了TypeScript这个带类型的超集，已经没有必要手写JavaScript了，JSDoc的历史使命也结束了。用TypeScript做开发，让编译器生成JavaScript是更为明智的选择。

我觉得这个问题是两个问题，语言烂不烂跟它适合不适合大型项目没关系。
第一，对大型项目来说强类型是非常重要的能力，所以从设计上JavaScript就不适合大型项目。当然技术问题总有工程手段可以弥补，甚至可以用TS。但是到目前为止，JS语言还没出现具有代表性的大型项目（即使加上TS），我还完全没听说过超过百人的JS项目。
第二，毫无疑问，早期版本的JavaScript是个烂语言，它的作者自己都非常不喜欢。但是它是个有亮点的烂语言，它的烂体现在一些明显粗糙的局部设计失误上，而不体现在整体思路上，修补到ES2018，我认为它已经是非常好的语言了。

你说的那个镜像问题其实已经说明了js的处境，因为python有的问题js一样有
先说结论：这么说吧，不是js是个烂语言（虽然js本身确实不咋地，ES6之前尤其烂）。而是所有无法进行“输入输出变量类型检查”的语言，在大型项目上都很垃圾。
大型项目有什么特别的？特别之处就在于大型项目的工作量你必须找人协作，你再NB大型项目的工作量也很难一个人完成（你够牛你当然可以做完，猴年马月之后对不？）。于是多个人写代码，约束非常重要，否则就是一个人一个样。光有约束还不行，还得有工具来帮助工程师检查漏洞。那个镜像问题不也说了吗，Facebook的HHVM有一大堆顶尖工程师写的代码检查工具，帮助你解决诸如“变量传来传去后就不知道是啥玩意了”的这一类问题，而这种问题对于绝大部分静态语言来说就是编译器和IDE的工作。这也是为啥知乎还有1个问题：
为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是强类型 + 静态?总有人嘲笑，说静态语言的类型检查是弱者的护身符，这类“牛逼程序员”我在知乎看到过不止一个，然而这些自以为是的人忘记了，像他们“这么牛逼（假设他们真的牛逼好了）”的程序员始终是少数，世界上绝大部分代码都是由普通人写成，最重要的是——我们是人类，人类的特长在于会制造和使用工具；而类型检查这种重复工作完全应该交给工具完成，因为自己的大脑比较突出所以能完成这种对其他人来说心智负担过重的工作而炫耀，和野兽炫耀自己牙尖爪利没啥区别，历史倒退尔。
PS1：没有自带类型检查的语言，不过是当初人们需要类型推导功能而做的第一次动态语言尝试时，一个历史错误罢了。别说大型项目，小型项目我都不乐意用这类语言写，除非没办法。
PS2：“前端没有大项目”，这句话可是前端界的同学自己自嘲的，所以js的弱点暴露的不够明显，很多人还没感觉到
PS3：就算有PS2，前几年前端界是这么说的“能被JavaScript重写的，都将被JavaScript重写”。结果从去年开始就变成了：“能被JavaScript重写的，都将被TypeScript重写”。为啥？我说各位还没闻出点味道来

JavaScript用在大型项目中……

是的，所以我们需要typescript