otato's recent timeline updates
otato

otato

V2EX member #225092, joined on 2017-04-09 14:29:47 +08:00
otato's recent replies
记住一点,出了事,你和你同事互为满减卡
没有节度使我不认可
米游社啥时候整个暗黑模式啊
@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 ,我用过一次,初始简单直接,但是一旦事件数量上去甚至开始事件联动之后,混乱程度指数上升。当然我当时确实也挺菜的,不过估计现在写也不会好多少。
如果不靠人工能分辨对错,为什么还需要你这个系统,直接上线分辨系统啊
你们公司是怎么做到前端不加班而后端加班的啊
Apr 11, 2019
Replied to a topic by liman 酷工作 [深圳] 虾皮 Shopee 内推
好像搞错帖子了,不好意思。。
Apr 11, 2019
Replied to a topic by liman 酷工作 [深圳] 虾皮 Shopee 内推
欸? v2 能删帖么,刚才看回复不止这几个啊
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   891 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 20:19 · PVG 04:19 · LAX 13:19 · JFK 16:19
♥ Do have faith in what you're doing.