#webassembly

[lostjared]

[itrunsdoom]

16,000 HTML checkboxes? Yeah, they render Doom.

Thanks for sharing, AlexMax!

[iamdeveloper]

Why everyone is talking about WebAssemblyRust ☞ https://bit.ly/2L8s9mI #WebAssembly #Morioh

[fnord888]

Who exactly wants SharedArrayBuffer anyway?

[insidehtml5]

Calls between JavaScript and WebAssembly are finally fast 🎉 – Mozilla Hacks - the Web developer blog

At Mozilla, we want WebAssembly to be as fast as it can be. This started with its design, which gives it great throughput. Then we improved load times with a ...

[michaelgogins]

Operating Systems Asleep at the Wheel? and the Future of Computer Music

As you may know Csound has had a WebAssembly build for some time now. Based on my experience with Csound for WASM in the Csound Showcase, I offer some thoughts on the future of computing in general, and computer music in particular. It does go that deep and that far.

Currently pretty much all of Csound except for multi-threading runs just fine in WASM. Other benchmarks in other projects show approximate parity between C code compiled to machine language for the desktop (”native”) and compiled to WASM for the browser, as long as the code doesn’t call out to the browser; such calls currently impose high overhead.

But that overhead is likely to be optimized, and there will then be no or small speed advantages to native code, while at the same, there will be other and potentially quite important advantages to WASM code.

At this time, a rough benchmark for Csound for WebAssembly shows runnng "csound-high-resolution.csd” at sr = 48000 and ksmps = 100 takes about 4.5 seconds using native Csound on the desktop, and running the exact same piece in Csound for WebAssembly using a local Web server takes 9.45 seconds. That’s more or less half as fast for WASM, and that’s quite usable.

One obvious advantage for WASM is that it will run just fine in every common browser on every operating system.

But there is a potentially equally important advantange in that WASM modules should soon be able to call into the browser, into the browser’s document object module, and into other WASM modules. It is this last clause that should arrest your attention. It means that WASM could soon support an immense ecosystem of proven, debugged, high-performance, reusable libraries, even more so than Java, JavaScript, Python, or .NET. Csound itself is of course an example of such a WASM library.

This has all almost happened before. It used to be the case that Web browsers would run Java applets, and there was an easy interface between JavaScript and Java classes in the browser’s JavaScript context. This cool possibility was killed because corporations did not like (indeed, nobody liked) the security loopholes it brought.

The WASM ecosystem is more likely to take hold because (a) all the major browser and Internet corporations currently support it, and (b) the WASM runtimes in browsers rigorously enforce the same security sandbox that contains JavaScript code. This sandbox is what prevents code from one Web site being tricked into running malicious code from another Web site.

One may wonder: Why not get rid of the operating system altogether, or rather, replace it with a thin layer that runs applications as WASM modules? I see absolutely no reason not to do this.

Operating systems, of course, could be modified to bring the same advantages to regular “desktop” applications and libraries. That would mean installing a WASM runtime as a standard component of the operating system, like bash on Linux, and having the OS automatically run WASM applications. It would also most likely mean adding to standard compilers such as gcc a built-in option for compiling to WASM. If operating system designers and maintaners are not, indeed, asleep at the wheel, then that will happen (this option has clearly been foreseen and provided for by the WASM designers).

Again, this has almost all happened before. Microsoft’s .NET virtual machine promised this kind of inter-operability, and it was extended to Linux and the open source world with the Mono project, which is still alive. But .NET did not take over the world. Possible reasons include lack of native speed, and bias against MIcrosoft, 

But it doesn’t matter. Mono has been ported to WASM.

Indeed many languages now compile to WASM, see this list.

Okay, now for the concluding punch line. 

If, in addition to Csound, other computer music systems, applications, and libraries were compiled to WASM, then they could all talk to each other. JavaScript would serve as the universal scripting language/glue code. This would at least make it possible to break through the silo walls that have tended to technically isolate different communities of computer musicians. Note that JavaScript itself is now a fairly high performance language.

Systems that I would particularly like to see ported to WASM include OpenMusic, Common Music, Grace, Pure Data, SuperCollider, Max, LilyPond, and MuseScore. Some of these would require first porting Scheme or Common Lisp to WASM. That in turn will require adding to WASM a garbage-collected memory manager.

What this means for me and my computer music projects is that I will probably in the near future release binaries only as WASM. I will add a release for WASM to csound-extended and, over time, move all suitable code into this release. You will be able to track the progress of this undertaking here.

[sinfallas]

La vida después de Flash: multimedia para la Web abierta

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por juliabis. Flash hizo llegar vídeo, animación, sitios interactivos y, sí, anuncios a miles de millones de usuarios durante más de una década, pero ahora se se está marchando. Adobe dejará de soportar Flash para el año 2020. Firefox ya no lo soporta “fuera de la caja”, y Chrome tampoco. ¿Qué es lo…

View On WordPress

[another-normal-anomaly]

Best thing about doing programmer things with someone more experienced than you: going down way fewer blind alleys

Worst thing about it: constantly having to choose between asking a stupid question now, and falling behind and having to ask two stupid questions later.