WebAssembly should be the most important thing to implement

As you can see in this article . WebAssembly will be the new standard and will finally provide us near-native performance for web.

Even Unity will support it. It would be a shame that the new Scirra product that is focused in web, to not do it.

Actually, i think that does not make sense to Scirra writes a new runtime and let WebAssembly aside.

WebAssembly is the future of web games/apps.

I assume the new C3 runtime will be capable of exporting to WebAssembly? The trouble is that Microsoft browsers do not support WebAssembly at this point, BUT Microsoft just announced support for it in their latest Edge version (albeit behind a experimental flag):

tinyurl.com/laetjcm

It works really well. The upcoming version 3 of Godot will also support direct WebAssembly export, as explained here:

tinyurl.com/lhbq8ko

I'd be very surprised if Scirra would not support WebAssembly as an export option.

The engine would have to be rewritten from the ground up, including plugs. In a different language.

It's basically the same as asking for a native export.

Our latest blog post details our thinking on this, including a run-down of some of the downsides of WebAssembly.

Don't ignore those downsides and tell us to do it anyway, that's not useful feedback.

The engine would have to be rewritten from the ground up, including plugs. In a different language.

It's basically the same as asking for a native export.

I read up on the subject a bit.

tinyurl.com/jy5dr2c

Seems like WebAssembly (webasm) is meant to allow C/C++ to be compiled to run in a web browser.

Newt, you are correct, it would be like asking for a native exporter level of support. That is why Unity and Godot (and other game engine) are relying on webasm: to have a relatively easy port of their native exporters!

It would be sour cherries for Scrirra to swallow when it turns out that competing game engines' native exporters ported to WebAssembly perform better than hand-written native asm javascript and canvas in the browsers.

A static language converted to webasm executes faster than javascript converted to webasm. That is saying that Construct 3's javascript is converted to webasm in the first place, which is not the case, right?

And since javascript (asm) is JIT compiled (meaning it must be parsed, typechecked, interpreted and finally compiled) it will be slower than webasm, which is parsed and then compiled. According to the linked article a 5% speedup is already the case, with future speedups expected.

The conclusion is that competing game engines will (probably) offer better performing web games with improved predictability because they have native exporters in the first place which are ported to webasm. Isn't that ironic?

Of course, in practice it will probably not make much of a difference for most games, going by what Ashley says in his article. I do suspect that it may matter for lower spec'd hardware.

One thing that does stand out as being one of webasm's advantages: security. Since it runs binary/bytecode the browser's console window can no longer be abused to hack into a game's code that easily.

Is this correct?

One thing that does stand out as being one of webasm's advantages: security. Since it runs binary/bytecode the browser's console window can no longer be abused to hack into a game's code that easily.

Is this correct?

Probably.

It's kind of hard to say for sure how it will be integrated into browsers.

There might be some exposed code, but the ability to manipulate it will most likely be limited.

You have to remember its just for browsers, so without knowing that it will have wrappers, it's kind of limited.

That is to say that if the current trend of pushing apps into browsers does not become more common.