WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer.
That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use.
wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)...
As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.
"In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1]
"Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2]
I figured this would be the case. This fact will contribute to lots of interesting discussions in the future regarding whether or not we should move away from JS and if so, how. Obviously having something like React is still hugely beneficial for reducing the logical complexity of creating UI, but you'd need to reconsider how you'd write your components without JSX or perhaps some language agnostic version of JSX would need to be created.. Or maybe we just implement E4X type syntax in other languages.
"Beyond the MVP" is the key phrase here. The first version of webassembly will not be able do that.
Just like it won't have dynamic linking, SIMD, shared memory (pthreads) or support for garbage collected languages.
It's worth noting that those features were already on the path to being added to it asm.js before webassembly was even being worked on. Most of them are still going to make it to asm.js first.
That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use.
wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)...
As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.