其实我觉得战场大家自己拉开的乱七八糟， 我也不过就是逐一回覆， 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 反驳的更是笑话。 ----- Sent from JPTT on my Google Pixel 3 XL. -- 虚实之间的世界，反抗军与启蒙军的交集 带着 Android 去旅行、去发现 在身边浑然不觉的 另一个世界。 全世界，都是我们的 足迹与游乐场。 ~ The world around you is not what it seems. ~ http://ingress.tw --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.231.44.97 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1605577598.A.805.html 人的学习时间是有限的，你学了 A 就会延後学 B 的时间，我只是在点出这件事情。 当然要说长期来看都是要学的， 这点我没意见，但不是只有这个方法可以学。 「标示」型别系统只是拆解问题的一环。写 js 还是有型别，不会因为写 js 就不写型别。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:08:20 确实也是有可能，不排除。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:12:03 楼上黑的真认真，凡是你不同意的，写再多字都是凹对吧呵呵 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:22:49 讨论区人人得而回之，咬我啊～ 不会啊。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:31:46 嗯嗯，免战牌挂的真溜。没人不知道你避战了。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:32:20 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:32:47 java 还是有 scala/groovy 之争啊，人多就会有派系。XDD uglify 不会在开发期做，我们这里讨论的是「开发成本」。 我以为我前文已经写过，这篇就没特别写了..... 另外 react 因为xml 的 spec 转译成本特别高(不少)，以上说明。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:42:12 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:44:27 应该还会有几个老人讲，马的我用 java 就好，陪你们搞一堆 groovy 跟动态类别，在那边吃我的 meta class 空间。XDDD ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:47:11 开发时降低转译成本，在浏览器有增加运算成本。 两个成本谁高谁低各有见解，但两个是不同的东西。 增量编译不慢，但除非你程式永远不 shutdown ，不然你还是得处理中间的编译成本。 我们对开发时间是很敏感的。 至於你说专案肥本身会影响编译时间，没错，但增加一个不小的乘数一样会让总数变大。 网路上不少脱离 ts 的讨论抱怨的都是 compile slow 。 我在提醒的是这个部分。 更容易用应该也包括开发时间的降低，我从头到尾在意的都是「开发时间」。 後期语言的目标跟策略，根据目的不同，但多数语言都有在降低开发时间这点试着做出各种 讨论开发时间本来就是高阶语言的目标跟特性之一，重点是你要解决什麽问题。 如同我在我最早回文第一篇的第一行跟第一行，先定义问题。 jQuery 就我印象所及，没有让我每次启动专案都要等两秒以上的编译时间啊。 jQuery 就下载成本跟 eval 成本，再搭配普及到翻的 cdn ，拿来跟webapck 搭配 tsx 比? 另外 jquery 是为了 browser 的一致性，不是为了让你写起来可以组织更大的程式码。 (好啦 jquery plugin 那段勉强算，但当年的契约也非常严格，基本上是不想要叠太多层。) 早期真要说的话，大一点的专案，会 merge js 跟 ugly ，但 again ，这些是在 production layer ，client layer 还是用 require 之类的非同步载入方案处理。 後来 require 跟 common js 在 node 插手以後的大一统就先不论。 但今天讨论的是开发体验，降低开发时间的耗损跟取舍，一直是个重要课题，不能草率的假设有耗损也没关系， 也不是说有耗损就一定不能用。 而是每件事情都有代价，算清楚代价划不划算。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 11:34:37 转译成本不一样啊，我原文要讲的一直都是转译换来的代价是什麽。 然後你没发现我只挑 jsx 出来讲就是因为他的转译成本特别高。 但我还是写 react ，因为他的元件架构我最认同写起来对我最快，整体可以降低成本。 讲有损耗这种算的出来的东西，也要这麽罗嗦。 别的不谈 babel 你 polifill 到哪一板，就会严重影响编译时间了。 哪个团队不是在这类编译成本的降低煞费苦心。 你说代价你愿意付我没问题， 你说大家都在付所以不是问题，我就想问，你的时间不是时间吗？ ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 11:40:56 不会啊, 在 2020 年我还是推 react 啊, 只是不推你 ts. 在 2008 年我推 jQuery (2008 coscup 演讲), 在 2011 年我推 require (多场 meetup), 2012 年我推前端专职化(JSDC), 在 2014年我推 react,webpack, polymer. (jstw) 2014 年我就在用 react 写 SSR. 我也会推有理想性进步性的东西, 只是你的进步跟我的进步不一样而已. 重点还是 cost & revenue. 欢迎嘘, 但大家都不发文怪我罗, 你发一篇文把我的文章挤出去, 我就少一篇啦. 你们写文章可能很难吧, 我信手捻来都文章呢. 更何况里面还有一篇别人灌水的. XD ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 12:13:43 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 12:14:12 这个理由我十年前买 SSD 时就用过了 用了十年SSD了现在对这些细节还是很敏感啊(怒) 你可以写你的论点是什麽, 但举几本书好像不算论点. 这几本书我都不是没读过, 你要不要明确的指出是哪一章的哪一个论点冲突. ※ 编辑: TonyQ (210.61.209.201 台湾), 11/17/2020 13:10:54 ※ 编辑: TonyQ (210.61.209.201 台湾), 11/17/2020 13:11:53 我文中的例子举的数量， 比这串人所有提到的总数还多。 ※ 编辑: TonyQ (223.137.174.34 台湾), 11/17/2020 13:40:52 我也觉得是你的问题，看起来我们有共识了。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 14:20:38 重构强调 type 的重要性，关标示 type 有成本屁事。 红绿灯很重要，代表盖红绿灯不用钱喔。 红绿灯很重要也没每个路口都盖啊。 ※ 编辑: TonyQ (223.136.191.168 台湾), 11/17/2020 19:53:39 孩子，该长大了(< 这是你想要的回应吗？) 如果你可以举得出 ts 超棒棒的情境， 你就比我厉害了。 我写文分享从来就只为了写给有兴趣看的人， 不是让人觉得我厉害的 。 你们看我文我没收门票钱， 自然也不用付你们评论费，你说对吧。 看的不爽，写篇好一点的反驳， 好歹我文章写的出来，你的文章还在路上。 社群讨论是用不同意见论战的，不是用嘴炮回文的。 对团队合作这几个字，你们实践在哪我不清楚， 但这几年我的心思倒是都在这几个字上了。 就是因为重视团队合作，才更需要一套可以快速训练上手的 principle， 而不是语法蜜糖。 说 ts 就可以让旧人避坑，照这说法， csharp 跟 java 不就都没坑了。 是你做不到或放弃做到，别假设我做不到。 我觉得是你带团队不够久才不明白，能教会大家做人， 可能 pornhub 都还比较有贡献一点。 TS 的编辑器会让你以为自己避开了这些坑，直到你再度的踩进去。 是说先不说小明我对他评价高的从来也都不是他的开发技巧, 啊是说这里的人讨论事情是怎样, 好好的讲话是不行吗? 动不动烙年纪, 烙朋友, 烙经历, 啊是回不了正题了是不是. such a good response . 有够有格调的回应. ※ 编辑: TonyQ (61.231.44.97 台湾), 11/18/2020 13:50:50 我一向习惯在战场上用别人的招式跟对手辩论. 啊一个一直嚷嚷着不用认真, 躲在旁边嘘文, 连这蠢浮点数都要瞎跟的...... 不是我要贬低谁, 而是...... ※ 编辑: TonyQ (210.61.209.201 台湾), 11/18/2020 19:25:53