常年三个系统，Windows Debian MacOS 来回切，没有一家独大的道理，每个系统都有优秀到离不开的软件。
开发软件，各个平台都有自己的用户受众群体，比如你想做一个给普通人用的小工具，那么你不可能用 Linux 开发，Windows 用户才是你的受众群体，当然 Mac 的用户量也不少。
一个软件多个平台测试过才算是合格的。

我移动 4G 一直正常

建议先看官网文档。把文档中的示例都看懂，语言就学的差不多了。学着官方文档里的风格去写，可以适当发展自己的风格。
亲亲，这边建议您写代码的时候把 Ctrl 键或 Command 键扣掉哦～
GitHub 之类的上面的代码都是有作者自己风格的，不一定代表官方推荐，不一定是好的。

1 Google 是商业公司，不是慈善机构，广告是他们收入来源之一
2 在你看到 Google 有广告就觉得不可思议，破坏了你心目中光辉形象的时候，是不是要自己反思一下双膝已经离不开地面了？ Google 也是要挣钱吃饭的！投广告赚钱没有什么不妥。
3 百度因为医药广告害人之后，成为了反面教材，而当时有人指出 Google 上也存在医药广告，但是 Google 上面的医药广告不是给钱就能发的，要审核资质证明的，所以结论是 Google 的广告相比百度成为了正面教材。这件事听听就好，Google 的广告至少不会害死人。

老手无所谓，但默认 root 用户会让新手习惯所有操作都直接跑，以至于到非 root 环境就不知所措了。
其次，除了非常底层的操作服务以外，没什么业务服务需要 root 权限的，都是非 root 能启动的。比如监听端口 80、443 这些低端口的问题，也是有非 root 的解决方案的，只不过大家习惯了碰到问题直接 sudo ……
以 root 去启动服务，等哪天中个挖矿病毒，就该后悔了……然后去投诉他们为啥要默认 root 用户？
默认非 root 用户，出问题了你也怪不到他们身上，毕竟没给 root 权限你强行获取，那是你自己的问题。

原生的 Web Components 会是官方支持的未来，只是现在 HTML Imports 被弃用暂时替代解决方案 ES Module 还不太成熟（ ES Module 已经比较成熟，但是应用在 HTML Imports 相关方向时暂时还没有比较好的实践，得继续观望）。
而 React VUE Angular 这些第三方框架的必然会在未来 Web Components 成熟后采纳一些原生的解决方案。
比如样式隔离问题，现在三大框架的解决方案只有两种，一种是给样式 class 类名加 hash，一种是加前缀，各个子组件不使用 id，以保证在复杂庞大的页面下样式互相不冲突，带来的问题就是样式类名又臭又长，或是太过随机。而原生的 Web Components 则在浏览器层面直接对样式进行隔离，不同子组件之间样式 class、id 都可以冲突而不相互受影响。
还有就是未来一定会出现越来越多的基于 Web Components 的第三方框架（目前貌似就只有 Google 的 Polymer 做了好几年了比较稳定），YouTube 就是采用的 Polymer 框架，根据浏览器支持情况选择 Polyfill，目前看起来已经很成熟了。
---
前两天在看 Chrome 弃用 Web Components v0 的讨论，感觉国外在生产实践中应用这个技术的已经有很多了，以至于 Chrome 必须推迟删除 API 的决定。

+1，昨天我也这样，今天好了

我的理解：动画的本身应该是在耗时较长的动作用来做补充的。
如果网速较慢，延迟较高，那么在用户点击提交按钮后界面会有较长时间的“无响应”，这个时候使用动画来进行过渡就会比较好。
但如果系统速度足够快，那么强行显示动画也会有点多余，甚至会令用户反感，毕竟不管你动画做的多么炫酷，“加载中”的状态总是令人讨厌的。明明我的电脑配置非常高，网速也非常快，为什么就是得不到无缝的操作体验？
如果是转场动画，也就是一个界面切换到另一个界面，在这个过程中添加一个过渡效果也是可以的，但是动画要做到非常流畅并且动画时间越短越好，给用户一个反馈，但是还没等用户反应过来，动画就结束了。如果这个转场时间过长，那么就会给用户带来明显的延迟感，将原本应该直接打开的页面愣是改成了需要“加载中”的页面。

反正我是直接内置库直接用，根据需要自己改

webComponents 才是王道