TypeScript性能(asm.js,闭包编译器)和开销

Question

我正在考虑将TypeScript结合客户端MVC(很可能是Backbone.js+ Marionette.js或Ember.js)用于未来的项目,因此有一些与性能和优化相关的问题:

• TypeScript输出与原生JavaScript性能相比如何？

• 既然asm.js是JavaScript的子集,是否可以将TypeScript代码转换为asm.js代码？如果是的话,它已经可以吗？

• 创建TypeScript与之一起使用的AMD项目的构建是否可行且仍然有用Google Closure compiler？

• TypeScript平均添加多少开销,文件大小明智？

• 例如Backbone.js,在小型项目中使用轻量级库时.TypeScript在文件大小方面使用是否有意义？

我喜欢额外的好处,TypeScript但我不想牺牲性能来编码风格和打字.

任何有关TypeScript在大型项目中使用的文章/书籍,特别是与性能,优化和构建相关的内容都非常受欢迎!

先感谢您 !

Answer 1

我们在团队中彻底评估和测试了TypeScript,其他团队已经使用过它,所以这是我的经验:

• TypeScript是JavaScript的超集,它主要将1:1转换为JavaScript而没有任何重大的性能损失,因此如果您知道如何编写高效的JavaScript,那么您就知道如何编写高效的TypeScript.其中一个不那么有效的特性是继承,它使用JavaScript原型"模拟"并生成比JavaScript中通常编写的代码更多的代码.所以谨慎使用继承.您可以查看生成的JavaScript,以查看您的构造是否针对您的情况进行了足够高效的编译.
• 编译打字稿到asm.js与编译JavaScript到asm.js的问题是一样的 - 你需要模拟asm.js缺少的功能与完整的javascript相比...如果你需要asm.js中的某些部分你可能需要自己编写或者通过emscripten等编写一些更合适(动态性较低)的语言.
• TypeScript有一些AMD的支持,但我不能谈论谷歌闭包支持......因为它试图以非常不同的方式完成类似的事情(注释中的类型和元信息而不是新语法),我认为它们与使用非常兼容最多两个......
• 文件大小不是真正的问题,它与可读JavaScript的文件大小非常相似,除非你经常使用继承
• 与JavaScript相比,将TypeScript与骨干和其他库一起使用有一个好处; 大多数流行的库已经有TypeScript的类型定义文件,因此您几乎可以免费获得自动完成和类型检查.与编写良好的JavaScript相比,文件大小差异并不是真正的问题.

TypeScript还很年轻,我们想要拥有的许多东西(JSLint,代码覆盖,TDD,BDD工具......)当时都缺失了.另外,编译器中有几个错误(之后已经修复),所以我们没有选择使用它,但是你的列表中的任何一点都没有显示为我们真正的拒绝......

更新:要了解TypeScript的潜力,您可以查看Visual Studio Online"Monaco".他们在那里所做的非常令人印象深刻,请参阅TypeScript快速入门