Hacker News Reader

Comment by coolmitch | Hacker News Reader

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?

View on HN

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.

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.

I think if the web assembly experiment succeeds it will spawn new languages that become wildly popular. The web is huge, and client side programming is just a different animal.

Doesn't WASM need GC support before Go can be used? It'll need to be fully managed languages until then, I think.

With that said I'm just parroting some other comments I've seen on this topic in other contexts, so I'm asking the question genuinely.

> Doesn't WASM need GC support before Go can be used?

Why can't the Go implementation can have its own GC, the same as the Go implementation for, say, x86 does?

It's possible but will run much slower with some of the restrictions in webasm.

Incredibly interested in the answer to that question as well. Go will not have a future in regards to web development if they don't find a solution for the GC issue in wasm. I assume (and hope) that's a bigger topic compiler-team internally as well currently.

FYI,https://go.googlesource.com/gollvm/

Interesting, thanks

A lot of current experiments seem to be the other way around. People with C/C++ projects porting them to WebAssembly. This is partly due to the initial limitations in the current version though.

I'm not a web developer but this has definitely peaked my interest to the point I've been dabbling with WebAssembly. It's really easy to get going so I could see a lot of people with other than WebDev backgrounds getting into application development in the browser.

Rust already supports compiling to wasm as well.

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.

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.

I think emscripten does this by keeping dictionaries on the Javascript side which map numeric "ids" (used on the asm.js/wasm side) to JS objects. This is how mapping a GLuint 'texture id' to WebGL objects works for instance. The JS object won't be garbage collected as long as it 'pinned' in the lookup dictionary, but as soon as the asm.js/wasm side manually release the handle, the JS object will be GC'd. Future APIs (like the a WebGL successor) will hopefully provide 'garbage free' APIs so that they don't require keeping such helper structures around.

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.

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...

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.

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

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.

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.

> 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.

Reply on news.ycombinator.com