They often forget to mention, that WebAssembly is just a low-level programming language (much lower than C), it has extremely simple syntax (it has just four data types, no system calls, the specification takes 5 pages instead of 500 pages of C spec). You may call it a "bytecode", but typical bytecodes also have around-500-page specifications.
Also, its relation to javascript is not any bigger than the relation to any other programming language (i.e. there is no relation). A WebAssembly VM could be made as an extension of any environment.
I think your claim is right, but be wary about spec page counts. They blow out with age.
As time goes on, more pages are devoted to nailing down corner-cases, and retroactively legislating either for or against assumptions had previously been common sense until someone in the real world violated them.
WASM will see such growth in time. Think of how simple HTML was once upon a time.
There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it.
The other side of that, then, is the great potential for interop that Javascript offers. We now have a worldwide platform with a built-in presentation layer and a highly-optimized interpreter with useful, reflectable data structures out of the box. (edit i.e. it's a viable platform for metaprogramming... the endgame of which is JS-in-JS (see "prepack")).
I would love to see a future in which the browser (and "personal" computer generally) remained a locus of significant computation. In practice, I suspect that highly-intensive tasks (mostly AI stuff) will continue to be done on servers, not because we lack the processing power, but because end users will have signed away the custody of all data worth processing. If that is the case, then WASM's role will be to fill a fairly marginal gap, between what JS can do, and what has to be farmed out anyway.
So ultimately I hope that WASM offers a lifeline to the computing power that individuals still have. But given the state of JS (after huge investments), it feels like starting over again.
Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS.
Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore.
My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly demands more features and faster execution. The only logical conclusion is that the web browser will become an operating system.
I'll find it really amusing when devs outside the frontend world will storm in, devs who currently hate working with the browser because of JavaScript. The problem they will face is that a nice UI will still be needed. Since they will probably hate the DOM even more than than JS now they can just omit it. A canvas is canvas, right? :)
But then the next obvious problem will kick in. What should we use to implement a UI. GTK? WxPython? Swing? Tkinter? QT? JavaFX? Great candidates :) It will just be great. I mean not, but it will happen, because JS and "browser tech" is considered sub par (not by me, but I keep reading this).
WebAssembly will bring in lots of innovation, opportunities and also create the next level chaos. We will look back to the tooling hell as the good old days of frontend development :)
In 20 years of software development and trying different platforms, JavaScript has been the most frustrating and the most rewarding of all of them.
I find a lot of value in using JavaScript as a cross-platform shell. I personally do a lot of work on all of the major operating systems. I primarily (a light primary, like maybe 67%, not 90%) work on Windows, but most of my users are working on macOS. And we're all writing software that eventually has to run on Android. There is almost never a problem I can't solve using a JS project of some kind. That's the rewarding part. I feel like my software goes a lot further on the JS platform than it could have ever gone on any other.
But it's frustratingly slow. A lot of that is the poor quality of a lot of the libraries that are available. I'm not really keen on writing my own HTML templating system, but I'm afraid I might have to just to get the performance targets I want (I static-gen almost everything).
And I often feel like the language is not doing enough to help me. I love writing metaprogrammable systems, but the lack of easily accessible, standardized, advanced type information in JS is a big impediment to that. Sure, I can enumerate all of the methods an object has available to it, but there is no good way to enumerate the parameters those methods take, their return type, or even that they are methods, if I ever happen to get a reference to one of them sans the object from which it came
And yes, I still do object oriented programming. But the functional story in JavaScript is not any better. With map, filter, and reduce being methods on Array, coupled with JS's goofy OO semantics where methods can become detached from their objects if they aren't explicitly bound to them, things become frustratingly verbose to get basic functional patterns to feel good.
So a WASM that let me build better dev tools, in better languages, without losing that cross-platform capability, would be a godsend. Having it run in the browser also is just icing on the cake at this point.
> 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.
Does this worry anyone else? Or I am getting worked up over nothing?
Static languages can compile to wasm. Low-level runtime implementations of other managed languages which don't mesh well with JS backends can compile to wasm.
Yeah, it's of moderate concern. I can see why it's not really a priority here, since they're probably targeting languages that already don't have GC to compile into WASM, like c++ as a canonical example. I have to imagine that GC is also a pretty huge section of performance / JIT compilation problems in the javascript runtime. So shipping a spec that doesn't support it is no worse than allowing statically compiled code to run on desktop computers.
That said, I wonder how the WASM runtime is sandboxed. Not having a runtime-provided memory manager makes me worry not just about memory leaks, but also about explicit shenanigans in different memory zones. It's hard to believe that a WASM runtime doesn't protect against this sort of escaping though, so it's more of an academic wondering than a real concern.
That only means that for now, languages will have to provide their own garbage collectors, like Go initially implemented their garbage collector in C which is a language that manages memory manually.
after reading many tutorials about WASM I still figured out one of the most important questions for me:
Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds.
Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know what would I need the performance if I cannot access the most performance demanding APIs.
Wasm has explicitly declared imports & exports, so that it can be called from, and call into, both JS and other wasm modules. I haven't seen anything regarding dynamic linking, but just linking these declarations at wasm module start time.
The interface should take care of all type conversion between wasm and JS primitive types (notably varying integer sizes and JS floats). wasm's 64-bit integers will likely not be allowed across a JS<->wasm interface.
It seems like it would be a little backward to go from WASM to javascript in order to invoke native code (in e.g. an OpenGL driver). More likely WASM will have some way of its own to interface with such things. Right?
Oh cool, the text format[1] appears to be s-expressions!
Sounds like an easy dump from AST to text to wasm. Aside from what the Google Closure Compiler provides, I wonder what benefit, if any, this may give to ClojureScript. I'm guessing CLJS will just keep Google Closure for its optimizations, while Google Closure will output either wat files or wasm files. Unless optimizations can just be done during wat to wasm, which would be ideal for other language authors who can just translate to their intentions and not have to worry so much about fancy optimizations. (I'm rambling at this point. Sorry.)
The issue is that JIT js is hard to improve performance on because it's a dynamically typed language. Even with Web Assembly, something will still need to compile down into the bytecode to run. So perf is going to depend on that step in whatever language you write in and how easily that converts and optimizes into web assembly standards.
Does this mean that strongly typed languages have a performance advantage, given that they will be able to easily compile down into optimized typed bytecode?
As an anecdote: I had been running a Z80 emulator on my website (http://8bitworkshop.com) and I began to notice persistent 30-second delays on Firefox. It was difficult to track down, but I suspected the Z80 interpreter which had a gigantic switch statement. The optimizer must have been choking on it.
After refactoring each opcode handler into separate functions, it now runs with several subsecond delays on startup (as the various code paths are discovered and optimized, I suppose) and with no delays after a minute or so.
WebAssembly won't have this problem (neither does asm.js, but that's a different story...)
The generalish difference between JS and native code languages like C is about 10X. This varies from around 2X to 50X depending highly on what you're doing.
WASM should run at native speeds minus some special CPU instructions like vector stuff. So about as fast as highly optimized bytecode languages like Java, maybe 20% slower than optimized C.
One of the small things that may impact speed greatly, is that WASM has a real integer type, it isn't a float like JS has.
Some benchmarking has been talked about before [0], the upshot being C->WASM has a slowdown around 16-25ms. That's a hell of a lot faster than JS in a lot of places.
Unfortunately, as soon as you hook into the HTML APIs, like giving JS a result, you're back to JS speeds.
Well, possibly no faster than can currently be achieved by asm.js if the JIT likes you, but I think discussions of raw speed miss the point.
1. Parsing text based JS is much slower than parsing something like WASM.
2. Initialising data required for programs can take significant time in JS as that data is just a program that must be parsed and run.
3. Those first two points, along with better type support should help things get fast quicker, as the parser and JIT have less work to do.
4. In general JS comes with a lot of baggage that it's extremely hard to get rid of at this point, in many ways it's not really a great foundation to build other things on.
Now, WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection or other facilities. I hope we'll end up with a successor or an evolution of it being the primary thing browsers interact with and JS simply being a language supported on it.
Currently browsers only support JS. If you want another language you have to transpile to JS or implement your language in JS, etc.
If the browser vendors were going to add another language I would have hoped it would be something so generic like LLVM instead of this WebASM which is too tied to JS.
LLVM bitcode doesn't make a great interchange format, because it's not really hardware agnostic, last I checked. Obviously you _can_ run it on hardware it's not created for, e.g. in an emulator or via some extra transpiling. But now you're introducing some serious inefficiency into the pipeline.
Same way you would C code. Tell the compiler you want to compile for debugging, and then connect your debugger to the running program. Marks in the code will tell your debugger what things are called and which line in the source code you are on.
JS today is often transpiled anyway, so you have to use some mapping to the source code to do debugging (eg. source maps).
Presumably with sourcemaps, same as you use to debug minified JS. I dunno how reliably that works in practice these days, but it's not a new problem by any means.
[+] [-] IvanK_net|8 years ago|reply
Also, its relation to javascript is not any bigger than the relation to any other programming language (i.e. there is no relation). A WebAssembly VM could be made as an extension of any environment.
I recommend reading the official paper https://github.com/WebAssembly/spec/blob/master/papers/pldi2... (I learned more than about 50 "essays" that I read about WASM in the past).
[+] [-] apo|8 years ago|reply
[+] [-] adrianratnapala|8 years ago|reply
As time goes on, more pages are devoted to nailing down corner-cases, and retroactively legislating either for or against assumptions had previously been common sense until someone in the real world violated them.
WASM will see such growth in time. Think of how simple HTML was once upon a time.
[+] [-] binji|8 years ago|reply
There's still some work to be done, but it is quite far along already.
[+] [-] paulddraper|8 years ago|reply
E.g. it's great for C, but not really for Python.
[+] [-] gavinpc|8 years ago|reply
There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it.
The other side of that, then, is the great potential for interop that Javascript offers. We now have a worldwide platform with a built-in presentation layer and a highly-optimized interpreter with useful, reflectable data structures out of the box. (edit i.e. it's a viable platform for metaprogramming... the endgame of which is JS-in-JS (see "prepack")).
I would love to see a future in which the browser (and "personal" computer generally) remained a locus of significant computation. In practice, I suspect that highly-intensive tasks (mostly AI stuff) will continue to be done on servers, not because we lack the processing power, but because end users will have signed away the custody of all data worth processing. If that is the case, then WASM's role will be to fill a fairly marginal gap, between what JS can do, and what has to be farmed out anyway.
So ultimately I hope that WASM offers a lifeline to the computing power that individuals still have. But given the state of JS (after huge investments), it feels like starting over again.
[+] [-] throwasehasdwi|8 years ago|reply
Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore.
My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly demands more features and faster execution. The only logical conclusion is that the web browser will become an operating system.
[+] [-] kowdermeister|8 years ago|reply
But then the next obvious problem will kick in. What should we use to implement a UI. GTK? WxPython? Swing? Tkinter? QT? JavaFX? Great candidates :) It will just be great. I mean not, but it will happen, because JS and "browser tech" is considered sub par (not by me, but I keep reading this).
WebAssembly will bring in lots of innovation, opportunities and also create the next level chaos. We will look back to the tooling hell as the good old days of frontend development :)
[+] [-] moron4hire|8 years ago|reply
I find a lot of value in using JavaScript as a cross-platform shell. I personally do a lot of work on all of the major operating systems. I primarily (a light primary, like maybe 67%, not 90%) work on Windows, but most of my users are working on macOS. And we're all writing software that eventually has to run on Android. There is almost never a problem I can't solve using a JS project of some kind. That's the rewarding part. I feel like my software goes a lot further on the JS platform than it could have ever gone on any other.
But it's frustratingly slow. A lot of that is the poor quality of a lot of the libraries that are available. I'm not really keen on writing my own HTML templating system, but I'm afraid I might have to just to get the performance targets I want (I static-gen almost everything).
And I often feel like the language is not doing enough to help me. I love writing metaprogrammable systems, but the lack of easily accessible, standardized, advanced type information in JS is a big impediment to that. Sure, I can enumerate all of the methods an object has available to it, but there is no good way to enumerate the parameters those methods take, their return type, or even that they are methods, if I ever happen to get a reference to one of them sans the object from which it came
And yes, I still do object oriented programming. But the functional story in JavaScript is not any better. With map, filter, and reduce being methods on Array, coupled with JS's goofy OO semantics where methods can become detached from their objects if they aren't explicitly bound to them, things become frustratingly verbose to get basic functional patterns to feel good.
So a WASM that let me build better dev tools, in better languages, without losing that cross-platform capability, would be a godsend. Having it run in the browser also is just icing on the cake at this point.
[+] [-] jbreckmckye|8 years ago|reply
[+] [-] vivin|8 years ago|reply
Does this worry anyone else? Or I am getting worked up over nothing?
[+] [-] white-flame|8 years ago|reply
Static languages can compile to wasm. Low-level runtime implementations of other managed languages which don't mesh well with JS backends can compile to wasm.
Webasm doesn't replace JS, it complements it.
[+] [-] thaumasiotes|8 years ago|reply
Of all the things you've ever encountered called "assembly language", how many supported GC?
[+] [-] pfooti|8 years ago|reply
That said, I wonder how the WASM runtime is sandboxed. Not having a runtime-provided memory manager makes me worry not just about memory leaks, but also about explicit shenanigans in different memory zones. It's hard to believe that a WASM runtime doesn't protect against this sort of escaping though, so it's more of an academic wondering than a real concern.
[+] [-] bigato|8 years ago|reply
[+] [-] tamat|8 years ago|reply
Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds.
Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know what would I need the performance if I cannot access the most performance demanding APIs.
[+] [-] white-flame|8 years ago|reply
The interface should take care of all type conversion between wasm and JS primitive types (notably varying integer sizes and JS floats). wasm's 64-bit integers will likely not be allowed across a JS<->wasm interface.
[+] [-] westoncb|8 years ago|reply
[+] [-] Rusky|8 years ago|reply
[+] [-] Slackwise|8 years ago|reply
Sounds like an easy dump from AST to text to wasm. Aside from what the Google Closure Compiler provides, I wonder what benefit, if any, this may give to ClojureScript. I'm guessing CLJS will just keep Google Closure for its optimizations, while Google Closure will output either wat files or wasm files. Unless optimizations can just be done during wat to wasm, which would be ideal for other language authors who can just translate to their intentions and not have to worry so much about fancy optimizations. (I'm rambling at this point. Sorry.)
[1]: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
[+] [-] jorblumesea|8 years ago|reply
The issue is that JIT js is hard to improve performance on because it's a dynamically typed language. Even with Web Assembly, something will still need to compile down into the bytecode to run. So perf is going to depend on that step in whatever language you write in and how easily that converts and optimizes into web assembly standards.
Does this mean that strongly typed languages have a performance advantage, given that they will be able to easily compile down into optimized typed bytecode?
[+] [-] amelius|8 years ago|reply
(Yes, I know, it depends. I'm just looking for a rough estimate.)
[+] [-] sehugg|8 years ago|reply
After refactoring each opcode handler into separate functions, it now runs with several subsecond delays on startup (as the various code paths are discovered and optimized, I suppose) and with no delays after a minute or so.
WebAssembly won't have this problem (neither does asm.js, but that's a different story...)
[+] [-] throwasehasdwi|8 years ago|reply
WASM should run at native speeds minus some special CPU instructions like vector stuff. So about as fast as highly optimized bytecode languages like Java, maybe 20% slower than optimized C.
[+] [-] shakna|8 years ago|reply
Some benchmarking has been talked about before [0], the upshot being C->WASM has a slowdown around 16-25ms. That's a hell of a lot faster than JS in a lot of places.
Unfortunately, as soon as you hook into the HTML APIs, like giving JS a result, you're back to JS speeds.
[0] https://news.ycombinator.com/item?id=13604537
[+] [-] Dangeranger|8 years ago|reply
One big benefit will be being able to compile from an array of languages down to WebAssembly and maintain performance.
[+] [-] vvanders|8 years ago|reply
[+] [-] aardvark179|8 years ago|reply
1. Parsing text based JS is much slower than parsing something like WASM.
2. Initialising data required for programs can take significant time in JS as that data is just a program that must be parsed and run.
3. Those first two points, along with better type support should help things get fast quicker, as the parser and JIT have less work to do.
4. In general JS comes with a lot of baggage that it's extremely hard to get rid of at this point, in many ways it's not really a great foundation to build other things on.
Now, WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection or other facilities. I hope we'll end up with a successor or an evolution of it being the primary thing browsers interact with and JS simply being a language supported on it.
[+] [-] petters|8 years ago|reply
Its single-threaded performance is essentially native, but I don't have the numbers.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] sova|8 years ago|reply
[+] [-] ericfrederich|8 years ago|reply
If the browser vendors were going to add another language I would have hoped it would be something so generic like LLVM instead of this WebASM which is too tied to JS.
[+] [-] bzbarsky|8 years ago|reply
[+] [-] Skuzzzy|8 years ago|reply
[+] [-] krallja|8 years ago|reply
Except Chrome and Firefox, which both support WebAssembly.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] backtoyoujim|8 years ago|reply
[+] [-] acomjean|8 years ago|reply
[+] [-] hmottestad|8 years ago|reply
JS today is often transpiled anyway, so you have to use some mapping to the source code to do debugging (eg. source maps).
[+] [-] mrec|8 years ago|reply