编程与软件工程svelte.dev编辑精选
虚拟 DOM 纯属额外开销（2018）
Virtual DOM is pure overhead (2018)
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Svelte 作者 Rich Harris 的争议性文章，主张虚拟 DOM 并非性能优势，而是一种纯粹的开销：既然模板已经标明了哪些部分会变化，框架完全可以通过编译时分析直接更新 DOM，省去运行时 diff。文章引发了对 React 虚拟 DOM 价值与编译型框架取舍的长期讨论。
为什么经久不衰：它挑战了前端框架的核心假设，评论区的正反交锋（历史背景、编译取舍、真实场景性能）比文章本身更有价值，至今仍是理解各框架设计哲学差异的经典切入点。
HN 评论精选
虚拟 DOM 的历史价值在于用声明式状态管理取代把 DOM 当状态存储的坏习惯，文章忽略了这一背景。
这篇文章和很多评论都忘了虚拟 DOM 出现时 DOM 操作的典型做法：开发者常把 DOM 当状态存储，用 jQuery 反复搜索节点、检查状态再更新。React 的真正功劳是改变了前端状态管理的文化——说 VDOM 比真实 DOM 快，指的是这种对比，而文章恰恰回避了这一点。
oraphalous查看英文原文
I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child elements that need updating - inspecting the DOM in various ways so as to determine the component's current state. If your component needed to affect components higher up, or sibling to the current instance - then your application is often doing a search of the DOM to find the nodes.. and yes if you architect things well then you could avoid a lot of these - but let's face it, front end developers weren't typically renown for their application architecture skills. In short - the DOM was often used to store state. And this just isn't a very efficient approach. This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail. As far as I'm aware React and its VDOM approach was the framework that deserves the credit for changing the culture of how we thought about state management on the frontend. That newer frameworks have been able to build upon this core insight - in ways that are even more efficient than the VDOM approach is great - but they should pay homage to that original insight and change in perspective React made possible. I feel this article and many of the comments here so far - fail to do that - and worse, seem to be trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.
React 的核心价值是组件模型而非虚拟 DOM；Svelte 的编译时方案是一种需要权衡的取舍。
首先，只因为虚拟 DOM 而用 React 的人没抓住重点，React 真正的优势是函数式、可组合的组件设计。其次，React 几乎不设限，编译只需 JSX 转 JS，简单到可以手写；而 Svelte 依赖重度编译，源码和浏览器里运行的代码之间有大量非平凡的转换。这是开发者应该了解的重大取舍。
Lowkeyloki查看英文原文
First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library, all things considered. The only compilation step necessary is JSX to Javascript. JSX maps pretty directly to React's API. This means compilation is pretty simple. So much so that you can do it by hand really easily if you really wanted to. Svelte, on the other hand, is pretty compilation-heavy. There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. But if you are comfortable with that trade-off, that's perfectly fine. It is worth being aware of it, though.
应用变大后虚拟 DOM diff 的开销微不足道，React 的调度能力对实际体验更有价值。
Dan Abramov 有一段很有说服力的论述：时间切片让 React 在运行你的代码时保持响应——你的代码不只是 DOM 更新，还有组件里的任意 JS 逻辑，没有框架能魔法般加速任意代码。以我的经验，应用变大后，DOM 协调的开销相比业务逻辑可以忽略不计。
Lx1oG-AWb6h_ZG0查看英文原文
Dan Abramov has a great thread about this here: https://mobile.twitter.com/dan_abramov/status/1120971795425832961. In particular, I find this argument really persuasive: > Time slicing keeps React responsive while it runs your code. Your code isn’t just DOM updates or “diffing”. It’s any JS logic you do in your components! Sometimes you gotta calculate things. No framework can magically speed up arbitrary code. In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation.
文章用夸张的微基准论据和傲慢语气否定虚拟 DOM，缺乏量化且脱离真实场景，说服力不足。
说虚拟 DOM 是'纯粹开销'却不量化到底开销多大，是推理上的灾难性失败。现实世界不是合成基准测试，大多数应用有比每秒组件更新次数更重要的问题，而 React 实践中完全够用。把虚拟 DOM 称为'梗'和'稻草人'，这种夸张加傲慢的语气让人想起 G-WAN 式的微基准营销——这不是推销产品的好方式。
jchw查看英文原文
Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead. Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here. In practice. So Svelte has a lot to prove to get people to try to move. And this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” (while simultaneously admitting that plenty of frameworks were slower at the time.) That’s not going to work. That’s going to classify you as “insane person” to many people. It reminds me of the claims G-WAN made: over-exaggerations in a smarmy tone based on micro-benchmark wins. I’m not saying there’s anything wrong with Svelte. But, this is not how you sell something. React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. It delivered exactly that. And yet: > the alternative is to do something no-one actually does Somehow this article manages to contradict itself in pursuit of unnecessary smarminess. I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion. The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选