4 ms·
I think you're just misunderstanding what wasm is. Writing browser applications in any language was never a "core benefit proposition", it was just something th
by NationalPark 6y ago
I think you're just misunderstanding what wasm is. Writing browser applications in any language was never a "core benefit proposition", it was just something that you could do with the tooling. The value has always been in the library/platform layer. Objectively pure wasm is faster than pure javascript, subjectively the additional type safety from writing in Rust (which is practically speaking what most people shipping wasm write their source code in) makes people more confident that their complex code works.
Outside of a few hobbyists, nobody is writing entire web applications in wasm. We already have great frameworks for dealing with UI/DOM stuff.
- Rochus 6y agoTo quote from https://webassembly.org/ https://webassembly.org/: "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a silly idea of some hobbyists.
- jkelleyrtp 6y agoBrowser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features. My favorite example is Rapier http://rapier.rs/ http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.
- Rochus 6y agoThanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.
- CyberDildonics 6y agoI tried the same thing and it took 4 seconds on my 8 year old computer.
- Rochus 6y agoThanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.
- CyberDildonics 6y agoDrawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.
- Rochus 6y agoFrom https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL: "WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas" So I would guess that when your graphics chip is faster than mine you get a higher performance.
- CyberDildonics 6y agoThese two things have nothing to do with each other. This is a physics engine running on your CPU, not your GPU. The webgl window is run with your GPU and is extremely simple. Drawing a few dozen boxes is something graphics cards from 22 years ago would have no problem with.
- raxxorrax 6y agoLooks like a nice physics engine, but I wouldn't say it blows JS engines out of the water performance wise. They are surprisingly fast these days. Ammo js: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.html http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.ht... Ammo wasm: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wasm.html http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wa... They can be faster, but it is still insane how fast JS interpreters have become. So for smaller application it might be ok to stay in JS land.