5 ms·

"All interactions with the DOM are written in Javascript." You can only be as fast as the slowest link. Does it help for virtual dom reconciliation to be in W

"All interactions with the DOM are written in Javascript." You can only be as fast as the slowest link. Does it help for virtual dom reconciliation to be in WASM as opposed to JS that is optimized and JIT'ed by modern JS engines? I doubt it as the use case is very different from VR/AR/AI where WASM would presumably have some advantage. Any experts to educate us?

gizmo 9y ago
Web browsers are pretty fast already, so if you only do those DOM updates that actually affect what you see on screen you can have your app update at 60 frames per second. That's where a virtual dom helps out. Virtual dom systems effectively work in two stages: 1) figuring out how the DOM should be updated 2) applying these changes with as few (or cheapest) DOM operations as possible I don't expect WebAssembly will do much for step (2), as the bottleneck there is in repeatedly crossing the boundary between the javascript world and the DOM, or in the DOM operations themselves. Step (1) is essentially just crunching (tree based) data structures. Web Assembly should be a lot faster here, because (depending on implementation) you get denser data structures, better cache locality, no garbage collection, and so on. You'll also get much more consistent performance. For complex web applications that keep a lot of view state around (1) might be the bottleneck, but in most real world applications I expect that (2) is the bottleneck, because the browser has to do so much work in terms of layout, CSS application, and so on every time the DOM gets updated. If you really want to get a big performance improvement you have to do much more in WebAssembly. Use only absolute positioning for DOM nodes and create your own layout engine. Don't have any CSS except for the rules needed to display what is currently visible. Do all typesetting in WebAssembly too. This means recreating much of a web browser inside a web browser, and you can then optimize the WebAssembly code for the specific needs of your web application for big performance gains. It may sound hugely impractical, but if WebAsembly is only 10% slower than C it's viable. It means you won't have to wait for standards organizations to give new FlexBox options, or a way to dynamically adjust font size to fit a fixed rectangle, you can just solve all these problems locally. If this works it could lead to a complete "user space" renaissance.
- oever 9y ago
  > Web Assembly should be a lot faster here, because (depending on implementation) you get denser data structures, better cache locality, no garbage collection, and so on. You can get these advantages by using plain javascript with typed arrays. https://github.com/vandenoever/baredom https://github.com/vandenoever/baredom
  - DonHopkins 9y ago
    I would guess a lot of the overhead would be thunking back and forth between webasm and js functions, so if you implemented the update in pure js where it can call directly into the DOM apis, and also read pointers, numbers and strings directly out of the webasm data array, then you could avoid any thunking between the two different worlds in the inner loop. By thunking I mean doing this from C++ code: EM_ASM_({ window['asmDomHelpers']['domApi']['appendChild']($0, $1); }, vnode->elm, createElm(vnode->children[i]));
    - oever 9y ago
      So you propose to interface between C++ and JavaScript via a shared buffer and to eschew any explicit FFI calls. If the data structure is lockless, that is doable.
- TimJYoung 9y ago
  "If you really want to..." This is exactly what we've done with our product, Elevate Web Builder, so I can definitely attest to the fact that it is 100% correct. Our product uses a compile-to-JS transpiler and has its own layout engine, uses dynamic CSS, has update cycles to allow for efficient DOM updates, etc. The only real downside is that text measurment must touch the DOM and is really slow, so the layout engine has to perform a lot of intelligent caching and "measurement-avoidance" techniques to ensure that it measures text as infrequently as possible.
  - gizmo 9y ago
    If you do your own line wrapping, then I'm pretty sure you don't need to do any text measurements. To get the kerning information for a given font face and size you can cache the widths of all character pairs ("AA", "AB", "AC"). Last I checked just summing the width of character pairs in a string would get you a width estimate accurate to the pixel, even for reasonably long strings. You don't have cross-platform pixel-perfect text rendering anyway, so you don't need to be 100% accurate. Maybe you're already doing this, but if not it's worth exploring.
coldtea 9y ago
>You can only be as fast as the slowest link Only if that "slowest links" takes a large part of your processing time. If you have a program that reads some data and passes them to a much faster foreign function (e.g. Python passing to a C extension) to do some calculation, then your "slowest link" (in this case, Python) wont matter much. The program will still be many times faster than if the calculation had been written in pure Python.
pizlonator 9y ago
The speed advantage - if there is one - would come from the code surrounding the DOM not the DOM code itself. Without this package you would write the surrounding code in JS because that's what you need to do to even talk to the DOM. But with this package that code can be written in C++ and so it will be fast. If you have enough of that surrounding non-DOM code that significantly benefits from not being JS, then you will have a speed up. You could get this speed up even if talking to the DOM using this package is slower than talking to the DOM directly in JS. It just depends on how much do you depend on the speed of everything else and how much of everything else is written in C++.

gizmo 9y ago

Web browsers are pretty fast already, so if you only do those DOM updates that actually affect what you see on screen you can have your app update at 60 frames per second. That's where a virtual dom helps out. Virtual dom systems effectively work in two stages: 1) figuring out how the DOM should be updated 2) applying these changes with as few (or cheapest) DOM operations as possible I don't expect WebAssembly will do much for step (2), as the bottleneck there is in repeatedly crossing the boundary between the javascript world and the DOM, or in the DOM operations themselves. Step (1) is essentially just crunching (tree based) data structures. Web Assembly should be a lot faster here, because (depending on implementation) you get denser data structures, better cache locality, no garbage collection, and so on. You'll also get much more consistent performance. For complex web applications that keep a lot of view state around (1) might be the bottleneck, but in most real world applications I expect that (2) is the bottleneck, because the browser has to do so much work in terms of layout, CSS application, and so on every time the DOM gets updated. If you really want to get a big performance improvement you have to do much more in WebAssembly. Use only absolute positioning for DOM nodes and create your own layout engine. Don't have any CSS except for the rules needed to display what is currently visible. Do all typesetting in WebAssembly too. This means recreating much of a web browser inside a web browser, and you can then optimize the WebAssembly code for the specific needs of your web application for big performance gains. It may sound hugely impractical, but if WebAsembly is only 10% slower than C it's viable. It means you won't have to wait for standards organizations to give new FlexBox options, or a way to dynamically adjust font size to fit a fixed rectangle, you can just solve all these problems locally. If this works it could lead to a complete "user space" renaissance.

oever 9y ago
> Web Assembly should be a lot faster here, because (depending on implementation) you get denser data structures, better cache locality, no garbage collection, and so on. You can get these advantages by using plain javascript with typed arrays. https://github.com/vandenoever/baredom https://github.com/vandenoever/baredom
- DonHopkins 9y ago
  I would guess a lot of the overhead would be thunking back and forth between webasm and js functions, so if you implemented the update in pure js where it can call directly into the DOM apis, and also read pointers, numbers and strings directly out of the webasm data array, then you could avoid any thunking between the two different worlds in the inner loop. By thunking I mean doing this from C++ code: EM_ASM_({ window['asmDomHelpers']['domApi']['appendChild']($0, $1); }, vnode->elm, createElm(vnode->children[i]));
  - oever 9y ago
    So you propose to interface between C++ and JavaScript via a shared buffer and to eschew any explicit FFI calls. If the data structure is lockless, that is doable.
TimJYoung 9y ago
"If you really want to..." This is exactly what we've done with our product, Elevate Web Builder, so I can definitely attest to the fact that it is 100% correct. Our product uses a compile-to-JS transpiler and has its own layout engine, uses dynamic CSS, has update cycles to allow for efficient DOM updates, etc. The only real downside is that text measurment must touch the DOM and is really slow, so the layout engine has to perform a lot of intelligent caching and "measurement-avoidance" techniques to ensure that it measures text as infrequently as possible.
- gizmo 9y ago
  If you do your own line wrapping, then I'm pretty sure you don't need to do any text measurements. To get the kerning information for a given font face and size you can cache the widths of all character pairs ("AA", "AB", "AC"). Last I checked just summing the width of character pairs in a string would get you a width estimate accurate to the pixel, even for reasonably long strings. You don't have cross-platform pixel-perfect text rendering anyway, so you don't need to be 100% accurate. Maybe you're already doing this, but if not it's worth exploring.

coldtea 9y ago

>You can only be as fast as the slowest link Only if that "slowest links" takes a large part of your processing time. If you have a program that reads some data and passes them to a much faster foreign function (e.g. Python passing to a C extension) to do some calculation, then your "slowest link" (in this case, Python) wont matter much. The program will still be many times faster than if the calculation had been written in pure Python.

pizlonator 9y ago

The speed advantage - if there is one - would come from the code surrounding the DOM not the DOM code itself. Without this package you would write the surrounding code in JS because that's what you need to do to even talk to the DOM. But with this package that code can be written in C++ and so it will be fast. If you have enough of that surrounding non-DOM code that significantly benefits from not being JS, then you will have a speed up. You could get this speed up even if talking to the DOM using this package is slower than talking to the DOM directly in JS. It just depends on how much do you depend on the speed of everything else and how much of everything else is written in C++.