I can totally see Qt a and .NET apps running on top WebAssembly. Imagine MS Word is running in your browser without them having to rewrite it in JS!
WebAssembly won't give you unlimited power. You will still have the browser sandboxing and security / privacy policies in place. Accessing to the local file system is for instance constrained in the browser for good reasons. WebAssembly apps will be able to do what Web APIs let any page do.
Not a problem, we can just wait for the inevitable security vulnerabilities.
> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many peopl…
There are a lot of developers -- a huge amount, actually -- who believe memory management is too important to leave to an automated GC algorithm. That, and the memory requirements of a particular application might require something different than a GC provides.
I'm a HUGE fan of Scheme. And of Lisp, in general. But having seen in the "real world" how so many people are so adverse to Lisp's beautiful syntax, I'm pretty confident that JavaScript would never have caught on if it looked like Lisp rather than like C.
They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)
You underestimate the average programmer's aversion to Lisp syntax, despite it being the clearly superior syntax.
If JavaScript had had Lisp syntax, then everyone would still be using Flash. Or some other plugin that provided a language with a more popular syntax.
I can totally see Qt a and .NET apps running on top WebAssembly. Imagine MS Word is running in your browser without them having to rewrite it in JS!
Yay! Nothing improved for me as a consumer, but total control of the app by Microsoft (it runs on their website and I don't even own my own copy) and slower speed (because of the extra VM and sandbox). Can't wait!
> Nothing improved for me as a consumer
Nothing to install, no updates, no license key, not tied to a machine.... ?
I really hope web assembly takes off and becomes a thing wide implemented in all the major browsers. The web is such a fantastic application platform (despite its frequent misuse...), and removing the javascript performance tax will be huge.
The W3C spec is now finalised and locked in, and Chrome and Firefox will release Web Assembly completely in their next releases, respectively.
I'm a HUGE fan of Scheme. And of Lisp, in general. But having seen in the "real world" how so many people are so adverse to Lisp's beautiful syntax, I'm pretty confident that JavaScript would never have caught on if it looked like Lisp rather than like C.
They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)
> They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript.
If people disliked the syntax enough to avoid the language (and the browser that uses it), I imagine that other browsers would've started supporting other languages, and something else would've dominated.
> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many peopl…
At least in Rust's case, RAII/lifetimes provide mostly the same development experience without GC overhead.
> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many peopl…
You don't have to go back to the 80's to develop closer to the metal. Neither Rust nor Swift have garbage collection, but both are thoroughly modern, productive languages. I've also been told that C++14 is reasonably pleasant, but I have no personal experience with which to judge.
Swift is garbage-collected – it might not have a tracing GC, but ARC is essentially compile-time GC – certainly, from the perspective of a developer, ARC is extrordinarily similar to a tracing GC (with some small caveats).
What's the point if you can't interact with the DOM?
Almost all examples of webassembly just render to a canvas.
Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?
> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…
You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).