如果说是框架的话，就看对框架的定义是什么了。
个人认为：
vue 是框架，配套的是特有的对 WEB 系统的抽象以及一系列搭建 WEB 系统的思想和方法论；
jQuery 是库，提供了方便处理 DOM、方便调用常规算法的工具。

理论上来说，一个项目既可以用 jQuery 来写，也可以用 vue 来写，也可以什么都不用原生 JS 来写，只不过针对不同项目的情况，各自的实现成本不同，而这种成本并不是绝对的。

两者的功能既有交集，又有各自特有的，看具体的项目需求和采用的架构思想，决定究竟适合使用什么技术乃至如何搭配。

不方便的地方可以总结为如下几条定律：

不是自己攒的机器尽量不要用 linux。
使用开源软件尽量用 Linux。
苹果电脑干啥都最好用 macos。
玩游戏还是 Windows 爽。

当然极客可以忽略。

两个显示器看怎么放，如果左右的话，容易造成一侧颈椎酸痛。
最符合人体工学的方法是目视正前方。

长时间写代码，因为颈椎健康的问题基本上那个都会用外接显示器，而且还需要垫高到人体工学最适角度。
至于 15 寸还是 13 寸，如果是 MBP 的话完全是因为性能参数，如果平时用外接显示器，性能一样的话我会选更加轻薄的 13 寸，便携性好，开会、上下班等不会累赘。

这个帖子有些标题党。

ES6 是 ECMA-262 6th Edition，如果后续有修改的话不知道是直接给 ES6 打补丁还是在 ES2018 做修订案。
不过这一部分是非规范性的，只是一些建议，最终什么趋势还说不准。

个人喜欢加分号，觉得在 ES 的语言特性方面严格使用分号是一种高可靠性方案；
不过确实此前 ES 的语法情况，末尾分号对语言、引擎和开发程序的设计和实现都没什么实质影响，末尾加不加分号全凭习惯；一些 JS 大牛也认为分号的意义太弱而推崇末尾无分号，综合来看，这确实是合理的。

可能在 ES 的未来发展方面，末尾分号对于语言、引擎的设计和实现造成了影响，未来 ES 对末尾分号的依赖有可能会逐渐增强。以前只需要注意几个特殊情况下特殊处理（如 standardjs 的方案），以保证末尾无分号的风格具备高可靠性；但未来随着新特性的增加，有可能这类特殊情况会越来越多，多到末尾无分号的方案失去其便利优势，到那个时候综合对比可能末尾写分号的代码风格会处于便利性和可靠性的优势地位。

当然都是后话了。

曾经认真研究过，个人评估是 16:10 更适合竖屏阅读。

@des 我在想可能 ECMA-262 的标准制定流程是完全强依赖社区需求的，所以各家引擎不好为了自己一家的利益或者喜好而随意做草案，反而社区需求以及市场压力会制约各家引擎永远朝着最适应社区需求的方向制定草案。
另一方面也可能是因为 TC39 太勤快了，近几年更新标准的频率很高，使得各家引擎的实现标准不至于会产生太大的区别。

@des ECMA-262 没怎么遇到这个问题，因为实际上各家引擎在实现草案的时候都是互相商量和参考的，最终总会殊途同归，具体可以看一下 ECMAScript 近几年的发展就能看出来。

@oness 问号以及后面的结构浏览器通常称为 Search，服务端通常称为 Query，这部分是会传到服务器的。而井号以及后面的部分浏览器端是称为 Hash，是不会传到服务器上的。
通常单页面应用的路由及页面间的传参不需要服务器处理，也就不需要传给服务器。
最重要的一点是如果在 Search 中传参整个页面是会刷新的，而单页面应用的设计就是想要避免用户在使用过程中页面刷新。Hash 的修改通常就不会刷新。

三年前就很多网站这么用了吧。
单页面应用的兴起应该是有大部分的案例都是用#+path 做前端路由的。
话说我还是喜欢 ECMA-262 的哲学，先让社区用起来再归入标准，毕竟技术也好标准也好都是为需求服务的。

干了 5 年程序员...
所以楼主是测试？

Node：怪我咯。
动态语言：什么鬼。
我：圣战贴，吃瓜~

回复的话基本两种目标：
1. 让员工内心接受实施上网行为管理是合理的。
2. 转移仇恨。

对于已经尝过过自由的甜头的人来说，永远不会满足于受限制的环境，所以第一种目标几乎不可能达到。
所以一般有点心机的人都会选择第二种目标，将仇恨转移到领导层或其他部门，为自己开脱责任。更加圆滑的人可以让抱怨的员工觉得你和他其实是统一战线的。

先抛开员工上社交网站是否真的是为了找灵感，设计师确实需要持续充电，看到其他人独特的设计思路也能让自己拓宽一些思路。

员工工作时间划水的情况比较严重的话，不管怎么说在管理上肯定是存在问题的，而管理层希望简单通过上网行为管理来解决问题，本身是偷懒和不负责任的做法。就好像孩子学习成绩不好，家长并不帮助孩子寻找和解决问题，而是报了个辅导班，妄图将自己本来应该承担的责任扔给辅导班老师，效果如何大家都清楚。

个人以为过程导向或形式导向的企业来说没啥好办法，除非把行为管理设施全干掉，不定期突击抽查工作状态，然后将上班划水程度考虑到绩效情况中。

我们公司是目标驱动，结果导向。
为工作任务设定目标，开始前由负责人评估工作量，然后实施人员按照要求的时间进行实施，过程不关心，但不要为他人制造麻烦，最终完成工作任务的时候也要求任务结果能达成预设目标，按照达成目标的程度量化绩效。
高效的人需要承担更多的工作量并享受更高的薪资待遇，良性循环。

Pixel 2 网上经常曝出新的问题，严重的有的机子忘记刷系统就出厂了。。。建议再好好研究一下？毕竟海淘发现严重的问题退换货比较麻烦。
今年比较看好三星 8 系，因为之前 Note7 炸机事件，今年三星割闪存的韭菜准备了大量财力卯足劲做旗舰机，几个月来 S8 和 Note8 在网上的评价都很好，也没见出什么问题，我有朋友入了国行的 S8 和 Note8，本地化做得非常棒，而且国行内置 Google 框架(需要自己去 apkmirror 上下 store 装上)。如果说之前三星的产品马马虎虎，今年为了重振品牌的这一班车还是值得搭一搭的。
我个人用 Pixel 1，到现在各部分功能仍然好用，只是 Google 的原生系统没有对中国特色的应用环境做优化，从始到终都要 root+icebox，勉强维持续航时间。以前为了纯净、为了用 Google 服务，倾向于选择 Google 原生系统；现在我想是时候说用一个不流氓还自带 Google 框架的国行系统比 Google 原生系统好用了。

Node8 支持完整的 ES2016(ES7)语法（除了部分已有的本来就很好用没必要替换的特性），部分 ES2017 语法，因为本身 ES 标准就是先应用后标准化的，所以新的特性你会见到，但是通常在 Beta 之前不建议用于正式生产(Beta 的时候就已经很稳定了，基本就剩下走流程出 ES 标准了，编入 ES 标准再改成正式版特性)。
Express 我没有用过最新版，但是作为应用最广泛的 Node.js WEB 框架应该也支持得比即时吧，RTFM，我知道 Koa2 是完全支持 promise 和 async 的。

不管你想用 Express 还是 Koa 还是其他的，直接到官方文档里看教程就可以，教程的 Demo 很典型，基本以后写程序都是这个样式，了解一个 WEB 服务基本的元素和架构，然后再根据具体的项目要求来设计，不同的项目可能思路结构甚至代码风格都完全不一样。