老手无所谓，但默认 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 才是王道