@Rwing coffee 是语法糖，但也因为这语法糖解决了很多痛点，也所以 es6 大部分新特性是借鉴 coffee 的。

而 js 的弱类型，是 js 的特性，而且在我们看来是 js 的优势，基于弱类型你的代码就会很灵活。然后 ts 就把这个特性覆盖成强类型了？？

@kop1989 你的想法绝大部分我是理解的，这个绝大部分是过程部分，比如因为 ts 火了，用的公司多，所以行业内 ts 空前发达，从员工角度来说，如果不掌握 ts，自己就没有市场
关键是我不理解的是起源部分，就是为啥 ts 会火，而不是 coffee 或者其他 js 高级语言火。。这个我没想明白~

@youxiachai emmmm，我们的话题在往另一个争论更大的话题上偏。。不过我还是忍不住要问一句
你肯定是用 windows 的吧，你不觉得 windows 用起来浑身难受么。。
因为孩子的关系，我已经实现了以前我跟别人说的那句，如果不是为了玩游戏，我可以一辈子不碰 windows 。。
我已经有半年没碰过 windows 了，因为实在是没时间玩游戏。。

@xarthur 我只是不明白为啥这么火~

@Rwing 我司现在正在做的一个后台系统，也是我从业十来年里看到的最复杂的后台系统，我们用 coffee 写的，没有任何问题啊，所以 ts 的优势到底在哪呢。。

@youxiachai 说到这个，我就还有一个疑问，为啥感觉 coffee 用的人越来越少。。
coffee 从 1 到 2 我一直都在用，个人认为 js 的高级语言里，就没有比 coffee 更好用的了（注：本人 java 出身。。

来来来，咱们聊聊两点：
1. 缩进。A 需要视觉上缩进是 4 个字符距离，B 需要视觉上缩进是 2 个字符距离，C 需要视觉上缩进是 3 个字符距离。你们用空格来缩进的怎么处理？忽略个人需求，强制使用？
2. 格式化代码。你们疯了吧？习惯性格式化代码是个什么习惯，不怕被打死？每个人的编辑器都不一样，A 把代码提交了，B 拉下来改东西然后格式化了一下代码也 push 了，这时候 B 的这个 commit 文件对比的意义何在？很可能全篇都是改动，怎么对比？

@galikeoy 对于用户体验来说都是一样的，都是无感刷新登录状态

@rikka 这里我的建议是，什么接口就做什么接口应该做的事情，处理 token 就要用专门处理 token 的接口，而不是在业务逻辑接口上插一个系统级的数据，这样会让人有种很脏的感觉

比如你所说的场景，token 过期了，你发起一个业务逻辑的请求，服务器直接打回，响应了一个约定好的代表 token 过期的 code，前端接到这个响应并匹配了 code，就自动发起一个 refresh token 的请求
然后有两种情况：
1. 当新 token 正常响应了之后，前端自动发起之前的业务逻辑请求
2. 如果新 token 获取失败，前端直接踢到登录页

这样不是看起来很干净么？还是遵循那个原则：什么接口就做什么接口应该做的事情