Will WebAssembly replace JavaScript for most games?

[vornay]

Now that Safari/Firefox/Chrome support running WebAssembly, will it replace Javascript for writing "HTML5 games"?  It will be smaller, cross-platform, run much faster, and be coded in C or C++.  

https://en.wikipedia.org/wiki/WebAssembly

 

[Antriel]

Once the global coverage hits certain level (right now mobile browsers don't seem to support it yet), certain games will definitely use it.

Whether it will replace JavaScript, probably not. JavaScript will still be enough for a lot of uses, possibly some libraries might get a WebAssembly build, but the game code could still be JS. Among the first adopters I would expect people using languages like Haxe, where it should be possible to provide both JS and WebAssembly builds, letting the browsers use whichever they support.

I don't see many people, at least not for small web games, using C++ directly. More likely some higher level languages, like C#. It will all depend on what frameworks will be available. Eventually I would expect all bigger frameworks that already support .c target, to add WebAssembly target.

[mattstyles]

The naive thought here is that, wow, WASM will speed up all the things, the reality, however, will be very different.

Whilst some applications are CPU bound many are not, even gaming, hence why many people extol skimping on the CPU and using an i5 for gaming. Given that the browser has the same access to the GPU as any other application running (albeit with a slightly different engine running it) I'm still surprised we aren't seeing higher detail games running in browsers, I guess its a data problem in so much as better graphics usually mean much more upfront loading.

WASM will help in many situations, but not all. In many cases JS is easily 'fast enough'. Transpiling from one language to another is not without its pitfalls either, ask any JS developer who has done a hybrid app, particularly those that need integrations with the OS, and you'll hear how many tricky cases there are that would simply disappear if the app had been written natively (yes, this example isn't wholly reflective of transpiling to JS/WASM from a different language).

[Jammy]

WASM looks better suited for enterprise, script kiddies like me will stick with JS for simplicity

[mattstyles]

Enterprise won't touch it for a while, not until it stabilises and matures a little. Same with all things, although that is slowly changing.

[away168]

If it's faster then why not. The only problem right now is, it is new.

C/C++ has been around for long, and engines such as Unity and Unreal Engine for HTML5 builds have been longing for this to become worldwide default and I'm happy to switch over when that happens. As long as it is faster and better for both dev and runtime, I'm there.

[bruno_]

Even if you keep writing your code in JS, you could import libraries made in C++ from others with web assembly.

For game engines and graphic processors that could mean a performance improvement without changing your code.

[Raggar]

I was actually researching this yesterday. It's one of those things I like to keep up with every few months.

Personally, I'll stick to Javascript and current engines. I'm also pretty sure that the time it would take me to properly learn a new language like C/C++, could otherwise be spent learning general Javascript optimization pipelines. I'm not convinced, although I still think the technology is fascinating. Maybe one day.

[BobF]

WASM will be very useful for replacing chunks of high runner JS code that cause an app to become CPU bound. But beyond that I think JS will be preferable for most devs. Things to consider:

• C++ is *very* different from JS. Don't underestimate the challenges of things like memory and pointer management. C++ produces fast binaries, but it's also easy to hang yourself.
• Will there be an efficient means of debugging WASM code?
• If WASM code throws an exception will a usable stack trace be provided?
• Will WASM have access to the DOM? The internet?

I'm glad WASM is available, but JS code will be more robust and maintainable, so I plan to be judicious with my use of of C++.