4 ms·

For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code insid

For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code inside the browser without adapting it (much), and doing this at a speed which is not (much) worse than the speed of the original code. This in turn makes functionality that was traditionally very hard to get in a browser/JS environment suddenly very easy to get: - Cryptographic libraries (e.g. libcrypto) - Libraries for numerical data manipulation and analysis - Compression libraries - Video codecs - ... This ability will lead to a paradigm shift (IMHO), because instead of having to reproduce all this functionality in JS (which would be crazy) you can just cross-compile it and use it right away. Also, with WebAssembly, browser vendors can simply focus on providing good and secure interfaces to a limited amount of low-level functions (IO, graphics) while letting the user define the high-level usage of these interfaces. If this works out well I can even imagine this technology spilling over to other domains, because what it provides is essentially a secure, portable, low-level sandbox with a very good performance and a huge installation base.

arethuza 9y ago
I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?
- dullgiulio 9y ago
  That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
  - ThePhysicist 9y ago
    There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.
    - dullgiulio 9y ago
      Alright, but everything can still be tampered. At best, you can cause a denial of service, at worst modify a document that a user signs has its own.
lacampbell 9y ago
This is the exciting new world I am thinking (hoping?) might happen. If this web assembly thing ends up being a success, the web is going to start taking an even larger slice of the development pie. There will still be a place for native apps of course, but that place will IMO be much smaller.

arethuza 9y ago

I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?

dullgiulio 9y ago
That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
- ThePhysicist 9y ago
  There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.
  - dullgiulio 9y ago
    Alright, but everything can still be tampered. At best, you can cause a denial of service, at worst modify a document that a user signs has its own.

lacampbell 9y ago

This is the exciting new world I am thinking (hoping?) might happen. If this web assembly thing ends up being a success, the web is going to start taking an even larger slice of the development pie. There will still be a place for native apps of course, but that place will IMO be much smaller.