3 ms·
The design goals of WebAssembly are the following: Fast, safe, and portable semantics: * Fast: executes with near native code performance, taking advantage of
by nojvek 7y ago
The design goals of WebAssembly are the following:
Fast, safe, and portable semantics:
* Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
* Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
* Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
* Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
* Language-independent: does not privilege any particular language, programming model, or object model.
* Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
* Open: programs can interoperate with their environment in a simple and universal manner.
Efficient and portable representation:
* Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
* Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
* Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
* Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
* Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
* Portable: makes no architectural assumptions that are not broadly supported across modern hardware.
If webassembly is truly able to meet this goals, together with good debugging and tools, it will become the the universal way to represent computation across devices and platforms.
Really cool.
- skunkworker 7y agoTwo of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers. About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing for in-browser MP3 encoding. And secondly cloudflare allows for their workers to be written in WASM, allowing for more processor intensive apps (like resizing an image) to be completely on the edge. I see it as eventually fulfilling the portability goals that java applets in the browsers use to have, but instead of one you have many companies agreeing on the implementation. [1] https://github.com/Kagami/vmsg https://github.com/Kagami/vmsg [2] https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
- robocat 7y ago> like resizing an image For image uploading, resizing is best done in the browser, so you are not sending large files over a limited mobile connection. The code is ugly (it also needs to fix image rotation by reading EXIF information because browsers are broken, and if supporting IE11 then there is some other voodoo).
- zzo38computer 7y agoThe problem is that the browser does not let me enter a shell command where a filename is expected (Heirloom-mailx does allow it, and is something I often use when dealing with attachments).
- skunkworker 7y agoThe Cloudflare workers using WASM allow an image from a server to be resized on the edge before being delivered to the end user, not the other way around.