如题。
我想引擎组主要是为了照顾大部分游戏开发者的情绪，才不得不使用ts吧。
项目没做几个，各种编程语言却学了一堆~
你会因为你的游戏用户说你程序是用js写的，而花费大量人力改为ts吗，不可能的，这是发展需要
嗯嗯，我们唯一能做的就是尽力去适应新环境。
对于一个有js编程经验的人，转ts也就看个几小时文档的事
ts 大法好
1赞
ts可读性好太多了
1赞
js转ts就分分钟的事
js转ts就分分钟的事
而且是可以混用的,你不学ts,完全可以继续用js
要持续学习，不要抱怨，你改变不了大环境，那就要学会适应…
2赞
我就是为了逃避TS，而学的coccs creator。当初用白鹭（白鹭只支持TS）做了好几年，后来才发现JS才是王道，果断转了ccc。
TS最大的问题是集成第三方JS库太坑了，毕竟github上大大小小知名不知名的第三方贡献者都是用JS的。简单的调用还好，类库如果比较大，需要对应的 d.ts文件，否则ts不能直接调用。
1赞
我新建文件都是用的js
哪个版本是ts写的？
哦，是3d版。去学习下。
之前js写的代码感觉已经不可用了，需要重头改一遍。有点烦 感觉兼容性没做好，似乎有点理解unity的同事为啥喷了
为了ts的智能提示，真的特别方便，然后入了坑，才发现，除了智能提示，好像也没什么优势哈哈
1赞
ts 的优点 代码补全 代码重构 跳转到定义
js 不用写类型 ts感觉跟java c# c 这些强类型很像
js浏览器可直接识别 ts需要先编译成js
最近我比较闲，入了ts的坑，关于调用js库确实是一个很操蛋的问题。除了这一点ts真的很棒，ts requir导入之后编辑器没办法检索到变量的类型，调js脚本的方法后传参webstorm上还报错，虽然运行没毛病，但是看着贼难受。ts生态不是很大，很多库都还是js，现在很犹豫要不要入ts的坑
js="火车"; ts = "地铁"
两者都是在轨道上运行的 看你喜欢坐缓慢的火车还是愿意挤高效率的地铁
我们用js。
因为ts需要转成js再运行，项目大了后（目前十几万行代码了），这个转换会慢。。。
js我们按严格JsDoc声明公共接口，目前提示没任何问题。
只有一个坑：因为cc.require不能指定全路径，导致require进来的js脚本没办法提示。。。。
编译的时候，ts会转成js，何来的高效率?
他说的是代码补全