※ 引述《as30385438 (LCH)》之铭言： : 光是在obj後面.一下就会跑出各种method和argument/return type : 就不知道能避免多少低级错误和省下查文件翻code的时间了 : 所以说用TS会拖慢开发速度的人 : 我真的不知道他是在做什麽神奇的专案需要用到诸多JS的神奇特性 project scan 就是需要时间, 你档案数多到一个程度, 就是慢. webpack 有那麽多 tooltip 再加速效能, 难道是假的. 说真的, 这段话反过来说也是可以还给你的. 连自己的 type 跟 convention 都掌握不好的, 是有什麽好靠邀的. 另外 js 的 autocomplete, 就算是十五年前我用 aptana 就有 autocomlete, 真的这麽喜欢有 type 写个 jsdoc 就好. (还是不知道什麽是 jsdoc?) 是要多聪明才觉得 typescript 是唯一达成 autocomplete 的方法. 而且我还是那句话, 你今天碰到 ts 世界以外的模组, 你是要怎麽 autocomplete 跟省时间. 你高兴把自己关进笼子里面是你的事情, 但有些人觉得这是找自己麻烦的事情, 不是你一句神奇专案才花时间可以带过的. : 相关的webpack config也只要设定一次, 何乐而不为呢 是每个专案你都得设一次. : 当然你可以说, 只要平常规范足够好, 大家团队意识够强 : 加上每个人记忆力超凡, 写过的每个function是做什麽的都不会忘 不需要的 : 每个人都是完美的JS programmer不会踩到一些不该踩的坑 : 那当然用JS也不会有太大问题 一样是不需要的 而且写 ts 还是可以踩雷坑, 不要讲的好像那些 bad pattern 在 ts 可以被语言层防住. 写 ts 你不管好还是会有人写 magic number, 还是会有人滥用 any, 还是会有人乱切责任跟 function. 就我在前端是界打滚的经验, 前端世界要解决的问题, 最大的挑战一直就是毫无意义的 include, 跟缺乏 management 的 codebase. : 但我们都知道, : 人 是一定会犯错的 : 的确, TS不能解决所有问题, 但要把这锅推给TS就有点诡异了 : 这个逻辑有点像：「反正用了也只是从30分到60分, TS真粪」 你可以举例的时候不要一直带入自己的偏好吗 如果是我来举例的话, 大概就是30分变20分吧, TS真粪. 这种举例有什麽意思吗? 你喜欢他可以美化他我没意见, 但今天在讨论中, 你有办法就举出真的改善了什麽, 举案例出来, 有道理的没人会反驳你. 但透过这种莫名其妙的比方, 甚至你原文也承认有需要更多设定, 有设定就有编译时间耗损, 然後你只是轻描淡写的说你觉得代价不大. 但我就是觉得这代价他不愿意扛啊 这什麽亚利安星球反驳法. : TS本来就是以尽量不破坏JS原有特性下改进JS的可读性 严格来说, TS 破坏 JS syntax 的一致性, 但他最後转回 JS, 所以你说不破坏JS原有特性我是可以理解. (废话 转成 js 是要怎麽破坏 js 的一致性) 但不一致的 syntax 就会造成学习负担. jsx 当初出来也被干谯过一样的事情, 但当初大家忍是因为这样可以换来, 跟 html 相关的 markup 表达, 确实有助於语意理解. 但这件事情也不是没有代价的, 干谯的声音一直也都有, 我角度看这也是 react 迟迟无法一统江湖的核心因素之一. : 拿any来说, 敝公司的tsconfig中是有设定nonImplicitAny : 新写的code中要用上any也必须给reviewer足够好的理由 : 在prototype偷塞东西这种事情也是没事不会做 所以你解决问题的方法是靠 reviewer 把关啊, 不是靠 TS 帮你把关啊, 你到底是来帮 ts 讲话的还是黑 ts 的 : 除了一些很底层的模组, 例如支援mixin之类的 see? : 不要因一时贪图方便造成後续难以维护 : 我认同大大说的, 的确没有办法控制整个世界照我们想要的规矩走 : 但这不是我们不能在力所能及的范围内做到最好的藉口 我个人觉得所谓的做到最好, 不是学会最屌的强型别, 而是组织好程式用最低的成本达成目标. 我说了, 辅助轮再怎麽样会有辅助效果, 但他不是没有代价的, 有些人从一进这个世界就付出这些代价, 自然已经感觉不到代价. 我前面几篇都反覆再强调一件事情, 所有工具都有他要解决的目标情境, 但 JS 世界或许现在的人不太在意, 偶尔就会看到一些明显没这种知识的 application, 程式码的组织跟程式码的庞复程度还是严重的影响到下载速度跟体验. 特别是 client rendering 的程式. 今天如果我们谈的是 web base 的 ts code, 跟我们谈 node base 的 ts code, node 我会觉得还好, web 我就觉得有点浪费. 我们讨论到这里, 任何一个可能的专案情境都没举出来, 我实在是不知道我们在谈什麽. 我今天谈的不是 TS 有多粪, 而是没掌握 JS 的人到底有啥好说 JS 粪的. 这当然是个战文, 但我就想看有多少人可以战这个议题, 然後讲得周全. 对 TS 的优点讲来讲去就是 type check, 刚有个推文写了, 无法明确定义 type 的是不好的工程师. 不好意思, 问题被错置了, 谁跟你说无法定义 type, 是不需要用这种方式定义 type. 用相同逻辑, 我才想问, 不靠 TS 就搞不清楚 type 的, 是能当什麽工程师. 我从还没 typescript 的年代就写了很久的 js 了啦, 如果今天我们是在 ES6 class 还没出来的年代, (这是当年 typescript 最大的卖点), 这些倡议我都觉得有些道理, 这个年代, 我们再用能 autocomplete 来说明这件事情, 我也是会想问, 啊是写了多伟大的东西. 需要这样才能做好. 命题是想谈新手好上手, 还是要谈老手(我)对 ts 跟 js 的理解, 这些最好是讲清楚, 不然被开群嘲我也不知道该怎麽救. 这世界上自以为自己是进步的人很多, 当年 rails 喊的多红, 其实 typescript 也曾经吸引过一票人, 後来那些人多数都退坑了. 这次到底是再来一次, 还是能长久, 我倒是乐於看戏. 不要急着以为别人都不知道这些事情, 我们是看着规格一路发展过来的... -- 网页上拉近距离的帮手 实现 GMail丰富应用的功臣 数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ 欢迎同好到 AJAX 板一同讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 210.61.209.201 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1605508606.A.97B.html ※ 编辑: TonyQ (210.61.209.201 台湾), 11/16/2020 14:41:57 team 要有一套自己的 type 跟 conention 啊。 不然咧，使用 ts 也是一种 team principle 啊。 ※ 编辑: TonyQ (61.231.44.97 台湾), 11/17/2020 10:11:36