otato

米游社啥时候整个暗黑模式啊

@yunlongV 非要合理化的就是留档，传 ID 的话，对应的内容后面被人改了就很难掰扯清楚

提供单页面方案或者工程性的基础，这不跟我一个意思嘛
接下来不是跟你抬杠，只是有些问题你理解错了
首先真没 native 这个说法，你可能理解成那些跨平台 APP 方案了，那种方案的性能损耗一般来自框架和平台 API 的通信上，但 r/v 都是 js，跟原生 js 跑在同一个页面里，没那些损耗。
再就虚拟 DOM，我举个例子吧：
列表渲染 1234，要更新成 5234，性能最好肯定是直接 1 => 5，不过实际应用中你怎么知道 1 变了呢，要么不管他全量更新，要么自己去 diff 变化，但这增加了心智负担
虚拟 dom 就能做到，你就 list = 5234，他自动帮你算出来，只要把 1 更新成 5 就行了
这种简单场景可能全量更新也很快，可万一列表里面是个复杂一些的功能组件呢，有自己的状态和事件绑定，这些都要手动处理，可就保不住头发了
真的，作为一个摸到一些 jquery 时代尾巴的前端，这些框架其实降低了开发难度的。
不过发展到现在确实概念多了产生一些壁垒，这里再次建议尝试一下完整版的 vue，直接在页面里写模板，处理事件+双向绑定，什么组件、vuex 、router 通通没有，不用打包编译，引个 vue.js 就行，文档首页就在强调的渐进式框架，就是给你这种场景用的

你这个其实就是个路由嘛，或者说加载器，功能感觉够了，安心当个路由吧。

每个页面里面的逻辑简单的就写原生，稍微复杂一点的用 vue 完整版（带模板解析器的，直接就可以在页面里写不用 build ），或者其他什么框架，再复杂的还是得上前端那一套。

虚拟 DOM 的性能，就是在 js 里对比一下，不操作 dom，不占多少时间，最后 diff 算法算出来的实际 DOM 操作，基本就是最优解。现在直接大段 innerHTML 确实性能最好，但是再细的粒度呢，要么使用者手动去操作 dom，要么你实现个中间层，可是，这个中间层，不也就会是个虚拟 DOM 么 23333

事件系统建议就用在页面间传数据或者跟主程序通讯，发布 /订阅模式适合做底层不适合在业务中全面使用。
早期有框架使用，比如 riot.js ，我用过一次，初始简单直接，但是一旦事件数量上去甚至开始事件联动之后，混乱程度指数上升。当然我当时确实也挺菜的，不过估计现在写也不会好多少。

如果不靠人工能分辨对错，为什么还需要你这个系统，直接上线分辨系统啊

你们公司是怎么做到前端不加班而后端加班的啊

好像搞错帖子了，不好意思。。

？ v2 能删帖么，刚才看回复不止这几个啊

虽然楼上已经贴出来官方建议小写的链接，不过本杠精还是找到了官方用大写的例子：
官博： https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d27d7d7e2
搜索 Webpack now by default supports