其实我觉得战场大家自己拉开的乱七八糟，
我也不过就是逐一回复，
autocomplete 我也说了根本不是语言的重点，
是其他人重视，这样可以说你们在讨论缺陷，
我在讨论 autocomplete 我也觉得是有趣。
另外，其实我回文在讨论的，还是应用上的优点跟缺点，
单论“程式语言学”的优点跟缺点，
weak type 跟 strong type 本来就是各有信徒，
这个我觉得再吵十年也不会有结果，
十年前这个争论就在，十年后恐怕还是在。
另外有些人不懂我对转译耗损的看法，
我只能说大家没经历过不需要转译的年代，
认知基础是有差别的。
转译的差别是，es6 在很多地方都已迈入原生支援，而 ts 则否。
目前转译除了 import 跟 react 的 jsx/tsx 需求以外，
很多东西是可以不靠转译的。
而 import 如果跑在 node ，
那就更不需要转译，我在看的是长线规格。
我还是那句话，
没经历过不需要转译的人，很难理解转译的耗损。
当然老古板被认为这是吹毛求疵，我也觉得可以理解。
ts 如果有一天可以进 ecma stanard ，或是 browser native support，
这件事情会很棒，但还远的很。
(要说的话，更希望的是 import 在 web，
能有更稳定的实作，等了十年了不知道有没有等到。
web standard 在 loading，
包括 http2 在内一直都很有野心，
但这题大家目前共识都是把成本花在前面一次打包，
我觉得这应该还是一个过度做法，总有一天会被改掉的。)
国外抨击 typescrip 给 developer 有 false sense of security.
多数人无法反对，而且回到最后本质，
原因还是 developer mindset。
ts 无法帮助你本质上直接上升生产力，
就跟 VAR 也没办法让你速成一个专案一样。
当你要进入一个世界，
那个世界就是有着各种不同的问题。
typescript 让你体会一种安全跟安心感，
但那种安全跟安心感，不是真实的。
换言之，要用 typescript 不用 typescript，
我觉得是无所谓，重点是 coding sense 。
觉得 typescript 写起来比较爽，ok go。
但别忘了他本质还是 js ，不管strong type 看起来多漂亮，
当别人要打要摸要用的时候，终究还是会出问题。
另外当 ecma script 有新的 spec ，
世界有新的 move 时，要有点耐心跟上这个世界。
有些人对这个论点可能会觉得，
啊如果 js 跟 ts 都要学怎么写 code，
为什么我要特别找 ts 麻烦。
因为，js 要学的东西，
包含 callback 包含 promise async await ，
包含 error handing，fetch or request ，
避免 magic number ，避免 bad code pattern 。
更高阶的要处理记忆力耗损跟运算量瓶颈。
这些东西，都需要时间关注，
使用 ts 这类工具，有时候会给新手一个错觉是，
我就跟着使用说明书走就好。
其实包括 VAR 在内都有这个问题。
提出这个问题会让人觉得说，好像在说这些工具都不要用，
但说真的，我觉得真正重要的是，
拿掉这些辅助跟限制，
还能写出稳定的程式码准则( coding principle)。
因为语言层的转换还是会很频繁的，
今日你觉得 ts 好，或许明日他们觉得 dart 更好。
诸如此类。
几个不同层次的命题要分开看：
1. team :
对于 team 来说，
share type definition 是不是一个有帮助的事情，是。
但定义 type 则是个耗损，
这两个权衡过是不是有帮助的，
这取决于团队的平均能力。
在团队里面，每个要做的事情都是耗损，
但别误会，有耗损不代表不值得做，只是要计算结果。
举例，如果在一个只是反复使用既有工具的环境，
如只用某些已经支援 ts 的 VAR 等核心环境，
自己几乎不需要写类别跟操作，
那这种耗损降到最低，结果升到最大化，自然就很有帮助。
如我前文讲的，
讨论这事情要看要解决的问题是什么。
这句话老是被忽略不知道是举不了例子还是怎样。
但 team & code 多到一个阶段，
即使是 java 这种 strong type，
我就看过印度人还是可以写出，
methld1~7 这种莫名其妙的定义的。
这些就得用 coding principle 来约束，
事实上程式码准则比环境要求更值得学，
但讨论度从以前到现在都很低。
在这个年代很多人觉得过 lint 就是有遵守准则，
但 lint 只能处理机器语意，不能处理阅读语意。
这几篇你会看到我对 ts 评论者的敌意，
主要在于，当我们主观推崇 ts 是更好的语言。
一样的事情发生在 VAR 上，
我们引诱新手去学习这些东西，用掉他们的专注力。
学到的却不是让程式码写的更好的技巧，
而是某些高负债高学习曲线的东西。
而那些让程式码写的更好的技巧，
则被埋在这些学习过程里面。
type 这回事对老人家来说，并不是什么太大的问题，
我们是用自己对 application 的经验补完这些认知。
yes , 要说新手没有这种认知我同意,
但要对老人开我们无法掌握 type 的地图砲，
我觉得好像也是有些太有自信。
对新手，我觉得 ts 或 js ，跟着 team 用就好，
但不需要 ts 有比 js 高人一等的错觉。
大家在处理得还是 web 的 layout/event /traffic，
战场是 browser ，不是 type 。
browser 上的铁律就是包含引用在内，少写一点程式码就是快。
所以以前大家在挑核心引用都是千挑万选，
只挑最核心的东西，不会多拿。
这年头因为 VAR 引入的关系，
复杂度越来越高，coding base 也越来越肥，
我还是那句话，感觉不到代价不代表代价不存在。
一个专案会多到 type 是个问题，
就过去经验，通常是复杂度已经到真的太高的程度了。
这是一种天然的抑制器。
而这种时候通常我的目标会是降低复杂度，
来让需要记得的事情比较少。
js 世界最烦的事情是，
前面无脑写的爽，往往后面都是火葬场。
每一个函式把上下游看清楚，
记在心理，本来就很重要。
总之，要用不用是个人选择，但凡事都有代价。
这里的讨论真是越来越无趣了，
都是精神论等级的，
“我用了 ts 以后，团队的 quality 都觉得好一点了呢！”。
好好的就案例范围分析适用性不是很好吗？
反正黑的人就黑，反黑的人就反黑，文章会高来高去是因为，
没有对手可以让我们捉对厮杀进入具体的案例探讨。
如果觉得没有人看得懂，写细节又何必？
反过来说，支持 ts 的又在这串中写了什么？
反驳的也都是软趴趴的，前面拿 double 反驳的更是笑话。