I can't say it enough: "vdom" is not fast. It is slow.

The only *defensible* claim is that it isn't as slow as one might think given how much overhead it adds...but that doesn't make it competitive or good.
Why is vdom slow?

It does too much work.

Computing diffs through something like React's reconciliation algorithm is a clever way to avoid needing to have knowledge of the potential changes that can occur on either the JS or DOM side.

But it's correspondingly very expensive.
Reactive systems that constrain *either* how you update DOM (e.g. Lit's template system) *or* cabin the effects of JS side-effects (Svelte's "reactive declarations", FAST's Observables) deliver superior performance because they don't need to model + compare the whole world
Now, React and other vdom systems have ways of saying "don't diff me bro!", but they don't reduce the memory and GC overhead of diff management, and they're error prone.

But most importantly, they aren't the default. Which means the default is *SLOW*.
There are other ways that the toolchains that tend to come with React (hilariously, justified by performance concerns) tank startup and destroy the first best chance to make a good impression with users...but just know that the core is *also* slow.

By design.
Someone will inevitably slide into my DMs with DBMon whataboutism. *Sigh*.

Every framework can tune for hot paths (usually by getting back to NOT diffing). But the question is average costs across components built the usual way.
The problem of hot repaint loops is exotic and unusual.

Yes, it happens. Yes, perf matters there. But it's so rare as to be a special case.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Alex Russell

Alex Russell Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @slightlylate

20 Oct
Having looked pretty deeply at various blockchain tech stacks over the years, this thread seems dead on.

People are holding on to *the dream*, and the fact that the tech will impoverish millions, help destroy the one world we share, and fail to avoid aggregation is immaterial.
I can't stress enough just how transparently wrong the "decentralised" claims are should you care to look.

Not the dream of decentralisation (whatever that is), but the lived reality of all these systems. Bitcoin? Mostly traded through exchanges now. And they will be regulated.
"web3"? Well, you can't find anything...so you get alt-stack, slower, less capable versions of systems we already have:

Read 6 tweets
8 Oct
So @maxlynch hit me right in the feels with this one:

I have deep, deep regrets that I have not been able to convince browser makers to refuse to load 2.7MB of JS, critical path, served uncompressed.
Browser teams (the folks who work on UI) don't think of content as "their problem". For historical reasons, they care about TLS and that has helped them make common cause with security interests.
But no such enlightenment has occurred around performance...and in particular, perf so bad that it endangers accessibility.

Platform teams, meanwhile, focus on making the runtime faster, rather than building common cause between users on high-end and low-end devices.
Read 14 tweets
7 Oct

Might need to be off Twitter while @fugueish and @justinschuh *ahem* digest this press release.
Big reveal: it's Chromium!

But secure?
/me checks their website

*surely* they must be a description of how this thing improves sandboxing, allocators, control-flow hardening...something?


Read 7 tweets
11 Aug
F: is he saying "super moms"?
me: I think he is?
I don't know how @ErrataRob is dealing with this...the stuff on the live stream is *UNHINGED*.
@ErrataRob The sincere stupidity is arresting and terrifying in equal measure.
Read 7 tweets
10 Aug
Your shopping website is not an SPA.

I repeat: your shopping website is not an SPA.

Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.
Like, it *could* be an SPA, in the same sense that one *could* use a solid rocket booster to power one's car.
How do I know it's ridiculous to apply this much JS to the problem?

Because I helped build e-commerce sites with similar features (filtering, carts, etc.) that had to work on 4.0 browsers over 33.6 modems to WebTV boxes in 1999.
Read 6 tweets
16 Jul
"$120 smartphone being sold for $500" you say? Why yes, cheap Androids *are* my beat.

A quick 🧵 on the technical specs of the UMIDIGI A9 Pro (a.k.a. "Freedom Phone") and how it stacks up against vs. legit $500USD devices.
The chip inside is the 8-core MediaTek Helio P60 (a.k.a., MT6771). It was initially released in early *2018* and was not a competitive part even then:


By modern standards it's a pile of 💩; no device above ~$200 should use it.
Looking at the headline specs, this thing's a dog. There are 8 cores, but as with most Android devices, that's less than half the picture.

The *fast* cores (4 x A73's) are a design from *2016*:


The slow cores are 2012's A53:

Read 19 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!