虚拟DOM真的快么
现代前端框架即MVVM框架有什么特性，脑子里第一时间想到的会是状态响应式和虚拟DOM。状态响应式改变了前端在业务开发上的逻辑，让开发者不必于去纠结我该为了做这个事去操作哪些DOM元素，而说起虚拟DOM，给出的理由都是减少DOM操作的次数，提高渲染速度，但是果真如此么？ 我们知道，虚拟DOM的实现原理是把DOM元素变成一个js对象，然后通过diff算法来对比前后两个js对象，最后根据差异来更新DOM，这比全量的操作DOM快很多，那么我们能不能跳过虚拟DOM这一步，直接去更新DOM的差异呢（vue使用模板进行编译，那么在遇到差异时进行靶向更新也是个方案），毕竟虚拟DOM额外增加了js的开销。 答案是可以的，Svelte就是这么做的，16年底写的Svelte也已经更新了八年多了，目前在Github上有80k的star，可见其受众的广泛。
为什么要有虚拟DOM，现有的虚拟DOM能不能去掉
目前还在实验阶段的Vue Vapor已经抛弃了虚拟DOM，而对于较早的实现了虚拟DOM的React来说应该没这个可能了，React更倾向于去做设计以兼容现有的情况，类似的还有为什么React需要花大量时间去做一个Concurrent Mode，而Vue则放弃了这一实现。 在去掉虚拟DOM之后直接操作DOM，就不需要前端框架再提供繁重的运行时了（新的运行时只需要处理状态、事件和生命周期），而React的运行时则会大很多。在React创建之初有一个很流行的思想是write once, run anywhere，那么用js写的代码怎么在各种环境比如app、小程序里运行呢，就得靠各种环境所对应的运行时了。 还有一点是，React里js和DOM混合书写的实现也会比静态模板更加难以处理（甚至是处理不了？）。 从开发一个通用的前端框架的角度来说，把节点渲染成真实的元素的运行时不能放弃，那么虚拟DOM也就必不可少了。可能有人会问，只专精一项行不行？可以是可以，但是像Java或者WebAssembly这样写一遍可以运行在各个环境的方案无疑是具有巨大市场的。
是否使用虚拟DOM对前端框架的技术选型的影响
没什么影响，一个框架是否应该被采用要考虑框架的性能、上手程度和可维护性、技术社区和产品生态、公司已有技术栈等因素。 在我看来，虚拟DOM是以牺牲一小部分性能为代价，换取更易扩展的代码。
