Java
最大的问题在于性能，不过这里指的不是编译为
JavaScript 后的运行时性能，而是实际应用于前端或 Node.
JS 项目时类型推导的性能。在大型项目中，语言服务（Language Server）冷启动后的初始化时间常常会长达 15 秒甚至超过 1 分钟，这种体验在许多其他语言中是难以接受的（JetBr
AIns 的项目加载机制比较特殊，这里仅讨论 LSP）。如果依赖的库或者 tsconfig.
JSon 文件本身存在问题，语言服务可能会陷入崩溃的死循环。这引出了另一个问题：tsconfig 的配置项过于繁杂。最近几个版本的
typescript 已经可以通过错误提示指出哪些配置可能有问题，但在早期版本中，开发者只能根据具体症状自行排查。这些配置表面上是为了提供灵活性，但实际上更多是为了兼容庞大的
JavaScript 遗留代码。从根源上看，这也是我对当前前端生态不满的原因之一——虽然一切看起来都很美好，但一切都显得不稳定。说到这里，我可能给人一种爱抱怨的印象，确实，我对当前前端开发有不少意见。比如新的 create-vue 工具会以组合方式在根目录生成三个 tsconfig.
JSon 文件。如果你想要一个现代化的 Vue 前端项目，根目录大概率会出现一堆配置文件：真的有必要这么多吗？我认为我们需要更现代化的整合方案，并且优先优化性能，这也是我选择尽可能使用 Deno 的原因。然而坏消息是，Deno 本身也并不稳定（笑）。
