Intro to WebAssembly
codelitt.comThe official FAQ specifically states the opposite of the second bullet point.
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.
> Web Assembly is not meant to be a replacement for JavaScript.
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 don't think you should even aim for DOM integration, DOM sucks for apps, having to go trough JS bridge when you need to use it is fine.
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)
JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.
I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS.
That being said, I hope I'm proven wrong.
I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box.
Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.
Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight.
Future web applications will be mainly plain WebAssembly + Canvas + WebGL.
There is a tradeoff between development speed and execution speed. For web apps, development speed is usually the most important of the two and the language ironing away the most technical details tends to be a strong choice.
Roughly speaking, C is further from the metal than assembly (and WASM) for obvious reasons; Java is further from the metal than C (or Rust) due to having garbage collection, and Javascript is slightly further from the metal than Java due to abstracting away threads (the gap was far wider before Java got lambdas). LISP, of course is off the scale due to abstracting away readability ;)
On a serious note, though, I don't see the advantage that Java or Flash or Silverlight would bring to web apps unless they bring greater development speed.
But I do see WASM as an excellent future supplement to JS-based apps, for optimizing time consuming parts of the code.
It will be like Unity, Unreal do nowadays, and how many plugin runtimes used to do in the past.
The productivity of doing WPF/XAML development with RAD tools like Blend, using an export button to generate an WebAssembly executable.
I might be wrong, but that is where I see it going to.
But that's already possible today without WASM. E.g. there are react plugins that render to canvas, as being used here together with some WebGL: http://www.anagram.paris/ (try to drag). And yet, we don't see this often being used. Instead, we see more DOM being used on new places (e.g. electron applications). I think if WASM+Canvas would be the way forward, we'd have already seen it by now, since it was already possible in plain JS or with asmjs if you really hate JS that much.
In the end, HTML & CSS is fast enough for most business-style applications and frameworks like angular/vue/react are pretty good ways to make frontends.
Yes, but today it requires using JS or compiling into asm.js, which isn't always possible to keep the original language semantics.
WebAssembly is just yet another virtual CPU. more suitable as target for Go, .NET, Java, Flash, ....
They only need to target the framebuffer routines into Canvas/WebGL and we get desktop frameworks inside of a browser frame.
Won't using Canvas or WebGL to render all content kill accessibility?
Native UIs have better accessibility support than the browser.
They only need to bring them along with the plugins, to what would become a portable framebuffer.
I am totally with you on WebAssembly, but I think this is a valid point that can't be swept under the rug.
Screen-readers operating against native applications aren't even close to their utility in browsers. Easy, reasonably universal text hooking is only possible on Windows and some OSX applications and while screen-fetching is universal, it yields extremely poor results in comparison to hooking. Very popular applications occasionally build Narrarator, sythesisprompt or NDK support but today "the web" (specifically HTML) is a much, much better experience for the visually impaired.
the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.
Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards.
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.
Well on one hand you will definitely increase the number of ways to do DOM manipulation, but on the other isolated communities could move at different paces. I think its hard to say if the dominate mode of ui web dev will slow down, I've definitely experienced this fatigue, its a huge issue. Some how the unix way of small composable parts which work well needs to find its way to the browser.
If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.
>a restricted subset of JavaScript
This actually isn't the case. Browsers provide a virtual machine which can run assembly code with web assembly, its that simple, nothing about it necessitates javascript except that its the interface to the DOM, in the future it could very well be possible to have a new script tag type which is ASM and requires zero javascript or javascript runtime.
I didn't say WASM was a restricted subset of JavaScript. I understand that it is a lower-level virtual machine, and that in fact it provides some primitives that asm.js doesn't (e.g. 64 bit integers). My point was that if you're looking to WASM to be some kind of silver bullet, you've got the wrong expectations. The causes of people's JavaScript fatigue have little if anything to do with JavaScript the language.
> JavaScript is going to continue to be used as "glue code"
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.
If the author states that there are already a number of Hello World examples, why not spend a bit more time and create something else that's still simple enough?
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.
That's fair feedback. There will be a part 2 where we will dig in more. As I mentioned in another comment, it's eating an elephant. 1 bite at a time.
I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly.
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...
WebAssembly is in a large part about re-using vast quantities of existing C/C++ code in the browser.
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.
I tend to agree with you in the context of porting existing C/C++ code to the Web is going to follow exactly the pattern you mention.
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!
For me Rust is a deja vu experience, in a certain sense.
I started to use C++ around 1992, on MS-DOS, as my next loved programming language after Turbo Pascal. Never saw any value in plain C, other than writing code unsafer as straight Assembly (Assembly has less UB than C).
Have taken part in C vs C++ flamewars on Usenet since those days, only to see C++ finally overtaking C in many fields in the last 10 years.
In some fields, like embedded programming, C still reigns over C++.
So while I look forward to have my managed languages, OSes and performance critical libraries written in a safer language, my life experience tells me it will take a few decades to achieve the same level of market adoption.
By no means do I believe it will overtake these other languages quickly. But one huge benefit that Rust has over these others is this idea of "fearless programming". Watching Ruby Devs jump into Rust, fight the compiler for a bit, but then have a blazing fast app with some very detailed systems level interaction, is amazing. On top of that, it never segfaults!
Jumping into C and C++ is in my own experience, much more difficult. All of the complexity of those languages disappears into the Compiler in Rust. I think the big thing here is that Rust can appeal to many developers from all walks, not just those of us who've spent years or decades with Assembly/C/C++.
I agree, but also feel a bit sorry for Ruby devs, in the sense that they could have had that experience with Dylan or even with Apple's short love with a Ruby AOT compiler (which eventually became RubyMotion), while staying in Ruby.
Rust's compile-time safety guarantees are a lot less appealing if the generated code runs ins a sandbox anyway. If the C/C++ code compiled down to wasm goes haywire it is not a security concern, 'only' an inconvenience for the user.
I mean, security issues are just a class of bug. Just because the sandbox keeps you for causing more damage when you stomp on yourself, doesn't mean there's not value in not stomping on yourself at all.
Rust is a great language, but it appeals to a very specific set of engineering goals and a specific type of programmer who wants a lot of control while also wanting strong guarantees. So far, the web has provided neither. So for this reason, I think Rust adoption on the front-end will be slow, but still meaningful.
I like the idea of WebAssembly too; it is another kind of VM code. However, is there a C API to WebAssembly? Having a JavaScript API that is usable in both HTML and Node.js (and could easily be added to any other JavaScript too) is good, but a C API can also help (and I have written on some file on my computer what are some ideas for making a C API).
(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.)
It's like asking "is there JavaScript API to JavaScript".
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
b) is what I meant. I know that would not have been the original intention but I still think it can be useful in some cases, and there does not seem anything wrong with it. (It clearly wouldn't be for static linking WebAssembly codes with C codes, like what you might do with JavaScript, although it can have different uses.)
DOM manipulation isn't currently supported, for now you will need to provide a javascript layer between the C code and DOM. Its in the roadmap to create these interfaces.
Web assembly is better suited for CPU intensive tasks which you would want to offload from javascript but keep on the client.
I think that DOM manipulation should not be a part of WebAssembly, although the other way around may make some sense, where for example, the "window.wasm" property might be a WebAssembly module for accessing the HTML DOM (otherwise the module is not included and the WebAssembly code is sandboxed and cannot access DOM). If the WebAssembly module is loaded directly using a "script" tag in a HTML document, then it can automatically include the HTML DOM module.
Its inevitable that all of those who want to replace javascript will push facilities into the web assembly spec to remove javascript from the equation.
Is anyone experimenting with using WebAssembly in non-web contexts? Could be great for cross-platform native apps, microcontrollers, etc.
What benefits do you expect? Which of them aren't provided today by JVM or .Net?
Looks great! I'm looking forward to exception handling support.
i read it but it does not really explain wasm the language.
This was just an intro. There will be a part 2. It's a pretty large subject.