13. • Announced in 17 June 2015
• Supported by major Browsers
• Developed by WebAssembly Working
Group (W3C)
• Draft specific published 15 Feb 2018
WebAssembly – New Hope
36. EXECUTION
slow at start
threads - workers
no native threads
GC
close to native speed
threads – workers
native threads - future
no GC now
37. EXECUTION
many types
access to JS functions
access to DOM
access to Host API
only 4 primitive types
access to JS functions
no access to DOM
no access to Host API
50. SUMMARY
• Size of WebAssembly module depends on compiler
• WebAssembly compilation is slower to js in Mb/s
• WebAssembly has streaming compilation that compile module during network delays
• WebAssembly might be parsed out of main thread
70. CONVERT IMAGES
• Canvas + JS:
From JPEG to BITMAP by Canvas API and to WEBP by JS (lib webpjs)
• Canvas + WASM:
From JPEG to BITMAP by Canvas API and to WEBP by WASM (lib libwebp)
• Full WASM: JPEG to WEBP by WASM (libs: libjpeg, libwebp)
80. CONVERT IMAGES
• Canvas API works in main thread and blocks it
• WebAssembly does not block main thread
81. SUMMARY
• WebAssembly has very good performance on pure mathematics
• Call JS from WebAssembly lead to slow down of the performance
• Host API might be slower then WebAssembly in edge cases(!)
83. WHAT PROJECT FITS TO WEBASSEMLBY
• Requires a lot of computations
• Is developed with WebAssembly and high performance in mind
• Has small amount of interactions with JavaScript or DOM
• Has big C/C++ code base and high performance is not a goal
• Fast enough for Browser
87. USAGE SCENARIOS IN WEB
• Write faster version of the specific application
• Using existing C libraries in browser
• Reuse algorithm from service side
• Distribute whole application as wasm
• Secure your algorithms J
88. BUILD TARGET FOR
• C/C++
• Rust
• C# - Mono and CoreRT
• Go
• BrainFuck
• Even more: https://github.com/appcypher/awesome-wasm-langs