[coolmitch]

As a web developer working primarily in JS, what should I be learning now to stay relevant/up-to-date once WebAssembly is more common? Are we going to see more web stuff built with c++, like the dsp example in this blog post?

[sjrd]

I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the people who create compilers to WebAssembly.

Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said language.

To answer your other question, I most certainly hope we won't see "more Web stuff" built with C++. C++ is a terrible language for that. It's a very good language to do stuff that needs predictable high performance such as games. And games is a good market for C++ in the browser through WebAssembly. But other than that I hope other, more high level languages will pick up.

[k__]

I guess the first ones jumping on the WebAssembly wagon will be Web developers, so we will probably get WASM modules written in languages they see appropriate, when JS doesn't cut it anymore.

I guess it will be Rust or Go.

Rust because of Cargo (for npm users a big +) and Mozilla (good marketing of Rust).

Go because of Google (also a Web company with good marketing) and because I read some Node.js developers already switched to Go before WASM.

[flohofwoe]

You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of a minimifed JS blob you'll load a WebAssembly blob.

[CryZe]

Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaScript. So until those are a thing, it'll be extremely ugly to work with WASM Libraries in JavaScript.

[skybrian]

It seems too soon to worry about it, unless you like to work on compilers in which case have fun! If you don't, you have to guess what compile-to-WebAssembly language will become popular. So maybe just learn new languages if you enjoy that?

If a popular web library uses it for something real, they will probably provide a JavaScript API to call into it.

[butabah]

To your second question, WebAssembly shouldn't be affecting your day-to-day standard frontend development, unless you're developing very performant applications like games, simulations, etc.

For resources, MDN has a great introduction. Pretty up-to-date too. [1].

[1] https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wa...

[jjn2009]

A good way to gauge this is maybe looking at the app ecosystem and seeing how many apps rely on lower level APIs to perform their tasks.

[draw_down]

It seems like more of a compilation target than something you'd have to worry about much when writing JS.

[camus2]

WebAssembly is a medium for ASM.js apps, and ASM.js apps are mainly C and C++ . You have to learn C and C++ period.

[dasmoth]

Right now, that's probably the best way to go if you're keen to build non-trivial wasm stuff, but I don't think it's a foregone conclusion that it'll stay that way. There's a Rust implementation now, for instance. And some talk of better support for garbage collected languages.

[dragonwriter]

> You have to learn C and C++ period.

You can program in wasm's text format (the actual assembly language) directly, if you want, and you can program in anything that compiles to wasm. C/C++ have the most developed toolchains for higher (than wasm itself) level languages, for now, but that should open up.