Arc 的侧边栏非常好；
Easel 目测也不错。

@Dvel +1

首先因为不谈用户量，仅从开源设区的规模和参与度来说，React 是要比 Vue 好非常多的，比如长列表渲染、拖拽之类的，在 React 社区中已经有很多高质量的组件可以选用了，你只需要在其基础之上封装自己的业务组件即可，但在 Vue 中，要差很多。

@tutustream 这是脑子有多抽抽才会出这种手机？

唔，拼音的内容大多都是有时效性的，而且时效很短。

挑选适合你的应用场景的应用层协议，然后去找 java 语言的实现模块即可。

你们真的有时间，就每周拉一会议室，当面 review 代码。

唔，其实比较好的是本地写，然后同步到服务器上。

@zhbhun 其实是可以的，只要模块加载器根据 package.json 中的版本声明并结合 package-lock.json 中的版本信息，就可以处理 A 和 B 模块分别依赖 C 模块的不同版本的问题。

首先通常一行不应该这么长，否则读代码的时候就像读文章中的一个很长的句子，会比较费劲。比如古龙的小说对比金庸的。

不过写地好的话，倒也不是问题，就像金庸小说也不会真的有人明显感觉读着累。

但这段代码有一个更为麻烦的问题，在于它有一个四层深度的嵌套调用，通常嵌套调用的代码在阅读的时候需要来回查看才能梳理清楚。而写在一行里，会加重来回查看的难度。

所以最好能够把嵌套调用改写成链式调用（或顺序调用）。
如果真的不好改，应该换行。

之前做过一些简单地测试，在单词数量较多，文件名较长的时候，可读性由高到低：蛇式命名风格（单词全小写并使用下划线分隔） > 串式命名风格（单词全小写并使用中划线分隔） > 驼峰式命名风格（单词首字母大写并没有分隔符）。

唔，开饭店，尤其是这种小众饭馆，形式倒不是必要因素，口味才是。

接口设计定好规范，接口数据只依据业务需求来定，不要耦合服务器端的具体实现。

哎，年轻人，换个好看的壳就兴奋成这样。

我这一年半的，88%

其实你需要的只是一个支持 yaml 语法检查的编辑器，甚至它可以自动帮你修复一些语法格式上的问题。