I'm a bit lost on the appeal of webassembly. I can see why it's kinda cool to be able to ship a different language to browser and retain performance and bundle sizes, but the problem is I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser.
Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser: high level scripting/VM based langauges which require no memory management and have high level features and data structures. As far as I can tell, these can't target WebAssembly since they don't target LLVM (and you certainly will never be able to compile a language like Ruby to LLVM)
I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.
- Games
- Emulator cores
- Crypto
- Compression
- Software graphics
- Audio processing
- Computer vision
- Physics engines
- Other heavy math/matrix/constraint solvers
- In-memory databases
Besides games, all of these are library uses, and tend to have fixed structure definitions and often even fixed memory buffers to work with (crypto in particular). The developer is still writing the main application in JavaScript (or whatever other dynamic/GC'd language you wish to compile into JS) and gets the full speed and memory footprint benefit of pulling libraries such as these as opposed to seeking pure JS versions.
Have fun writing a new adblocker for each page. Yes, debugging/decompiling is possible, but that is far scarier than the the current situation.
When it's possible to ignore the DOM by uploading your own renderer (e.g. custom freetype/etc compiled to webasm), it's possible to prevent adblocking based on HTML/CSS selectors.
Of course. Similarly, I doubt Adobe intend for Flash to replace entire websites with over-animated single page apps with terrible usability, but that's how many websites used Flash In the late 90s.
Yes, well-designed sites will use WebAssembly in other more reasonable ways. Entirely separate from that are the websites that try to disable the right-click context menu to "protect" images, and the businesses that are watching there revenue disappear with the rise in adblocking. Some businesses will - often foolishly - use all available means to "protect their content", so that's how they will use WebAssembly.
> you certainly will never be able to compile a language like Ruby to LLVM
$ file /usr/bin/ruby
/usr/bin/ruby ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=4b353b68b7d8b46a570883c82efe48db9d77ef22, stripped
Looks like somebody managed it ;)
Snark aside, the trick for running managed languages on the WASM virtual architecture is the same as running them anywhere else: compile the runtime to the target, then ship the runtime with your program. That's what Go does, and why its hello world binary is 1.6 MB.
For a working example, PyPy.js (https://pypyjs.org) successfully ports Python to asm.js. It costs about 5MB in overhead, so it's not a practical alternative to JavaScript, but at this point it's mainly an optimization problem. If a language can statically analyze what libraries and runtime facilities a given program requires, then it can strip out everything else, leaving behind a reasonably sized binary for delivery over the Web.
"a reasonably sized binary for delivery over the Web" This frightens me. I consider a web page over 1 MB (including images) to be outrageous. I dread the day when web developers think its okay to include a 5MB file in a web page! At least other large binary files, like video, can be streamed. Can WASM binary files stream? I imagine the answer is no.
I am excited to write some Rust in the browser, and have been tinkering with what it might look to have a rust frontend framework with ergonomics comparable to what you might expect in other high level languages. (https://anowell.github.io/quasar/)
That said, I agree that more people will want to work in higher level languages, though I kinda suspect "most" are going to still prefer Javascript for the forseeable future - so I sorta see JS compiling to WASM as inevitable.
It's funny... the tactic that ReactNative runs for JS in different environments may well be contrasted with a "BrowserNative" library that bridges browser UI with another compiled (webasm) language.
I'm building some peer-to-peer communications software where I'd like to support the browser as a secondary platform (for users who can't or don't want to download a client). My options for that would be to have the browser act as a thin client and run the software on a server, or run the software in the browser. WebAssembly lets me do the latter without being forced to write all my rather complicated networking code in javascript just to support a secondary platform.
A clue lies in the fact that all the major browser vendors (Google, Microsoft, Mozilla, Apple) are implementing WebAssembly. What is the strategic reason for this?
The speculation is that it all has to do with the rise of native mobile apps, which posed a threat to the web-entrenched interests. Google, I'm guessing, would prefer that you to stay in the web browser, using Google Search to to find all your applications, running them Google Chrome, and remaining a captive audience for Google's advertising clients. (instead of are searching for apps in the App Store and running them natively).
One important reason that native apps initially took off was that games, and other interactive content, could not be efficiently implemented for mobile web browsers. WebAssembly (in combination with WebGL) pretty much solves this problem. People have already ported a number of C++.OpenGL games to the web using emscripten.
> I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser
I understand that most 3D game development is done in C++. I'm guessing that you don't know a lot of 3D game developers?
Besides games, many professional applications are developed in C++, for a variety of reasons. Examples could include scientific, engineering, graphics and audio processing software.
> Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser
Python is an interpreted language and CPython is implemented in C. You can cross-compile to WebAssembly today and start running Python scripts in the browser. Performance critical paths in Python scripts, like NumPy operations, which are offloaded to compiled C functions, would be offloaded to compiled WASM functions.
As for garbage collected languages, like Java and C#, future versions of WebAssembly will provide low-level GC primitives, which should theoretically allow those languages to run in the web browser as well. Having said that, you would incur the overhead of having to run the JVM/CLR virtual machine inside the browser engines's own JavaScript/WebAssembly virtual machine.
> I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.
I suspect there is a lot of interest from C/C++/Rust developers already, and will continue to grow as WASM matures. Something like 10 million professional developers know and use C++ regularly, so this is a not insignificant usergroup on its own.
The first language I see making use of webasm is typescript. They can see a lot of performance improvements over javascript by including type information in the compiled assembly.
FYI, the author noted that wasm-util[0] compiles TypeScript to WebAssembly.
Also, the author notes that future versions of WebAssembly may contain garbage collection features, which would be relevant to TypeScript.
"Garbage collection: If you can define your types ahead of time, you should be able to turn your code into WebAssembly. So code using something like TypeScript should be compilable to WebAssembly. The only hitch currently, though, is that WebAssembly doesn’t know how to interact with existing garbage collectors, like the one built in to the JS engine. The idea of this future feature is to give WebAssembly first-class access to the builtin GC with a set of low-level GC primitive types and operations."
Yes, when you're compiling a particular language to wasm, you could include a GC in wasm code as part of that language's runtime system. But it wouldn't interoperate with the Javascript GC, or GCs for other wasm modules compiled from other toolchains.
Typescript as it exists today is specifically designed to produce readable JavaScript. It does not make use of any runtime type system outside of JavaScript's , so I find it hard to see it that useful outside of a JavaScript compilation source
I'd love to write C++ in the browser, but only if they fix timers. The power of C++ and manual memory management is completely useless if some independent overburdened thread gets to decide when you are scheduled and for how long you run. If you have to just take 5ms breaks in your thread execution, you might as well just get a garbage collector that stops your world for a couple of milliseconds once in a while. Performance and any resemblance of real-time programming is lost anyway.
Could you tell me a bit more about why you want to write C++ in the browser? What things are you doing that are so CPU intensive that C++ is higher productivity then just JS?
Not the OP, but you're assuming that systems languages are lower productivity than JavaScript. I don't believe that Rust and Swift are necessarily lower productivity than JavaScript.
Nevertheless, here are a few of the main reasons you might want to work in a language that can easily target WASM:
1. Wholesale porting of desktop applications and game engines to the Web. This is the guise under which we developed asm.js, and it resonated well enough that Epic and Unity added support for asm.js to their engines.
2. Re-using existing, well-tested libraries that are written in C/C++. Why settle for zip.js if I can use libarchive directly? What about libraries that don't necessarily have high-quality JavaScript equivalents, like OpenCV, Box2D, or libsass?
3. Shipping high-performance codecs for multimedia formats like FLIF, BPG, and AV1 that aren't natively supported by browsers. Mozilla is actively using this strategy to develope the AV1 codec: https://hacks.mozilla.org/2017/02/webassembly-will-ease-coll...
4. Optimizing hot paths in JavaScript codebases, in the same way that Python or Ruby programmers will often re-implement individual functions or modules in C to overcome bottlenecks. For an example of this, consider the Flask microframework in Python, which depends on the Jinja2 templating library, which depends on Markupsafe for escaping HTML. Buried inside markupsafe is a 200 line file, "_speedups.c", that speeds things up. So even if end-developers aren't writing C/C++/Rust, they can still benefit from libraries that incorporate WASM.
5. Saving battery life. The fewer cycles it takes to finish a computation, the longer the CPU can spend sleeping. WASM provides significantly greater control over exactly what executes, and you can opt to burn CPU cycles on optimization once, during compilation, to get more a more efficient .wasm artifact for everyone. Since WASM is statically typed, the compiler also has many more optimizations available to it; no more worrying about monomorphism or type inference as with a JS VM's JIT compiler.
It's not about being CPU-intensive - it's about getting to write better, more maintainable code in a better language with better tooling than JavaScript. Let's keep in mind that all lipstick notwithstanding, JavaScript is still a pig, and it's use is not out of its desirability on its own merits, but a product of circumstance.
True real-time audio.
The WebAudio API just connects a pre-existing collection of basic nodes implemented by the browser in C or C++.
Being able to write sample-level processing targeted to WebASM would open up a lot of opportunities for different types of audio synthesis, effects, and analysis.
Not the same person, but for me, and a lot of the people I know it's a case of: "Anything but Javascript", rather than a specific language. Seeing as the web, and web "apps" are taking over, we don't all want to be pigeon-holed into writing JS/React/Angular/Node.
Video games. They require soft realtime constraints which current browsers are far from satisfying. Think networking, frame rendering, physics loop (even with deltas), etc. All of that is highly time-dependent.
JavaScript (ES6) is a decent language, but some people prefer another language. While it is true that anything that can be accomplished on the web can be accomplished with JS (Turing completeness and all), people may not enjoy working with it.
Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser: high level scripting/VM based langauges which require no memory management and have high level features and data structures. As far as I can tell, these can't target WebAssembly since they don't target LLVM (and you certainly will never be able to compile a language like Ruby to LLVM)
I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.