unpkg.com 上那么多包，你随便选一个得到地址，架设你刚好选的就是 element-ui，接下来不就和正常加载 element-ui 一个过程了？

@duanzs #15 这个不重要呀，你需要的只是一个包的地址而已。我提 element-ui 和 vue-router 是为了引入具体场景来强调「异步加载」这个事儿，是不是 element-ui 不是问题的重点。

@duanzs #8 我说的就是「动态引入而无需重新打包发布」啊。

Vue 动态添加应用能力就是靠 Vue.use( )（以及相关的 Vue.mixin( )、Vue.component( )、Vue.directive( ) 等），接受的参数就是一个 Plain JS Object，那么你的问题就变成「如何在不重新编译引用者的情况下获得这个 Plain JS Object 」。最简单的，如楼上所说用 RequireJS，或者自己实现一个简单的异步模块加载器（动态添加 <script>，用全局函数得到模块内容），只要目标模块地址可以在运行时确定，模块引用者（主业务应用）就不需要重新编译和发布，目标模块暴露一个 install 方法传给 Vue.use( ) 去调用，就完事了。

我举 element-ui 和 vue-router 的例子，是因为它们也是这么做的。

@duanzs #5 不要先入为主觉得 element-ui 就是个组件库所以没有参考性，其实大家的本质都是一样的，无非是动态注册的东西不一样而已。

@duanzs #5 那好，Vue Router，这个不是样式库吧，要方法有方法，要组件有组件，你可以看看它是怎么做的。

是啊，element-ui 和业务应用的项目也是分开的啊，如果 element-ui 的引用方式是 CDN （ HTTP 链接），人家更新也不需要你重新发布业务应用啊

这不就是各种 Vue 组件库的效果？

活用 Vue.use()、Vue.component()、<component :is="?">

其实，就算是前端，本质的东西也没咋变。当然各种 Web 规范确实在演进，也带来了不少新东西，但远没到「学不动跟不上」的程度。

变的一直是工具。就好像以前做菜切丝只用刀，现在有了刨丝器，不兴用刀了，你就不知道做这菜需要刨丝了？

@manyfreebug #6
「子组件要是能直接使用父组件里的数据那多好」
「子组件要是能直接使用祖父组件里的数据那多好」
……
「子组件要是能直接使用所有组件里的数据那多好」

这样的结果就是，状态集中于某个组件，或无序地分散在多个组件，从而失去了组件化的意义。

当然讲究状态分层就会带来一定的访问障碍，这是难以避免的副作用。（所以 Vue 3 的 Hooks 好啊！）

等 PB 版再稳定些……

其他的都很好，就是 reactive wrapper 带来的 .value 略蛋疼

我感觉也不是 Windows 7 Aero 多好，而是 Windows 10 透明太糟糕（现在在慢慢找回去）

这就是为什么建议 JS 字符串用单引号包裹的原因（

ENTRYPOINT

require(...) 返回目标模块的导出值（也就是 module.exports ）。如果这个值是个包含 path 属性的对象，自然也就可以直接 .path 访问这个属性。

不要想多，require() 只是一个函数调用，而已。同理，如果这个模块的导出值是个函数，也就可以直接 require(...)() 立刻调用那个导出值。

如果让组件 export default 一个函数（而不是一个 plain object ），由这个函数承载 setup() 的功能，并返回一个类似 Component Options 的东西让它看起来像 Vue 2.x 的写法，大家还会有这么大的抵触吗？

Duet Display 刚出不久就买了，然后每隔一段时间想用就给我出幺蛾子，要么连上设备闪屏，要么程序直接崩溃，macOS 和 Windows 都一样。Duet Display 是我迄今为止买的最坑的软件了……

emmm，网易云音乐的界面渲染逻辑出 bug 了？

曾经这么做过，最后感觉也没啥问题，虽然当时的需求还是比较简单。至于接口返回内容，人家就是那样设计 API 的，还能咋办，最多服务端封装一层。