※ 引述《TonyQ (得理饶人)》之铭言：
: 是说应该要定义什么是好什么是烂,
: 我是觉得啦, 能解决问题叫好, 不能解决问题叫烂.
: 程式只是工具, 人才是决定 code 是不是垃圾的载体.
不太认同, 如果今天的task是计算1加到10000
从纸上开始 1 + 2 + 3...一直算到10000可以解决问题
用等差数列的公式也可以解决问题
写段code直接写个function让function可以支援不同的min, max也同样能解决问题
这些方法都能解决问题？难道他们都是好方法吗？
回到程式语言, 我相信大部分人都觉得战语言优劣很无聊
毕竟工程师都有自己偏好
但前端这块就比较不一样, 大部分人用JS不是因为喜欢或是适合
而是因为没有别的选择
前面在吵的web assembly目前来说生态系还差太远
看起来它也是以补强而非取代JS为目的
为什么近年TS开始红起来
我认为不是像大大说的, 那是能力不足的人在用的
以同是动态语言的Python为例
typing模组不管是语言面和IDE的支援也都越来越完善
我待过的两间公司也都规定新写的code能加type hint就要加
不过Python虽是动态语言但却是强型别, 跟JS还是有差就是了
在5人以上维护的专案中用了TS绝对对开发速度和维护性有显著的帮助
光是在obj后面.一下就会跑出各种method和argument/return type
就不知道能避免多少低级错误和省下查文件翻code的时间了
所以说用TS会拖慢开发速度的人
我真的不知道他是在做什么神奇的专案需要用到诸多JS的神奇特性
相关的webpack config也只要设定一次, 何乐而不为呢
当然你可以说, 只要平常规范足够好, 大家团队意识够强
加上每个人记忆力超凡, 写过的每个function是做什么的都不会忘
每个人都是完美的JS programmer不会踩到一些不该踩的坑
那当然用JS也不会有太大问题
但我们都知道,
人 是一定会犯错的
的确, TS不能解决所有问题, 但要把这锅推给TS就有点诡异了
这个逻辑有点像：“反正用了也只是从30分到60分, TS真粪”
TS本来就是以尽量不破坏JS原有特性下改进JS的可读性
拿any来说, 敝公司的tsconfig中是有设定nonImplicitAny
新写的code中要用上any也必须给reviewer足够好的理由
在prototype偷塞东西这种事情也是没事不会做
除了一些很底层的模组, 例如支援mixin之类的
不要因一时贪图方便造成后续难以维护
我认同大大说的, 的确没有办法控制整个世界照我们想要的规矩走
但这不是我们不能在力所能及的范围内做到最好的借口