An Abridged Cartoon Introduction To WebAssembly(smashingmagazine.com)
smashingmagazine.com
An Abridged Cartoon Introduction To WebAssembly
https://www.smashingmagazine.com/2017/05/abridged-cartoon-introduction-webassembly/#
106 comments
Really helpful link. What's the current state of tooling to directly write WebAssembly? What assembler/editor/debugger you would you recommend?
Right now, "tooling" is quite the same as the tooling for Javascript. You can write your code in a Notepad and the web browser will tell you about errors.
WebAssembly has two representations: a binary form .WASM and a text form .WAST (with one-to-one correspondence). The browser environment can convert between them (or you can write a short piece of code to do it).
If you know C, this website may help you get familiar with WASM syntax: https://wasdk.github.io/WasmFiddle/ (when you press Build, the WASM code will appear at the bottom).
WebAssembly has two representations: a binary form .WASM and a text form .WAST (with one-to-one correspondence). The browser environment can convert between them (or you can write a short piece of code to do it).
If you know C, this website may help you get familiar with WASM syntax: https://wasdk.github.io/WasmFiddle/ (when you press Build, the WASM code will appear at the bottom).
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.
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.
HTML got complicated because they modified the assumptions whenever they were violated, to make the violation into a working case.
Specs grow much more slowly if, in response to such non-conforming implementations of a processing stage, they just codify the common sense, and maybe give methods for detecting the non-conforming outputs and rejecting them. XHTML is not a large spec.
Specs grow much more slowly if, in response to such non-conforming implementations of a processing stage, they just codify the common sense, and maybe give methods for detecting the non-conforming outputs and rejecting them. XHTML is not a large spec.
Very true. But HTML is not unique in this regard, other standards have done this too.
I picked on HTML because it is also a foundational web technology. Many of its standards setters are the same people who will influence WASM, and many of the same incentives will be at play with WASM as with HTML.
I picked on HTML because it is also a foundational web technology. Many of its standards setters are the same people who will influence WASM, and many of the same incentives will be at play with WASM as with HTML.
You may want to take a look at the formal spec here as well: https://webassembly.github.io/spec/
There's still some work to be done, but it is quite far along already.
There's still some work to be done, but it is quite far along already.
Also: WASM is best as a target for languages that usually committee to machine code.
E.g. it's great for C, but not really for Python.
E.g. it's great for C, but not really for Python.
Many languages--like Python--are implemented in C, so it's a pretty natural chain-of-events to get from there to WASM.
[deleted]
I'm of two minds about WASM.
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.
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.
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.
People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them.
The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se. If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that could change at any time.
WASM also impacts the labor market, as you mention. But it's not, as we might like to believe, because programmers' demands for more freedom and expressive power are being honored; it's because, as monkmartinez suggests [0] (and maybe this is what you mean by "floodgates"), companies would rather not be limited to a smaller human-resource pool when developing web properties.
If I sound a little dystopian, it might be because I'm currently reading Cyber-Marx [1], an insightful book from 1999 about the "information revolution" and its relation to capital.
[0] https://news.ycombinator.com/item?id=14342983
[1] http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252...
The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se. If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that could change at any time.
WASM also impacts the labor market, as you mention. But it's not, as we might like to believe, because programmers' demands for more freedom and expressive power are being honored; it's because, as monkmartinez suggests [0] (and maybe this is what you mean by "floodgates"), companies would rather not be limited to a smaller human-resource pool when developing web properties.
If I sound a little dystopian, it might be because I'm currently reading Cyber-Marx [1], an insightful book from 1999 about the "information revolution" and its relation to capital.
[0] https://news.ycombinator.com/item?id=14342983
[1] http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252...
I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?
Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger reason to get behind efforts that increase the share of developers available.
Yes, I'm saying that this would not move forward without buy-in from non-programmers with influence. But language isn't the only thing. WASM is (correct me if I'm wrong) harder to reverse engineer, which must matter to those same stakeholders.
I don't see how it would be harder to RE than .NETs IL (which is pretty easy to RE), or even plain old assembly -- which looks horrible, but can be disassembled and even "decompiled" (which generates a potential C source from the disassembled bytecode).
I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now.
Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.
I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and secondly the speed of development. As much I complain about writing js code, it's a lot faster to get things done compared to Rust/C++.
Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.
I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and secondly the speed of development. As much I complain about writing js code, it's a lot faster to get things done compared to Rust/C++.
You might be right about C++/Rust but I hear constant complaints from C#, Java, and Go devs about JS. It feels like about half of them would jump ship immediately given another choice. The truth is that even with all the advancements JS has made the tooling and features are still years behind some other mainstream languages.
The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.
The transpilers don't work that great and don't produce standard bytecode, in this regard WASM will be a game changer.
> Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.
Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs.
That's before you even get into the idiomatic differences between languages and libraries.
Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs.
That's before you even get into the idiomatic differences between languages and libraries.
Alternate hypothesis: at least as of right now†, Web Workers still don't support thread-like behavior. If I wanted to program e.g. a game in C++ or Python, I'd be pulling in an engine and some libraries that all expect to have threads available. This code would not transpile.
You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation.
If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web.
† https://kripken.github.io/emscripten-site/docs/porting/pthre...
You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation.
If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web.
† https://kripken.github.io/emscripten-site/docs/porting/pthre...
I wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS.
The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon excited with hiring a Python|Ruby|Lua|Rust|C# developer that could talk natively to the browser? My guess is a LOT.
The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon excited with hiring a Python|Ruby|Lua|Rust|C# developer that could talk natively to the browser? My guess is a LOT.
On the one hand, I hear you and don't disagree - programming ergonomics is a big deal, and access to the language you like is important. I for one really don't want to program in a language that uses significant whitespace, if I can avoid it.
On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's moving fast because new ideas are evolving at speed (functional-reactive approaches, new ways to think about mixins vs multiple inheritance, etc), and those ideas lead to new framework architectures gaining popularity as they exploit these new ways of thinking about organizing data flow through a complicated system.
Couple that with some baseline things that aren't changing here - you're still going to have to interact with the DOM, you aren't going to magically get re-entrant multithreading, and the event model isn't changing. There's still going to be a lot about web programming that feels different from systems programming, and things are still going to move quickly. Probably even more quickly (but I'm not certain about that - I imagine one major reason JS shifts quickly is that it has so many programmers working with it, if the population fragments there will probably be a number of slow-moving communities that neither shift often nor take advantage of new features, which feels like the kind of neophile - neophobe split that's already apparent in different areas of programming).
So: I am not convinced that a (say) rust or go compiler to WASM will suddenly make front-end programming feel like systems programming. It'll be a new language, sure, but there's a lot more to web development and the (reasonable) complaints people have about a shifting landscape than just javascript and its funky definition of OO and triple equals sign.
On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's moving fast because new ideas are evolving at speed (functional-reactive approaches, new ways to think about mixins vs multiple inheritance, etc), and those ideas lead to new framework architectures gaining popularity as they exploit these new ways of thinking about organizing data flow through a complicated system.
Couple that with some baseline things that aren't changing here - you're still going to have to interact with the DOM, you aren't going to magically get re-entrant multithreading, and the event model isn't changing. There's still going to be a lot about web programming that feels different from systems programming, and things are still going to move quickly. Probably even more quickly (but I'm not certain about that - I imagine one major reason JS shifts quickly is that it has so many programmers working with it, if the population fragments there will probably be a number of slow-moving communities that neither shift often nor take advantage of new features, which feels like the kind of neophile - neophobe split that's already apparent in different areas of programming).
So: I am not convinced that a (say) rust or go compiler to WASM will suddenly make front-end programming feel like systems programming. It'll be a new language, sure, but there's a lot more to web development and the (reasonable) complaints people have about a shifting landscape than just javascript and its funky definition of OO and triple equals sign.
I am not sure I am qualified to really debate the merits of the JS ecosystem; perceived or real at this time. I tried to do front-end stuff when Knockout and Backbone were popular and Node was just starting. Maybe a better phrase is; I had a hard time keeping up... it was the paradigm changes (as you mentioned), but it was also the volume.
Paralyzation due to choice and only so much time to evaluate each framework. Couple that to "staying" power, that is, will this library be around in 6 months? I have taken a peek from time to time and been thoroughly aghast at the volume and not really seeing any of the old stand-bys around.
Now compare that to Python. There is no dearth of choice and one will find many of these choices have been around for more than a decade. They have evolved and changed of course, but not anywhere near the pace of JS. Again, I could take a 3 to 6 month break from looking at Python news and libraries... then come back and jump right into most of the libs I already know. Can a JS dev do that?
> Couple that with some baseline things that aren't changing here
Doesn't webASM give the power to abstract those things away? React creates a virtual DOM, right? Why can't Python create a virtual DOM via webASM?
I stand with you in that I agree things are going to move quickly once Python and others become peers with JS in the browser. I am sure it will be insane as everyone figures out which lib will have staying power like Django, or similar in another lang. I do think that people who generally gravitate toward languages like Python, Go, C#, Java will bring those attitudes with them... that is, they aren't going to re-invent the wheel every three months unless there is a super compelling reason to do so.
Paralyzation due to choice and only so much time to evaluate each framework. Couple that to "staying" power, that is, will this library be around in 6 months? I have taken a peek from time to time and been thoroughly aghast at the volume and not really seeing any of the old stand-bys around.
Now compare that to Python. There is no dearth of choice and one will find many of these choices have been around for more than a decade. They have evolved and changed of course, but not anywhere near the pace of JS. Again, I could take a 3 to 6 month break from looking at Python news and libraries... then come back and jump right into most of the libs I already know. Can a JS dev do that?
> Couple that with some baseline things that aren't changing here
Doesn't webASM give the power to abstract those things away? React creates a virtual DOM, right? Why can't Python create a virtual DOM via webASM?
I stand with you in that I agree things are going to move quickly once Python and others become peers with JS in the browser. I am sure it will be insane as everyone figures out which lib will have staying power like Django, or similar in another lang. I do think that people who generally gravitate toward languages like Python, Go, C#, Java will bring those attitudes with them... that is, they aren't going to re-invent the wheel every three months unless there is a super compelling reason to do so.
I think there's room all over for different kinds of ergonomics for software development. Languages play a big role here, for sure, and having access to more languages for the front end feels like it will be good by definition- more choices is usually better. There's a lot lot lot of new stuff for sure in JS, and it can be pretty overwhelming.
I think, though, that you could pretty easily take a break from JS dev and come back and still use the tools you had six or twelve months ago, just fine. For example, I maintain a pretty big angular 1 application that has a lot of pre-1.4 code in it. It runs fine, and I haven't touched my build tooling in over a year. There's still a lot of very relevant questions and answers on stackoverflow and so on.
Now, I may well want to use react or angular4 or something else for my next project, but nothing is stopping me from using angular 1, or backbone, or just plain jquery for that matter. They all still work.
As to the virtual DOM - abstraction libraries are really cool (although the vDOM isn't really that), but they introduce just yet another thing that changes over time. At the end of the day, the DOM is a pretty complicated thing, between its own structure, event models, css, and everything else, so the API to interact with it is going to be complicated no matter what language you use. Most frameworks (backbone, jquery, angular, react, etc) are all just different attempts to manage that complication, and all they ever really do is shove the complication from one place to another, but (for example with functional reactive models) that other place is something a group of people is willing to deal with.
I think, though, that you could pretty easily take a break from JS dev and come back and still use the tools you had six or twelve months ago, just fine. For example, I maintain a pretty big angular 1 application that has a lot of pre-1.4 code in it. It runs fine, and I haven't touched my build tooling in over a year. There's still a lot of very relevant questions and answers on stackoverflow and so on.
Now, I may well want to use react or angular4 or something else for my next project, but nothing is stopping me from using angular 1, or backbone, or just plain jquery for that matter. They all still work.
As to the virtual DOM - abstraction libraries are really cool (although the vDOM isn't really that), but they introduce just yet another thing that changes over time. At the end of the day, the DOM is a pretty complicated thing, between its own structure, event models, css, and everything else, so the API to interact with it is going to be complicated no matter what language you use. Most frameworks (backbone, jquery, angular, react, etc) are all just different attempts to manage that complication, and all they ever really do is shove the complication from one place to another, but (for example with functional reactive models) that other place is something a group of people is willing to deal with.
I agree that js world move fast but there is lot of reinvention of wheel and every new shiny thing have relatively small "payload". Also lot of things are just workarounds for js badparts. Currently I feel that js is out newest Java: clearly technically behind but since it has all the libraries it must be best forever. Of course ecosystem size has benefits but there more than just "they can't keep up with js". Es5 -> es6 -> elm, why bother with hot fixes when major update is available?
I'm very interested in the possibility of using a WASM VM as a unit of process isolation in an operating system. I actually kind of like Babel-compiled JavaScript, so I'm not as interested in WASM as a way to "get away from JavaScript", but the VM-based containerization possibilities (maybe with hardware-assist) are very cool.
Looks like Docker/Unikernel Systems actually has plans to build something like this: https://github.com/linuxkit/linuxkit/tree/master/projects/mi...
Looks like Docker/Unikernel Systems actually has plans to build something like this: https://github.com/linuxkit/linuxkit/tree/master/projects/mi...
Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?
Java applets were unfortunately ahead of their time for the hardware available and got a bad reputation for being slow, along with security problems, and now that Google extinguished plugins like Java and Flash (Google gets to skip the Extend step) we're stuck with whatever Chrome lets webasm do with no competition for this kind of VM-in-a-browser. The homogenization Google forced on the web is a travesty but everybody is too distracted by shiny new HTML5 features and the anti-plugin bandwagon to care.
Conceptually? It's not that different, and the only problems with Java were its implementation.
* Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing support for unsigned applets saying it'll increase trust, but what they really did was make the problem worse by killing the sandbox.
* Java was proprietary until long after its star had fallen.
* Java was introduced when computers weren't that powerful. The JVM took forever to start up and would slow down your whole computer while running. Most of us kept Java disabled unless we had to use an applet for something just because of the massive performance hit.
You can make similar arguments about Flash, too: it too had security holes, proprietary software, and performance issues.
There is one thing I really liked about Java and Flash, though: you could turn it off. If you don't want a site loading some heavy Flash monstrosity and eating all your RAM (I had so many issues with Flash killing the RAM on my old laptop with only 512 MB of RAM), you could just turn plugins off or install an extension to force you to click to load Flash content. You can't do that with JavaScript, so maybe WASM will bring that part of the old days back too.
* Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing support for unsigned applets saying it'll increase trust, but what they really did was make the problem worse by killing the sandbox.
* Java was proprietary until long after its star had fallen.
* Java was introduced when computers weren't that powerful. The JVM took forever to start up and would slow down your whole computer while running. Most of us kept Java disabled unless we had to use an applet for something just because of the massive performance hit.
You can make similar arguments about Flash, too: it too had security holes, proprietary software, and performance issues.
There is one thing I really liked about Java and Flash, though: you could turn it off. If you don't want a site loading some heavy Flash monstrosity and eating all your RAM (I had so many issues with Flash killing the RAM on my old laptop with only 512 MB of RAM), you could just turn plugins off or install an extension to force you to click to load Flash content. You can't do that with JavaScript, so maybe WASM will bring that part of the old days back too.
> you could just turn plugins off or install an extension to force you to click to load Flash content. You can't do that with JavaScript, so maybe WASM will bring that part of the old days back too.
NoScript?
NoScript?
I feel reasonably confident in predicting that WASM will have security holes and performance issues too. Computational demand always expands to fill the available performance.
Was there any point in the development of WASM where it made more sense to develop WASM to replace the JVM than it would have made to try fixing the problems with the JVM? Are we at that point now? It sounds like the last two problems fixed themselves.
Was there any point in the development of WASM where it made more sense to develop WASM to replace the JVM than it would have made to try fixing the problems with the JVM? Are we at that point now? It sounds like the last two problems fixed themselves.
I'd assume something like the conceptual difference between HTML5 canvas/video ("good") and Flash ("bad"). No plugins. Better sandboxing. Open specification not owned by some specific company. An expectation of multiple competing implementations.
Basically, it's a lot of the same stuff, but a (hopefully) better implementation, and promoted in a way that appeals to the people likely to use it. Start with an old technology. Tweak, relabel, and market under the new name.
Basically, it's a lot of the same stuff, but a (hopefully) better implementation, and promoted in a way that appeals to the people likely to use it. Start with an old technology. Tweak, relabel, and market under the new name.
Java applets have a radically different security model from Javascript and wasm. There's only thing that makes wasm any closer to Java applets than Javascript already is- it's distributed as a bytecode that's not dynamically typed, rather than text.
But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.
But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.
Wouldn't it be easier to change the security model on Java applets than to go through whatever the process of developing wasm is?
Perhaps, but there are other benefits to wasm than "lacks Java applets' downsides"- JVM bytecode is locked into the Java object model and garbage collector, while wasm doesn't impose any particular style of memory management. This makes it far more straightforward to use in high-performance situations than Java can ever be.
Java applets were far too ahead of their time. Now that we actually have the bandwidth and computing power to support Applets they would be far superior than the Frankenstein of CSS, JS, and HTML we have now.
Applets were confined to a horrible UI toolkit instead of working natively with the DOM
I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?
To make an analogy, right now it's possible to write and include C++ modules in your Python scripts, just like it's possible to do with WASM/JS. But people still use Python, because it's a much faster/easier way to get a specific kind of thing done.
So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.
So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.
So the next generation can't have nice things either :).
It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results".
(Lisp is definitely one, can't think of another on the top of my head).
It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results".
(Lisp is definitely one, can't think of another on the top of my head).
If only we had used Lisps for all the things!
We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity.
XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.
We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity.
XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.
It's not the overall objective but that's exactly the objective of a lot of people rooting for it. Think of how many people would be pissed off if they said "we're gonna try to replace javascript". Google did that with Dart and everyone gave them the finger... sunk cost fallacy.
Better to develop something for "performance" that just happens to be able to replace JS as a side benefit. Makes it a lot easier to swallow
Better to develop something for "performance" that just happens to be able to replace JS as a side benefit. Makes it a lot easier to swallow
So what you're saying is that WASM is a Trojan horse.
If you disagree with javascript losing dominance I guess you could say so. It's really just a way to make it easy to run whatever language you want in the browser in a cross-platform compatible way. I don't see this as a bad thing at all.
<excessive snark deleted>
At the very least, browsers are the new JRE.
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 :)
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.
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.
It sounds like you want to program in TypeScript.
TypeScript and I have had many bouts in the past. It is not the solution to my particular problems.
> 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?
Does this worry anyone else? Or I am getting worked up over nothing?
Dynamic, managed languages can compile to JS.
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.
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.
It seems like the normal thing to do would be to develop for a runtime that does feature GC?
Of all the things you've ever encountered called "assembly language", how many supported GC?
Of all the things you've ever encountered called "assembly language", how many supported GC?
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 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.
The addressable memory space doesn't include code, globals, stack, etc, but only that memory which could be considered the heap.
Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves it all compatible with using the MMU to trap accesses beyond allowed memory. The example from the paper linked elsewhere is that on a 64 bit machine, you can allocate 8GB of virtual address space, which covers the entire possible addressable range of wasm instructions, and use permissions to trap out of boundness. The very notion of allocating that 8GB already encapsulates memory sandboxing, as long as the addressability limits of instructions can't be usurped (and it's formally been shown to be sound).
Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves it all compatible with using the MMU to trap accesses beyond allowed memory. The example from the paper linked elsewhere is that on a 64 bit machine, you can allocate 8GB of virtual address space, which covers the entire possible addressable range of wasm instructions, and use permissions to trap out of boundness. The very notion of allocating that 8GB already encapsulates memory sandboxing, as long as the addressability limits of instructions can't be usurped (and it's formally been shown to be sound).
> The addressable memory space doesn't include code, globals, stack, etc
Really? In that case, how does a language like Rust, where stack allocation is used regularly, compile to WASM?
Really? In that case, how does a language like Rust, where stack allocation is used regularly, compile to WASM?
GP is referring to the call stack. It is still possible to use the WASM heap as a stack, by maintaining a stack pointer and a base pointer.
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.
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.
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?
Yes, JS and wasm can call each other. In the long run wasm should also be able to call web APIs directly.
Is wasm also restricted to running on one thread like js?
No, though neither is Javascript. (I am not sure how far along non-WebWorker-based wasm threads are, but here's the proposal: https://github.com/WebAssembly/threads)
Shared-memory threads are something I hope lands in WASM, since they're part of the reason you'd want to drop down to WASM in an application in the first place.
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.)
[1]: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
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...
Question...
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?
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?
Since JS is already quite fast nowadays, how much faster will WASM typically be?
(Yes, I know, it depends. I'm just looking for a rough estimate.)
(Yes, I know, it depends. I'm just looking for a rough estimate.)
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...)
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.
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.
And vector stuff (SIMD) is being planned. https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...
Edit: an even longer list of proposed features. http://webassembly.org/docs/future-features/
Edit: an even longer list of proposed features. http://webassembly.org/docs/future-features/
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.
[0] https://news.ycombinator.com/item?id=13604537
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
To start Mozilla has stated it can be up to 10% faster, but compiler optimizations will improve on that over the next few years.
One big benefit will be being able to compile from an array of languages down to WebAssembly and maintain performance.
One big benefit will be being able to compile from an array of languages down to WebAssembly and maintain performance.
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.
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.
> 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
Would it be possible to implement a garbage collector in WASM? And could it be a concurrent garbage collector, using advanced techniques such as memory barriers?
It would be cool if we could run e.g. Haskell or Go in WASM. Or even C programs which rely on the Boehm collector.
Would it be possible to implement a garbage collector in WASM? And could it be a concurrent garbage collector, using advanced techniques such as memory barriers?
It would be cool if we could run e.g. Haskell or Go in WASM. Or even C programs which rely on the Boehm collector.
Sure, why not implement a GC? There's a heap. You don't need much else.
I am running an integer programming solver in the browser with wasm: https://www.strandmark.net/wasm/glpk.html
Its single-threaded performance is essentially native, but I don't have the numbers.
Its single-threaded performance is essentially native, but I don't have the numbers.
[deleted]
Native
Does that mean Webscale?
edit: /s
edit: /s
Webscale? I don't know, and I am really unclear as to why people are already writing about webASM, there is hardly an agreed-upon standard so far. In my professional opinion as a Computational Scientist, I believe a LISP-like graphically-enabled DSL for the Web that worked simply and easily with: Web Forms, Graph Query for endpoints, and had a sensible GUI layering would be perfect for the next 200 years of screen.
I think that the issue comes in when people call it WebASM. ASM had different aims in 1960 than in 2017. In 1960 ASM was about minimizing register overlap and utilizing max CPU efficiency reels. Now, you have no idea what hardware your Web-whatever is going to run on, so how could you possibly optimize for CPU? The only real optimization would be optimizing software-engineer/developer attention+visualization and that would only come with an incredibly elegant breakdown of what screens need for a coder to be happy long into the future.
If there were some easy way for manufacturers to add "component" definitions for hardware devices, perhaps WebASM could become something amazing. However, the name ASM is likely to throw off too many would-be devs. At any rate, it's not meant to be assembly for the web, it's meant to be skeletal scaffolding for your amazing, native apps. Why else even bother.
I think that the issue comes in when people call it WebASM. ASM had different aims in 1960 than in 2017. In 1960 ASM was about minimizing register overlap and utilizing max CPU efficiency reels. Now, you have no idea what hardware your Web-whatever is going to run on, so how could you possibly optimize for CPU? The only real optimization would be optimizing software-engineer/developer attention+visualization and that would only come with an incredibly elegant breakdown of what screens need for a coder to be happy long into the future.
If there were some easy way for manufacturers to add "component" definitions for hardware devices, perhaps WebASM could become something amazing. However, the name ASM is likely to throw off too many would-be devs. At any rate, it's not meant to be assembly for the web, it's meant to be skeletal scaffolding for your amazing, native apps. Why else even bother.
I think you have a different framing of the problem most people excited about WASM have. It is not about talking directly to the hardware, just getting speed gain like you are. So this component idea seems to be coming from out of the blue and indicates to me you haven't paid webassembly much attention until now.
Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't need to match perfectly, it just needs to be similar enough, minimalistic and better than what we have now. The 'simple enough' part makes translation to native machine code easy enough and the minimal makes it easy for standards adoption. As for beating what we have now, you should read the article, because right now its javascript or nothing at all, and anything even vaguely more like a real machine can be optimized better than javascript.
Also, currently Chrome and Firefox support it. Currently Edge and Safari both support it in preview versions of the browsers. I am not sure where you are coming when you say "there is hardly an agreed-upon standard so far" because the four largest browser manufacturers have agreed enough to have 4 different working products or demos. Perhaps you could expand on that to let me know what you or if your information might have been old.
Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't need to match perfectly, it just needs to be similar enough, minimalistic and better than what we have now. The 'simple enough' part makes translation to native machine code easy enough and the minimal makes it easy for standards adoption. As for beating what we have now, you should read the article, because right now its javascript or nothing at all, and anything even vaguely more like a real machine can be optimized better than javascript.
Also, currently Chrome and Firefox support it. Currently Edge and Safari both support it in preview versions of the browsers. I am not sure where you are coming when you say "there is hardly an agreed-upon standard so far" because the four largest browser manufacturers have agreed enough to have 4 different working products or demos. Perhaps you could expand on that to let me know what you or if your information might have been old.
For example, I just googled briefly for the Chrome WASM platform status and to quote directly, "WebAssembly is in the early stages of language and spec design."
Although I would love to have a working model of WASM to play with, the fact is that it is a fresh idea and that any spec you see today will not be around in five years.
Wanting WASM to look like C/C++ is so hilariously misguided that I wonder if any programmers have been paying attention to language evolution in the past 5 decades.
Yes, Javascript is the best we can do at the moment, and that is truly sh. I do not disagree. My latest progress with regards to that is using something that compiles to JS, but there is still the indefatigable issue of having to use Javascript.
To me, WASM is an initiative to redesign the language behind the screen, and anything short would be inadequate because Javascript already does almost everything, just in an incredibly roundabout, piecemeal, poorly evolved way.
So, you are right in assuming I have not been paying attention to the news in the world of Web ASM, but I must also appeal to your logic and say that any of the news you read now is just theoretical debate. Maybe I should take up my issues with the language designers, as that may prove more fruitful.
Although I would love to have a working model of WASM to play with, the fact is that it is a fresh idea and that any spec you see today will not be around in five years.
Wanting WASM to look like C/C++ is so hilariously misguided that I wonder if any programmers have been paying attention to language evolution in the past 5 decades.
Yes, Javascript is the best we can do at the moment, and that is truly sh. I do not disagree. My latest progress with regards to that is using something that compiles to JS, but there is still the indefatigable issue of having to use Javascript.
To me, WASM is an initiative to redesign the language behind the screen, and anything short would be inadequate because Javascript already does almost everything, just in an incredibly roundabout, piecemeal, poorly evolved way.
So, you are right in assuming I have not been paying attention to the news in the world of Web ASM, but I must also appeal to your logic and say that any of the news you read now is just theoretical debate. Maybe I should take up my issues with the language designers, as that may prove more fruitful.
Last night I tried a web assembly demo of Ogre3d, an open source 3d rendering engine. It worked in Chrome and Firefox. (I will put the link here after work, it is sitting in my personal email)
Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now.
I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledge. I assure you web assembly is not an attempt to replace javascript or make javascript look like C/C++, though you imply you believe such when you say things like "Wanting WASM to look like C/C++ is so hilariously misguided". I am not sure how language design factors into, if someone were so inclined they could compile JS to Wasm and have similar performance gains if the compiler optimized well.
Wasm is about nothing more than performance and they have nailed it. It is very fast compared to javascript, though it is slower than the C or C++ compiled to a native executable.
Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now.
I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledge. I assure you web assembly is not an attempt to replace javascript or make javascript look like C/C++, though you imply you believe such when you say things like "Wanting WASM to look like C/C++ is so hilariously misguided". I am not sure how language design factors into, if someone were so inclined they could compile JS to Wasm and have similar performance gains if the compiler optimized well.
Wasm is about nothing more than performance and they have nailed it. It is very fast compared to javascript, though it is slower than the C or C++ compiled to a native executable.
Thank you for taking the time to clarify the status of the project to a stubborn mule such as myself.
I just tested this in Firefox 53 and Chromium 58: https://ogrecave.github.io/ogre/wasm/
Space to jump, WADS to move, Q to draw and put away swords.
Space to jump, WADS to move, Q to draw and put away swords.
https://www.youtube.com/watch?v=BV32Cs_CMqo Unreal Engine 3 (may 2nd release vid) very cool! Can I use WebASM to do amazing music visualizations?
Thank you for being reasonable, that is not very common. You were never rude and we are all... off sometimes.
and sorry I forgot the link, I am writing a note to myself on real dead tree so I can forget it easily.
and sorry I forgot the link, I am writing a note to myself on real dead tree so I can forget it easily.
Like MongoDB?
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.
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.
Llvm has a web assembly backend
> Currently browsers only support JS.
Except Chrome and Firefox, which both support WebAssembly.
Except Chrome and Firefox, which both support WebAssembly.
[deleted]
Is javascript being used as an ORB and this possibly binary byte code is a bit of machine readable IDL ?
Looks really interesting, but How does one debug the web assembly code?
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).
JS today is often transpiled anyway, so you have to use some mapping to the source code to do debugging (eg. source maps).
[deleted]
Thanks
I figured the built in browser debuggers wouldn't work so well for this.
I figured the built in browser debuggers wouldn't work so well for this.
The debuggers would need to be modified to support it, but I don't think there's a reason that you couldn't debug wasm inside a browser, if they were built to understand the debug annotations in the wasm code.
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.
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).