
Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA - pjmlp
https://mbasso.github.io/asm-dom/
======
austincheney
I wonder if they had chosen to compile to the standard DOM implementation if
there would still be a huge performance gain over the current execution speed?

DOM operations, in JavaScript, on Firefox already occur at near assembly speed
at billions of operations per second. Comparatively abstractions over the
native DOM implementation, in JavaScript, are many orders of magnitude slower.
While I understand this is a C++ application compiled to WASM it still begs
the question if this application is potentially sacrificing performance for a
more popular implementation such as the nonstandard JSX vDOM.

~~~
banachtarski
> DOM operations, in JavaScript, on Firefox already occur at near assembly
> speed at billions of operations per second

Call me skeptical

~~~
austincheney
You can see for yourself if you go to
[https://jsbench.github.io/](https://jsbench.github.io/)

Test

    
    
        document.getElementById("canvas");
    

against

    
    
        document.querySelector("#canvas");
    

On my really old desktop computer I am running about 800 million operations
per second in Firefox 74 on Windows 10. See what numbers you can get up to
with modern hardware or a different operating system.

~~~
blattimwind
I'm getting about 2.5 bn op/s, which suggests this is rather down to the JIT's
ability to elide microbenchmarking code.

Edit: Worth pointing out that the linked page runs on an eight year old
version of the "benchmarkjs" package, which is described as a robust
benchmarking package, but while the linked blog posts discusses some issues
with JS benchmarking, how to trick the JIT into actually still running your
NOPs is not discussed.

~~~
austincheney
You make a couple of assumptions and I am not sure they are correct.

1\. JIT's ability to elide microbenchmarking code

This can be easily debunked using a combination of DOM instructions and taking
note of how dramatically the ops/s count drops and then comparing that
difference in ops/s against the same difference from another browser like
Chrome. If both browsers report wildly different base numbers but similar
ratios then there is no cheating for micro-benchmarking numbers.

2\. Worth pointing out that the linked page runs on an eight year old version
of the "benchmarkjs" package

I found a different site that reports similar numbers so either they are using
the same old code or the numbers valid without regard for the old code.
[https://jsbench.me/](https://jsbench.me/)

~~~
blattimwind
> If both browsers report wildly different base numbers but similar ratios
> then there is no cheating for micro-benchmarking numbers.

I don't have a lot of experience with JS benchmarking, but for the JVM
microbenchmarking is genuinely difficult and relatively worthless because the
JIT is really good at killing off huge swaths of code if the results aren't
used and side effects aren't observed. And even if you do, it's not unusual
for it to optimize your code for the microbenchmark in a way that's not
directly applicable to production use.

Unless the benchmarking code around this does some transformations on the
source, I would expect a JIT (or an optimizing interpreter) to simply remove a
side-effect-free statement. I would certainly expect a state-of-the-art JIT
that's heavily bound to the DOM implementation to infer
"document.getElementById("#foo");" is a NOP.

> This can be easily debunked using a combination of DOM instructions and
> taking note of how dramatically the ops/s count drops and then comparing
> that difference in ops/s against the same difference from another browser
> like Chrome.

To get back to your particular example, since getElementById in your
microbench runs at approximately 100+ times the speed of querySelector (~15
mio op/s, which seems like what you'd expect) I would suspect that
querySelector() is not optimized out, because it can actually throw an
exception depending on the input.

~~~
austincheney
Each approach is equally capable of resulting in an error state if unexpected
input is supplied, for example pass an array into the document.getElementById.
The largest important difference is that the input to the querySelector must
be parsed as a coded instruction, a selector, while the input to
getElementById is a string literal that does not get parsed.

------
Hitton
Nice, but I think that only in rather extreme situations it would be
worthwhile to write web app in C++.

Can someone knowledgeable enough about wasm tell how difficult is to call
libraries written in another language compared to normal nonweb programming
(say calling C library from Python)?

~~~
wtetzner
> Nice, but I think that only in rather extreme situations it would be
> worthwhile to write web app in C++.

Maybe useful for getting existing desktop applications running in the browser?

------
arxpoetica
Why does everyone love JSX? If they'd kept the DOM separate from the code,
they might have had me—

------
helltone
What is a virtual DOM, and can we have SPA without it?

~~~
SysINT
Yes, however it is important to know one will loose accessibility for people
using assistive technologies. For background try W3C's Web Accessibility
Initiative (WAI) Accessible Rich Internet Applications (WAI-ARIA)
[https://www.w3.org/WAI/standards-
guidelines/aria/](https://www.w3.org/WAI/standards-guidelines/aria/)

~~~
zelly
I understand WAI for articles and "document" web pages, but does anyone who
uses these technologies use them on web apps? Is this even remotely the
audience for most of these SaaS SPAs?

~~~
danShumway
Ideally we'd like SaaS SPAs to be as accessible (if not more accessible) than
articles/documents.

The WAI looks mostly aimed at applications anyway, I suspect in part because
there aren't a ton of compelling reasons to use WASM for a static page.

