Quick question - how does the memoized DOM compare with no-virtual-dom-at-all approach of something like Svelte?
This lets you choose from multiple frameworks - comparing svelte against a few react variations, what I saw was that svelte was always fastest, but usually by a factor less than 2 (any react was 1.x times slower than the svelte).
The imba vs react numbers (from the article at https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...) shows a 30-40x speed difference.
And when you benchmark the speed of creating 10000 dom elements in an instant, less than 5% of the time should really be spent inside the framework one is supposed to test.
I stand by my claim in the mentioned article that tiny changes to a larger dom tree is a far better indicator of real world performance than anything else. Here Imba is really orders of magnitudes faster than react.
The last time I tested it, Imba was more than 10x faster than Svelte as well, but I'm not proficient enough in Svelte to claim that as a fact, and I have tremendous respect for Rich Harris and everything he's done with Svelte and other libraries.
FWIW, my initial impression of imba is that it's very impressive. I do think you rightly point out that, at this point, it may still be hard to leave larger ecosystems of react/vue/etc. DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years - the data size and audience and app space just don't really call for it. However... as my needs change, imba will be something I'll revisit. Thank you.
Maybe you're the exception among your peers or something, but I'd wager you're wrong. Benchmark or no benchmark, imba.io and the site for Scrimba are way snappy. In contrast, when I find myself having to derp around on a landing page or a UI made with React or contemporary frameworks, I can feel the bloat. Is it possible that being elbow deep in this stuff has dulled your senses?
I was just saying that for the majority of LOB apps I'm working on, whether a table of 2000 entries renders in .2 seconds or .3 seconds has no meaningful impact on the client projects I'm working on. Even though it's a 50% slowdown, or 33% speed up, depending on how you measure, that speed difference has no impact on these projects. If we got up to 20000 entries, and we were hitting 2sec vs 3sec, that might be noticeable and something to address.
And I'm not sure where you got that I got that you were saying that.
What I am saying is a direct challenge to what you wrote—no need to repeat yourself. I'm saying, positively, that the common standards in React projects produce bloat that is perceptible—in cases I had in mind, FWIW, that are even more trivial/lightweight, by comparison, than the example of 2000 entries you're relating here.
That you consider a threshold on the order of 2 seconds as beginning to be worthy of something that might need to be addressed is significant. It reveals a fundamental difference in our expectations of software. That "no impact" 0.3 seconds figure is already itself eons in CPU time.
(This isn't generic anti-JS, anti-Web sentiment, by the way. In the early days of developer.mozilla.org—up until 2008 or so—I poured a lot of effort working on the JS documentation to make sure high quality docs would be available to a wide audience, so that even more people might pick up JS, which wasn't taken very seriously at the time. That's also, though, why I bristle at the state of React and frontend development—it has sowed the idea that JS, or maybe just software in general, has to be inherently slow and bloated. The average modern Web project on modern mid-range hardware is more top-heavy and perceptibly less snappy than the Electron-style applications like Netscape, Firefox, etc. from 15 years ago, which ran unJITted on sub-Ghz machines.)
That.
Yes, it's eons. I get that. But the time/effort required to make modifications to be faster isn't something that my some of my clients - with limited budgets - are asking for.
Some are, and they care about speed. Typically there's lower hanging fruit in server side query optimization, reduced payload sizes, etc. But I'm sure you already know that.
I agree with most of your closing paragraph too, btw.
Are the two strategies as similar as they sound, or am I misunderstanding something?
On benchmarking: I went through the same concerns and ended up building a little benchmarking tool for a simple reactive UI library I'm working on. It's not super user-friendly yet but doing a good job of profiling tasks.
You can write custom benchmarks by clearly separating pre-setup work than relying on ready-made benchmarks (a bit of a pain initially, but helps a lot to fine-tune at unit-level going forward).
It uses Chrome DevTools Protocol(CDP) through Puppeteer and allows to analyze execution durations separately (Scripting, Layout, Paint, etc). Plus, it saves raw JSON profiling data, so you could import & examine it visually on DevTools Performance Tab's Timeline.
Think it will be helpful: https://github.com/dumijay/pfreak This is how the results look like: https://caldom.org/benchmark/
As described in your second link, that benchmark is timing something a bit different – and we don't know how well Svelte would perform on it (I'm guessing fairly similarly, since the overall approach seems similar. But there's no way to know without measuring.)
Some "frameworks" achieve good numbers there by being utterly unusable in real life, others miss the spirit of the benchmark completely (e.g. submitting a non-keyed implementation as keyed thereby gaining an unfair/misleading advantage), and as somebee said, the benchmark itself largely measures repaint time (and does so in a less than ideal way, by using setTimeout macro queue as a proxy for repaint time measurement, in band, instead of instrumenting performance via CDP). It lacks rigor in many ways (the most blatant was that initially it considered keyed and non-keyed implementations on par, but there are other issues such as putting a lot of weight into DOM creation compared to e.g. array diff, or as somebee said, not measuring low repaint load diffs)
IMHO, it only has two things going for it: a) it has a lot of frameworks listed b) it does at least attempt to measure repaint times unlike other benchmarks that only measure JS time (which has become somewhat irrelevant since V8 et al now offload repaints out of the JS thread)