@MarkLeeyun share 一下我的组合键：
capslock remap 到 ctrl
ctrl + hjkl = 上下左右
ctrl + fb = pageup / pagedown
ctrl + backspace = delete
fn+1..0 = f1...10 // 确实用的少

以上基于 macOS，配套上 karabinder 很顺滑。windows 上差不多。

肌肉记忆培养起来了就舒服了。

这样高效的打字习惯带来一个问题：需要全换成 hhkb 的键盘！
哈哈，又给自己买 hhkb 键盘的借口。。。家里键盘太多了。。。

@MarkLeeyun 没呀，很少用。fn+12345 也不是不能接受的。。。。吧？

给几个 ts 好用的例子，供楼主参考：
1. 有了 ts，你基本可以大大降低对 API 文档依赖程度。以往像 lodash / ant-design 你要一直打开个文档去看 API 参数的。有了 ts 之后，看看 ts 定义，基本也差不多。但事实上这能带来非常大的开发效率提升！

2. 更进一步，ts 还能减少前后端接口联调成本：如果后端接口用 thrift / protobuf / swagger / openapi 等等 idl 协议制定的，那么可直接从 idl 转成一个 ts 的 library 。你调后端接口的时候，少一个参数，直接在 vscode 里就给你提示了：不行。这个有时候甚至要比后端同学给提供一个联调环境还要靠谱。

3. JS 项目非常常见的一个 case：一个 options，从最顶层一路向下传递很多层。传的过程中还有可能出现有的地方是加一些，有的减少一些。你看到这个 options 的时候很无力，你要向上翻无数层才能找到这个东西的结构。脑容量有限，装这些东西它就不划算。

4. 团队需要规范，而 ts 能提供更多、更细致的约束。很多水友都提了，我就不展开了。

5. 对于前端个人成长有收益。并不是所有的前端同学都是科班出身，一路从 C/C++/Java 学过到到 js 的。多学一点，没啥不好。

总的来说，对于单人（前端）的开发效率有提升，对于团队的效率有成倍提升。所以，如果我是前端团队的 leader，我会选择上车。

当然凡事皆有两面，ts 的接入也是有成本的。业务足够简单，没几行脚本的，确实也没这个必要。

飞书云文档

notion

@starcraft f 键为啥是刚需？

你怎么还不买个车，宝马多好啊，方便又快，为什么还是骑自行车上班？
嗯，是这么这个感觉。

求稳要生活质量，美团。要拼一拼，要快点成长，提前退休，抖音。

不同域名不行

@Tokin 整体组件库的文档站点都是粗糙的不行。。。明显没有 PM+UE 加持，浓郁的程序员风味：视觉和文案就这样吧，我尽力了(扑街)。。。

@k9982874 一般情况下，大家都直接写 `.san` 格式的组件呢，可以对标 `.vue`

@wlwood 这个是因为这套组件库是不支持 ie678 的，san 框架本身是支持 ie678 的。这个组件库是 Google 的 material 风格啊，支持到 ie6 还不如去死算了。

支持到 ie6，说得准确点应该是支持 ie678。这只是 san 的一个加分项而已。san 也是支持 chrome 等等现代浏览器的啊，大家不用过于担心。而且就算 san 支持了 ie678 这些老古董们，体积也只有 14KB，还是远小于 Vue/ React 的 。

虽然前端开发者们心理生理上都需要淘汰 ie678，但是我们也不得不承认仍然有一些站点『被迫』需要支持 ie678。目前根据 http://tongji.baidu.com/data/browser 给出的数据来看，ie78 就是 pc 流量的 10% 左右，ie6 基于上已经狗带了。这样来看，这些流量很可能也就是 pc 用户群体 /收入的 10%。直接放弃流量这种事情老板肯定是不乐见的，这时候说什么社区责任感什么都是 shit。无论是 Vue 还是 React，都没办法跑了，而用 san 至少你的 js/组件还能用啊！只是兼容一下 css，还省力不少的。

对于以移动流量 /『高端用户』为主目标用户人群的站点来讲，这个兼容 ie678 这个特性直接忽略就好了，功能 /易用性 /性能上也都不会差。如果讲性能，浏览器渲染也好，服务端预渲染也罢，san 也是遥遥领先。https://baidu.github.io/san/ 大家可以自己看。

现在还有利率 9 折？？？(⊙…⊙)

@lasse 同楼主的报错。。。
可是你是怎么把 dns 设置成 8.8.8.8 的。。。？

如果跨域了，chrome 是会先发个 options 问问能不能跨域的

LZ，现在你可以在 js 里边这么写了：

let connection= await client.getConnection();
data1=await connection.query("SELECT count(1) FROM T_User");
data2=await connection.query("SELECT count(1) FROM T_Book");

如果 data1 和 data2 没有啥前后依赖，你可以非常容易地做成并发 io：

let connection= await client.getConnection();
let [data1, data2] = await Promise.all([
connection.query("SELECT count(1) FROM T_User"),
connection.query("SELECT count(1) FROM T_Book")
]);

是不是和 Java 一样好写了。。。

其实工作久了你就发现很多时候并没有那么多的岗位限制。

比如突然有一天要做一个新网站，需要你把后端也做了；或者有一天你要做一个没有 UE 支持的后台系统；再或者有一天你想做个手机应用，那可能用 hybrid 或者 ReactNative 之类的东西也能凑合着先糊上。再或者你想做一个创新项目，后端、UE 都没有，连 PM 都是你自己。

我们常见的是前端小哥自称自己是全栈，而不是其他工种。讲道理，能把这些都做个 6-8 分的人，最有可能的人也就是这一波人了：最贴近用户，有基础的设计能力，有基础的后端开发能力，有基础的界面开发能力。

别把自己的思路固定在一个工种上，那可能就有更多的可玩性，心情也会好很多。

我们是工程师，我们是解决问题的人，我们是创建新世界的人。