Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all.
JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really important to make this distinction.
Trying to use web assembly as a solution to problems it's explicitly not meant to solve is only going to lead to pain and frustration.
Furthermore, things like "static type checking", easy functional programming, and making application coding "less painful" aren't really goals as the post seems to make them out to be as well.
This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM.
And yes, DOM integration isn't there right now, but it will be. It makes sense to me that this is initially being limited for a number of reasons. It definitely means people won't immediately glob onto it, reducing the potential of accidentally locking in implementation bugs/features.
Some people think the DOM is unnecessary even in a webassembly world, but I think CSS and the DOM are generally good, what I've always wanted is a better language option.
I'm practically giddy with the potential for all of this finally happening!
I would be much happier if they exposed APIs such as WebGL, user input, IO, etc. to WASM trough WASM specific APIs than wrapping JS ones (but doubt they will do it)
That being said, I hope I'm proven wrong.
Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.
But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code.
People talk about Javascript fatigue, and it's real and exhausting to keep up with the constant framework churn. But I think the biggest reason at the root of it all is Javascript. Nobody talks about Unix fatigue, and all the different languages and frameworks that you can use to build your backend services. When we have a truly open-ended platform to build on, we're not going to feel this fatigue, I don't think.
This is a temporary situation. Eventually you'll be able to do everythign in WebAssembly, including DOM access etc. How long that will take is anyone's guess but it's certainly on the minds of the wasm team.
As a self-taught programmer, one of the difficulties I found (before SO) was that the many articles one read up on would typically repeat what someone else said. This especially with new technologies.
I think if authors pointed us to an existing "Hello World", and then expanded on that, in the long-run, beginners would sometimes find it easier to learn fadter.
Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of these technologies are young, webassembly even younger, there's no big argument for legacy code in this context, which means adopting something new would be fine, and good in this case because of the safety guarantees.
Anyway, a great intro in general, but for anyone looking at getting into this, I highly recommend checking out the Rust tutorials, like this one: https://medium.com/@ianjsikes/get-started-with-rust-webassem...
C++ will dominate in that space over Rust for the same reason it'll dominate in all other spaces: the amount of existing C++ code and the number of existing C++ programmers will always dwarf the amount of Rust code and Rust programmers.
Even if Rust was uniformly 10-20% better than Rust, economics dictate that for most people it'll make most sense to continue with C++ than rewrite thousands or millions lines of code in C++ or embark on months-long retraining of large number of programmers, some of which will not be happy about going from being proficient C++ programmers to beginner Rust programmer.
And that's why we don't need to mention Rust when writing about WebAssembly. At this point in time it's immaterial to the subject.
But, for new software, with no previous dependencies? The stdlib in Rust is decent, and the ecosystem is growing quickly. For new projects, I do think these will help in it's adoption in a new environment like WebAssembly, but we shall see!
(I did not read the linked document much though, but only the official FAQ. However I do think you would not use WebAssembly all the time, but it can be helpful in some cases, including wanting VM codes.)
WebAssembly is a portable instruction set, a simplified CPU.
The main use case for WebAssembly is compiling C/C++ code to that instruction set using emsscripten, which is a clang-based C/C++ compiler that emits WebAssembly modules.
Depending on how you look at it, the answer to "is there C API to assembly?" is:
a) yes, that's the first API there ever was and it's the main API
b) the question doesn't make sense. C/C++ is compiled to WebAssembly, there's no API to it. You could imagine a system that would allow using WebAssembly modules from native C/C++ code, where you would need a C/C++ bridge to executing WebAssembly functions (similar to JavaScript bridge for calling WebAssembly functions), but this is not really why WebAssembly exists
Web assembly is better suited for CPU intensive tasks which you would want to offload from javascript but keep on the client.
