8 ms·

> Faster-than-JS DOM performance ... > The wasm-bindgen code generation has been designed with the future host bindings proposal in mind from day 1. As soon a

> Faster-than-JS DOM performance ... > The wasm-bindgen code generation has been designed with the future host bindings proposal in mind from day 1. As soon as that’s a feature available in WebAssembly, we’ll be able to directly invoke imported functions without any of wasm-bindgen‘s JS shims. Sweet. Once again, Rust team knocking it out of the park.

jerf 9y ago
"Faster-than-JS DOM performance" That will be when the clock starts ticking on Javascript. Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? I'm not saying Rust will completely eat Javascript; there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, and also tends to afford the use of more efficient constructs that Javascript can provide (i.e., can't do anything about cache coherency in JS, can't manage how much copying you do in JS directly, etc.). And if the ball starts rolling on this, the browsers will start doing things like allowing WASM to register correctly-typed events handlers that don't have to be marshaled into JS and back... it's been a long road and there's a long road ahead still but do I see the glimmer of a world in which browsers can actually perform within a factor of 2 of native UIs?
- maxxxxx 9y ago
  Is JS even the speed problem or is it banging on the DOM all the time?
  - deleted 9y ago
    [deleted]
  - vardump 9y ago
    It might help to think speed as lower power consumption. So yes. As long as cellphones and laptops need a battery.
    - maxxxxx 9y ago
      I understand. My question is whether it's the Javascript code that uses CPU cycles or the DOM manipulations that cause the browser to recalculate the layout and do other stuff all the time? If it's the browser then it doesn't matter whether you use Javascript or webasm.
  - grayrest 9y ago
    The bottleneck varies depending on the specifics of the JS, DOM and CSS. I find that when something is slow the culprit is usually someone doing something dumb in JS. For non-dumb causes, layout is usually the bottleneck (reflow, applying styles, building the display list) but it can be other things. As an example, I worked on a site 5 years ago or so where the bottleneck was on paint, mostly due to lots of shadows. I believe caching of rendered shadows has made its way into most engines but it caused us issues at the time. Mozilla has been doing a lot of work on this front. The Servo project demonstrated you can do style and reflow in parallel. Pieces of that effort have been pulled into Firefox under the "Quantum" label but not the actual reflow part. They're in the process of finishing and incorporating WebRender to make paint more efficient and GPU driven and there have also been efforts at building new drawing APIs (PathTracer, Lyon) as part of that project. I know Chrome had been doing experiments with implementing DOM methods in Javascript to avoid having to cross the JS/C++ barrier in v8 but I haven't heard about that in a while nor any other major DOM-related perf projects out of them. Fairly long answer to a short question. If the new APIs retain the synchronous nature of the current DOM APIs where reads against the DOM state force previous DOM manipulations are blocked until a forced layout happens (I hope they are) then it'll still be possible to DOM thrash and kill your perf that way. I also suspect there's enough overhead in JS->DOM calls that WASM could pick up a double digit perf gain in microbenchmarks but not an order of magnitude with the caveat that's a fairly uninformed guess.
- jcoffland 9y ago
  Rust is also still very far from having eaten any significant chunk of C.
  - wffurr 9y ago
    Do you see any reason why it won't eventually do so?
    - runevault 9y ago
      Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up. There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.
      - pjmlp 9y ago
        Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.
        mmstick 9y ago
        We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.
    - 2trill2spill 9y ago
      I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.
    - maxxxxx 9y ago
- flavio81 9y ago
  >Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? Erm... PSA: Rust isn't the only language that is compiling to WASM. I'm glad for Rust developers (How exciting is for them to be able to target WASM), but what is really exciting is to have alternatives; even more exciting if they have nothing to do with javascript.
  - jerf 9y ago
    "Erm... PSA: Rust isn't the only language that is compiling to WASM." No, but Rust will still be sitting in a sweet spot, having many of those characteristics I named. For instance, Python compiling to WASM may be useful, but it won't have any of those advantages. Python running on WASM isn't hardly a threat to JS at all, because it won't do anything JS can't. Rust will conceivably be able to in the near term, and as I said, if it takes off and the browsers start adapting to statically-typed functions running in WASM the gap could open even more.
    - timClicks 9y ago
      IIRC wasm has no GC capabilities, so Python is an unlikely source language.
      - steveklabnik 9y ago
        In cases like that, you also compile the Python GC to wasm and use it. It ships with your app, adding bloat to your binary though. It does work!
        timClicks 9y ago
        Ah gotcha, have also been pretty impressed by pypyjs http://pypyjs.org/ http://pypyjs.org/
  - Can_Not 9y ago
    > Erm... PSA: Rust isn't the only language that is compiling to WASM. How many other languages are you expecting that most people really want to use but don't require a multi-megabyte VM?
- maxxxxx 9y ago
  Rust isn't the only player here. Kotlin I think does webasm already. And I think Java and C# will also jump on the bandwagon eventually.
  - steveklabnik 9y ago
    Rust has some significant advantages compared to languages like Kotlin, Java, and C# here. A really big one is binary sizes. To get those languages to work, you have to ship the entire runtime. For example, see https://www.infoq.com/news/2018/01/mono-cs-webassembly https://www.infoq.com/news/2018/01/mono-cs-webassembly > (the "hello world" example is 10 megabytes) The "hello world" example in Rust is ~100 bytes. Some applications and some people can pay these costs, it's true. But tiny binaries is quite appealing. It's even part of the reason that WebAssembly was created in the first place.
    - pjmlp 9y ago
      Java and .NET also have linkers, which can help bring down that size, even if not as much as Rust.
      - steveklabnik 9y ago
        I don’t doubt they’ll get some reduction, but it will always be more than zero.
        pjmlp 9y ago
        Yep, as I stated it is never going to be as small as Rust. Still, it might be small enough. Check the new version of Unity for browser deployment. https://youtu.be/EWVU6cFdmr0 https://youtu.be/EWVU6cFdmr0 796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.
        steveklabnik 9y ago
        That's awesome! I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.
- FridgeSeal 9y ago
  > there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, Maybe a good way of kicking this off is if someone writes a DSL/hosted language that compiles/transpiles/whatever down into Rust. Have this language be nice and easy to write (a la Python) and have it's compiler turn it into performant Rust. Kind of like how Nim works with respect to C. This way we could let web devs worry about the actual logic that runs the animations and stuff but have it compiled down into efficient, performant code. Everybody wins: we can finally get rid of JS, code that runs on our machines gets safer, faster and less resource hungry and JS devs are happy.
  - O_H_E 9y ago
    If this was implemented correctly, it could go viral.
  - nimmer 9y ago
    Nim does that with JS. Wasm generation requires someone to write a compiler backend for it but it can be done.
- Vinnl 9y ago
  I don't really mind Javascript that much, although I do agree that there are definitely nicer languages, and that Rust is probably one (I haven't worked with Rust yet). That said, one really nice thing that I fear we'd lose is the interoperability of the ecosystem. There are a lot of good libraries available for Javascript that help doing webdev, and I wonder what effect fragmentation of languages could have on that. Will we trade having nicer languages for availability of useful libraries in your language of choice?
  - steveklabnik 9y ago
    One project you'll hear about soon is wasm-pack; it's a tool that lets you take wasm-bindgen, compile your Rust to wasm, and then upload an npm package containing just the wasm, so that anyone using Node can use your stuff. The real issue is the various runtimes, not the actual libraries themselves.
    - Vinnl 9y ago
      That's a good point, and good news!

jerf 9y ago

"Faster-than-JS DOM performance" That will be when the clock starts ticking on Javascript. Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? I'm not saying Rust will completely eat Javascript; there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, and also tends to afford the use of more efficient constructs that Javascript can provide (i.e., can't do anything about cache coherency in JS, can't manage how much copying you do in JS directly, etc.). And if the ball starts rolling on this, the browsers will start doing things like allowing WASM to register correctly-typed events handlers that don't have to be marshaled into JS and back... it's been a long road and there's a long road ahead still but do I see the glimmer of a world in which browsers can actually perform within a factor of 2 of native UIs?

maxxxxx 9y ago
Is JS even the speed problem or is it banging on the DOM all the time?
- deleted 9y ago
  [deleted]
- vardump 9y ago
  It might help to think speed as lower power consumption. So yes. As long as cellphones and laptops need a battery.
  - maxxxxx 9y ago
    I understand. My question is whether it's the Javascript code that uses CPU cycles or the DOM manipulations that cause the browser to recalculate the layout and do other stuff all the time? If it's the browser then it doesn't matter whether you use Javascript or webasm.
- grayrest 9y ago
  The bottleneck varies depending on the specifics of the JS, DOM and CSS. I find that when something is slow the culprit is usually someone doing something dumb in JS. For non-dumb causes, layout is usually the bottleneck (reflow, applying styles, building the display list) but it can be other things. As an example, I worked on a site 5 years ago or so where the bottleneck was on paint, mostly due to lots of shadows. I believe caching of rendered shadows has made its way into most engines but it caused us issues at the time. Mozilla has been doing a lot of work on this front. The Servo project demonstrated you can do style and reflow in parallel. Pieces of that effort have been pulled into Firefox under the "Quantum" label but not the actual reflow part. They're in the process of finishing and incorporating WebRender to make paint more efficient and GPU driven and there have also been efforts at building new drawing APIs (PathTracer, Lyon) as part of that project. I know Chrome had been doing experiments with implementing DOM methods in Javascript to avoid having to cross the JS/C++ barrier in v8 but I haven't heard about that in a while nor any other major DOM-related perf projects out of them. Fairly long answer to a short question. If the new APIs retain the synchronous nature of the current DOM APIs where reads against the DOM state force previous DOM manipulations are blocked until a forced layout happens (I hope they are) then it'll still be possible to DOM thrash and kill your perf that way. I also suspect there's enough overhead in JS->DOM calls that WASM could pick up a double digit perf gain in microbenchmarks but not an order of magnitude with the caveat that's a fairly uninformed guess.
jcoffland 9y ago
Rust is also still very far from having eaten any significant chunk of C.
- wffurr 9y ago
  Do you see any reason why it won't eventually do so?
  - runevault 9y ago
    Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up. There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.
    - pjmlp 9y ago
      Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.
      - mmstick 9y ago
        We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.
  - 2trill2spill 9y ago
    I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.
  - maxxxxx 9y ago
flavio81 9y ago
>Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? Erm... PSA: Rust isn't the only language that is compiling to WASM. I'm glad for Rust developers (How exciting is for them to be able to target WASM), but what is really exciting is to have alternatives; even more exciting if they have nothing to do with javascript.
- jerf 9y ago
  "Erm... PSA: Rust isn't the only language that is compiling to WASM." No, but Rust will still be sitting in a sweet spot, having many of those characteristics I named. For instance, Python compiling to WASM may be useful, but it won't have any of those advantages. Python running on WASM isn't hardly a threat to JS at all, because it won't do anything JS can't. Rust will conceivably be able to in the near term, and as I said, if it takes off and the browsers start adapting to statically-typed functions running in WASM the gap could open even more.
  - timClicks 9y ago
    IIRC wasm has no GC capabilities, so Python is an unlikely source language.
    - steveklabnik 9y ago
      In cases like that, you also compile the Python GC to wasm and use it. It ships with your app, adding bloat to your binary though. It does work!
      - timClicks 9y ago
        Ah gotcha, have also been pretty impressed by pypyjs http://pypyjs.org/ http://pypyjs.org/
- Can_Not 9y ago
  > Erm... PSA: Rust isn't the only language that is compiling to WASM. How many other languages are you expecting that most people really want to use but don't require a multi-megabyte VM?
maxxxxx 9y ago
Rust isn't the only player here. Kotlin I think does webasm already. And I think Java and C# will also jump on the bandwagon eventually.
- steveklabnik 9y ago
  Rust has some significant advantages compared to languages like Kotlin, Java, and C# here. A really big one is binary sizes. To get those languages to work, you have to ship the entire runtime. For example, see https://www.infoq.com/news/2018/01/mono-cs-webassembly https://www.infoq.com/news/2018/01/mono-cs-webassembly > (the "hello world" example is 10 megabytes) The "hello world" example in Rust is ~100 bytes. Some applications and some people can pay these costs, it's true. But tiny binaries is quite appealing. It's even part of the reason that WebAssembly was created in the first place.
  - pjmlp 9y ago
    Java and .NET also have linkers, which can help bring down that size, even if not as much as Rust.
    - steveklabnik 9y ago
      I don’t doubt they’ll get some reduction, but it will always be more than zero.
      - pjmlp 9y ago
        Yep, as I stated it is never going to be as small as Rust. Still, it might be small enough. Check the new version of Unity for browser deployment. https://youtu.be/EWVU6cFdmr0 https://youtu.be/EWVU6cFdmr0 796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.
        steveklabnik 9y ago
        That's awesome! I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.
FridgeSeal 9y ago
> there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, Maybe a good way of kicking this off is if someone writes a DSL/hosted language that compiles/transpiles/whatever down into Rust. Have this language be nice and easy to write (a la Python) and have it's compiler turn it into performant Rust. Kind of like how Nim works with respect to C. This way we could let web devs worry about the actual logic that runs the animations and stuff but have it compiled down into efficient, performant code. Everybody wins: we can finally get rid of JS, code that runs on our machines gets safer, faster and less resource hungry and JS devs are happy.
- O_H_E 9y ago
  If this was implemented correctly, it could go viral.
- nimmer 9y ago
  Nim does that with JS. Wasm generation requires someone to write a compiler backend for it but it can be done.
Vinnl 9y ago
I don't really mind Javascript that much, although I do agree that there are definitely nicer languages, and that Rust is probably one (I haven't worked with Rust yet). That said, one really nice thing that I fear we'd lose is the interoperability of the ecosystem. There are a lot of good libraries available for Javascript that help doing webdev, and I wonder what effect fragmentation of languages could have on that. Will we trade having nicer languages for availability of useful libraries in your language of choice?
- steveklabnik 9y ago
  One project you'll hear about soon is wasm-pack; it's a tool that lets you take wasm-bindgen, compile your Rust to wasm, and then upload an npm package containing just the wasm, so that anyone using Node can use your stuff. The real issue is the various runtimes, not the actual libraries themselves.
  - Vinnl 9y ago
    That's a good point, and good news!