Experimental support for WebAssembly in V8

http://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html

by AndrewDucker • 10 years ago

394 262 10 years ago

v8project.blogspot.com

amelius• 10 years ago

Will WebAssembly allow us to create custom video codecs? Or is there still a bottleneck somewhere that makes this unrealistic?

espadrine3• 10 years ago

You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: https://github.com/phoboslab/jsmpeg.

It is unlikely to ever compete battery-wise with hardware support for a codec, however.

jfbastien15• 10 years ago

Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support.

* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.

TD-Linux• 10 years ago

Here's another example, using more modern codecs: https://brionv.com/misc/ogv.js/demo/

It's used in production on Wikipedia: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/o...

batmansmk• 10 years ago

It is a wonderful news. Firefox version is ready too.

sunfish4• 10 years ago

The big news here is coordinated announcements from multiple browsers:

https://blogs.windows.com/msedgedev/2016/03/15/previewing-we... https://v8project.blogspot.com/2016/03/experimental-support-... https://hacks.mozilla.org/2016/03/a-webassembly-milestone/

introducing support for the live demo:

https://webassembly.github.io/demo/

espadrine3• 10 years ago

A WebKit announcement is notably missing, unfortunately. However, it is great to see Edge, even though it is not a surprise, as they have been pushing for WebAssembly from the start.

jfbastien15• 10 years ago

"In development": https://webkit.org/status/#specification-webassembly

sunfish4• 10 years ago

WebAssembly is "In Development" on WebKit's status page: https://webkit.org/status/#specification-webassembly

s3th4• 10 years ago

Yes! It's the compatibility of more than one implementation, each running the same WebAssembly binary that makes me so excited about this milestone.

tkinom• 10 years ago

This might allow Flash to come back alive running inside wasm?

Dream or Nightmare? :-)

comex• 10 years ago

If you haven't seen it, Flash-via-HTML is already a thing:

http://mozilla.github.io/shumway/

lisivka4• 10 years ago

Nightmare

k_bx• 10 years ago

Demo throws an error in FF Nightly https://i.imgur.com/vBpWOdx.png

sp3323• 10 years ago

Are there any plans to run WebAssembly outside of a browser? Would it be difficult (once the binary format is nailed down) to distribute a standalone program?

sunfish4• 10 years ago

Yes; the WebAssembly project has some ideas on this here: https://github.com/WebAssembly/design/blob/master/NonWeb.md

CyberDildonics7• 10 years ago

I think if it really takes off and the shared memory parallelism works well it could end up being a pretty potent part of software delivery.

tracker18• 10 years ago

Given that node.js uses v8, and there are a few options for stand-alone distribution of node-based apps [1], I'm sure there will be many options (by the end of the year most likely)... Though, I'm not sure why you wouldn't take a more direct approach to building your code to different platform targets directly if you're using a compile language already... though if you're building web and want a standalone, I can see that.

[1] http://stackoverflow.com/a/12486874/43906

sp3323• 10 years ago

But you only have to compile once for all platforms (famous last words, I know). Including future platforms, platforms you don't know about, and platforms you don't care about but your users do.

moron4hire• 10 years ago

This is going to be huge for the WebVR community. The demo actually ran great on my janky laptop, whereas the ASM.js version at a lower resolution ran at the considerably crappy level I had come to expect of Unity HTML5-built apps on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos should burn less battery power on my smartphone as well, which means less heat build up, which means a longer time before the GPU throttles down.

titzer2• 10 years ago

Standard caveats apply here. It's experimental: a couple bugfixes are already in flight and we're working hard on improving the startup time.

Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with whom we've worked closely with over the past year to make this a reality.

Illniyar• 10 years ago

This is moving fast.

Does anyone know if theres a webassembly to js compiler to support legacy browsers?

s3th4• 10 years ago

The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now.

[0] https://github.com/kripken/emscripten/wiki/WebAssembly

[1] https://github.com/webassembly/binaryen

alimbada• 10 years ago

Yes, you should have a read of the FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md

systems• 10 years ago

does this mean i wont have to learn javascript, css, d3, svg, typescript, jquery, etc ... to make webistes and web apps

benjoffe• 10 years ago

You don't need any of those to make websites and web apps already (or to be less pednantic, you don't need most of those) so I'm not sure what your question is.

megalodon2• 10 years ago

No idea why this was downvoted, you are correct.

Furthermore d3, typescript and jquery is javascript so the question is more like "do I need to learn how to use tools to make websites?" at which point it is kind of silly.

Cshelton• 10 years ago

No, most things will still be done in javascript as the benefit of doing it in Wasm is negligible.

euroclydon• 10 years ago

Think of all the technologies you have to learn to make Desktop or Mobile Apps, or both. You'll need a language to compile to Web Assembly. Then you'll need a target display layer: DOM, SVG-DOM or Canvas. DOM support for text and user interaction is way better than SVG or Canvas.

_alexander_• 10 years ago

You still need these languages/technologies and libraries.

untog• 10 years ago

From my understanding, WebAssembly won't have DOM access. So it certainly won't replace jQuery, D3 or CSS any time soon.

tadlan6• 10 years ago

It will eventually, iirc

s3th4• 10 years ago

WebAssembly doesn't intend to replace jQuery, D8, or CSS. However, we definitely plan to enable efficient DOM access. Doing so requires supporting some sort of native Garbage Collection, as well as the concept of opaque reference types. See more here: https://github.com/WebAssembly/design/blob/master/GC.md

bjt• 10 years ago

The article specifically mentions first class DOM manipulation as one of the next goals. That's been part of the plan from the start. Maybe you're thinking of web workers?

coldtea2• 10 years ago

Yeah, you could program in C++...

tadlan6• 10 years ago

Or julia. Which is 1000th better than js

hutzlibu7• 10 years ago

Yes, in the future you will be able to programm your Website in C++ and OpenGl (2.0) and export it to WebAssembler and WebGL, if you think this will be easier ...

edit: this might actually work for some people, once you can access dom elements directly, but for now it is meant for huge WebApps, like games in the browser

CyberDildonics7• 10 years ago

No one said it will be easier. It is meant to be faster.

IvanK_net• 10 years ago

You are talking about a step in a specific direction.

If you make few more steps in that direction, you can simply write your own operating system, make native apps for it and then call it all "a website", because you can run it in a browser using e.g. this JS computer simulator https://copy.sh/v86/

spriggan35• 10 years ago

You'll still need to learn CSS and SVG as they are web techs, but you wont have to learn anything related to Javascript anymore. As for now Javascript has become irrelevant for good.

tracker18• 10 years ago

If you're targetting HTML, you will likely need at least CSS... most JS is optional, and there are compile-to options.

That said, this should allow you to target a canvas element, with minimal JS binder to wasm code... all logic including what gets rendered could be outside JS... but you'd have to think of and control all input/output, and there are other considerations for rendering performance.

anthk2• 10 years ago

The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all.

pohl• 10 years ago

And, should that come to pass, what would your rationale be for going out of your way to avoid it?

83457• 10 years ago

Lynx?

swiley• 10 years ago

I always use elinks when I'm trying to get work done as anything worth reading (documentation etc) works just fine in it but you don't have all the distracting "web stuff".

coldtea2• 10 years ago

And nobody really cares. Especially without a reasoning given...

trose• 10 years ago

Do you have reasoning behind that or do you just enjoy grandstanding with pedantic statements?

koder2016• 10 years ago

Developed by free-roaming coders fed on organic-certified food.

matt40773• 10 years ago

Hey – as a self-declared food-nerd I resent you comparing me with this self-important JS-luddite.

BuckRogers4• 10 years ago

The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all.

I'm guessing you're a JS diehard that doesn't want to see other languages hit the web? I'm not aware of any other reasons why you'd fight this otherwise.

tadlan6• 10 years ago

Question please: Even though there is stated desire to support python etc vm, this will be hampered by the need for the client to download the large VM vs native code that can be distributed itself, correct?

jfbastien15• 10 years ago

Correct, though we're working on dynamic linking to ease the pain, and improving compilers such as LLVM so that the generated code is smaller.

tadlan6• 10 years ago

Thanks. I'm not familiar with dynamic linking. What will that do?

xigency17• 10 years ago

Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't.

From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.

geon8• 10 years ago

Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?

nfriedly• 10 years ago

If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet.

Update: Here's a quote from the Microsoft announcement:

"Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case."

https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...

xigency17• 10 years ago

Performance.

Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.

mason552• 10 years ago

Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?

Similar to asking why would you want to run JavaScript on the server?

There's something to be said for having your code in a single language. People can move to different parts of the project more easily and if you need to run the code in multiple places then you can do so with (mostly) a single codebase.

The real question is why WOULDN'T you compile all your JavaScript to wasm assuming the build process is easy enough. For complex site that already have a build pipeline I don't see any reason to publish minified JavaScript instead of just building it all into wasm for performance reasons (assuming mature debugging tools of course). The only question I'd have is whether you get that much gain by going from JavaScript to wasm or if the browser's JIT compiler can do a good enough job.

tomjen33• 10 years ago

Game dev here.

Speed. Oh and memory - if I could optimize it so that all our vectors, matrices and logic code did only stack allocations I would be a happy camper.

omarforgotpwd2• 10 years ago

Once webassembly is widely supported, why would we ever write JavaScript again?

azakai3• 10 years ago

compiling from ECMAScript to WebAssembly would be a great boon in production.

That's not going to work well, I'm afraid.

JavaScript is a highly-dynamic language, and as a result, requires JITs that do runtime type profiling, type inference, and type-specialized code generation, in order to be fast.

WebAssembly is a low-level, statically typed language. It's like a portable C with a small binary footprint.

Even if you annotate and/or detect some of the JavaScript types at compile time, if you don't have them all, that means compiling JavaScript to WebAssembly will result in code that everywhere does "if this type, do that; if that type, do this". That's going to be bigger in code size than JavaScript currently is. It's also going to run much slower.

If you did type every single thing in your JavaScript program, somehow, then that might work well. But that's not really JavaScript anymore (or even TypeScript, etc.).

bcheung2• 10 years ago

WebAssembly is a binary representation of the Javascript AST. Optimizations usually happen AFTER it is parsed. That's all WebAssembly is -- the parsed result. Targeting WebAssembly from Javascript is the most natural fit that could possibly exist.

xigency17• 10 years ago

What about this JavaScript: https://raw.githubusercontent.com/gregtour/gameboy/master/JS...

It's not asm.js, it isn't C (but it was ported from C), but it's JavaScript and it has no dynamic allocations. No variable uses more than one type. I could hand fashion asm.js and WebAssembly code and tell you which one is faster.

That's the only answer to whether a JavaScript to WebAssembly compiler would be worthwhile.

skybrian• 10 years ago

If you want to target WebAssembly, I suggest starting with Rust or some other language that doesn't require a garbage collector.

WebAssembly doesn't have a garbage collector (yet) which is essential for JavaScript and many other high-level languages. Shipping a garbage collector compiled to WebAssembly is going to make downloads much larger, and it's likely going to perform worse than the native garbage collector.

A compiler for a garbage-collected language is probably better off targeting JavaScript, not WebAssembly. There are already lots of languages that do this: GWT, Dart, Kotlin, ClosureScript, Elm, etc. There was already plenty of work to do for a compiler expert even before WebAssembly came along.

xigency17• 10 years ago

The purpose is to limit the number of steps in development.

If only 50% of users are running the WebAssembly version of a product, and 50% are running the JavaScript version of the product, then both need to be stable.

Developing in an unrelated language is unlikely to help.

Touche3• 10 years ago

So when is Google going to deprecate Native Client?

jfbastien15• 10 years ago

When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an extremely secure sandbox. It's under Chrome's Vulnerability Reward Program, you're welcome to look for payoffs ;-)

crudbug2• 10 years ago

Giant Leap for Web Platform.

How is the mapping from wasm to asm done, at all?

Are they directly mapping from web world to native world in a sandbox ?

sbierwagen• 10 years ago

https://github.com/WebAssembly/design/blob/master/FAQ.md

crudbug2• 10 years ago

{Any Language} => WASM => {OPTIMIZATION/COMPILATION} => NATIVE CODE

gregwtmtno• 10 years ago

I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.

jfbastien15• 10 years ago

Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is.

View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...

s3th4• 10 years ago

WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2].

[0] https://www.w3.org/community/webassembly/

[1] https://github.com/WebAssembly/design/blob/master/TextFormat...

[2] https://github.com/WebAssembly/design/blob/master/Tooling.md

kuschku• 10 years ago

Great!

We should make sure that browsers refuse to run any code in the future that isn’t available in its full source.

Yes, that includes ReCaptcha

/me looks angrily at Google

cjfont• 10 years ago

I'm going to guess that the format lends itself better to code obfuscation than JavaScript, for those that do not want their code to be open.

pcwalton• 10 years ago

Before, we had asm.js. asm.js isn't very readable. By contrast, Web Assembly has a nice human-readable (though terse and low-level) IR. It even looks like Lisp, if you like that :)

Web Assembly is a small step toward better human inspectability of the compiled blobs your browser is executing, compared to Flash, Java, and asm.js. To be sure, it doesn't mandate that the source be available in the form preferred for editing. But the Web hasn't done that since 1997.

mrec• 10 years ago

Agreed. It might also be nice to have wasm blobs compiled from open source code supply a standard metadata link to that code (the project's GitHub repo or whatever) so that UAs can offer nice affordances to replace Ctrl-U if they want to.

kibwen4• 10 years ago

I don't think the downvotes are necessary here, this is a legitimate question.

Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform.

Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.

tracker18• 10 years ago

Well "just a binary representation" in the same way that .Net's CLR is just converted C#/VB/F# etc...

Unless you know the source language, and have some sort of reverse-compiler (or source maps), then getting back to a readable/usable source isn't so easy. Though that doesn't mean you can't trace through what goes down the wire, it won't be quite as low-level as x86 assembly, but will be lower level than most are comfortable with.

tomjen33• 10 years ago

I hear this argument a lot. It may have been true once, say 5 years ago.

Today I can already do that -- look at the output of the Google closure compiler with advanced optimizations turned on. Sure it is javascript and not binary, but all comments have been removed, all variables have been given short and meaningless names that are frequently reused and all the structures have been turned inside out.

And those optimizations are only for speed.

CaptSpify• 10 years ago

And I've never understood this argument. Yes, JS allows people to ship obfuscated code. Doesnt mean we should give up and stop expecting readable code.

gkya• 10 years ago

I am a bit baffled too, but in the end of the day, it's no different from running javascript. Most pages load probably millions of lines of JS and you can't audit it (disclaimer: I totally made up that number). For the security conscious, the only way is to implement very strict JS/cookie whitelisting, which is what I do. For the others, well, I guess it's no different from running JS in the end of the day.

I wonder if this will make it's way into WebKit, and if so its implications for Xombrero, will I have to maintain a seperate WASM whitelist, or disabling JS will disable it too? TBH I plan not allowing even the most trustible website run such code on my computer.

noiv2• 10 years ago

That three major browser teams implement and publish a new standard/technology at the same time is exciting. OTOH I can't believe we start over again with Assembler (a machine language).

dlubarov3• 10 years ago

Well it's not really machine code, since no hardware uses wasm as its native instruction set; it's just low level bytecode.

And it's really intended as a compilation target; I don't think anyone wants or expects average web developers to code in wasm.

noiv2• 10 years ago

Well, it runs on a virtual machine, not that much different. And the design doc states "writing by hand", but the s-expressions look interesting. Finally Lisp for browsers :)

z3t4• 10 years ago

It might sound like a stupid question, but is it faster then vanilla JavaScript!?

spriggan35• 10 years ago

Yes since it's lower level, and No since you'll still be limited to Web APIs like Javascript. The code isn't being executed outside the browser like a Java applet or Flash.

xhrpost• 10 years ago

I know programmers sometimes write directly in assembly for certain performance enhancements and certain hardware access. Is there a foreseeable reason someone would program directly in WebAssembly though? I realize that's not the reason this technology exists, just curious.

hutzlibu7• 10 years ago

As far as I understands, this should be doable. But it would probably be much easier to use another (static) language for the parts you want to optimize, compile to wasm and then access them in your js code.

abecedarius• 10 years ago

When asm.js came out I ported http://wry.me/hacking/Turing-Drawings to use it. It would've made as much performance sense to do the same for WebAssembly. This is not quite the same as hand-coding WebAssembly -- it's making a custom code generator for a little language.

BinaryIdiot3• 10 years ago

Oh man I'm very excited about this! Great job all around!

Web Assembly should make code more portable and faster on the web. No more transpiling to JavaScript (which honestly is a hack; going from one language to another language which is then compiled). If you want to use CoffeeScript, even though I dislike it, you'll be able to compile directly to WebAssembly instead.

I can't wait until this is fully baked with DOM access, etc.

jfbastien15• 10 years ago

Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.

BinaryIdiot3• 10 years ago

Transpiling some dynamic languages to JS is still sensible.

It's still practical, today, should you want to use something other than JS but I don't think it's that sensible. You take one language's syntax and idiosyncrasies, convert it to another language with its own, sometimes differing, idiosyncrasies and now you have to debug it, sometimes in a different language than it was written it.

I don't mind TypeScript or any of the others but I think WebAssembly is what makes those language great; transpiling to JavaScript is a hack.

Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly after announcement because your JavaScript now compiles to WebAssembly. You won't have to wait or deal with browsers that are lacking the necessary APIs; it'll "just work" because it's all compiled to WebAssembly.

kin• 10 years ago

Is there any news for WebAssembly on mobile browsers?

jfbastien15• 10 years ago

It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first-class platform for launch.

iLoch4• 10 years ago

Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now.

Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?

netghost• 10 years ago

Finally I can write in HyperTalk!

pekk• 10 years ago

The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.

xigency17• 10 years ago

HyperCard predates the world wide web. It was pretty awesome, too.

tracker18• 10 years ago

WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer.

That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use.

wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)...

As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.

michaelwww• 10 years ago

WASM can't talk to the DOM directly

It will according to multiple sources:

"In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1]

"Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2]

[1] http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md

hutzlibu7• 10 years ago

This is great news! And a nice working demo ... And a general question about wasm - since typescript can be strictly typed, would it benefit much, if it would be compiled to wasm?

CyberDildonics7• 10 years ago

I think you would want to see how it does when compiled to LLVM IR to answer that question.

Also keep in mind that webasm doesn't include a garbage collector. If typescript relies on one, it will need to be compiled to webasm as well.

hutzlibu7• 10 years ago

Ah right, the gc. I doubt you will see much benefit, if you will have to compile him as well. But maybe it is possible to code without ... and free memory yourself with "delete x" or "x=null"

constexpr• 10 years ago

I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type.

So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all.

Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a lot of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.

hutzlibu7• 10 years ago

I think I would be happy with the subset and the add of Integers ... Dynamic languages are great for rapid prototyping and debugging, but once the programming is done and everything is clear, I don't realy need stuff like window["foo" + someString](1,2,3) or the "any" type anymore ... I don't think it will be too hard, to "strongtype" your ts or js if there will be such a subset and you have a smart IDE.

fizzbatter2• 10 years ago

Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.

jfbastien15• 10 years ago

"ridiculously easy": https://github.com/rust-lang/rfcs/issues/604

grayrest• 10 years ago

Should just be replacing Emscripten in the toolchain with Binaryen [1].

[1] https://github.com/WebAssembly/binaryen

brson2• 10 years ago

This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share.

The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.

brson2• 10 years ago

Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on.

[1] https://internals.rust-lang.org/t/need-help-with-emscripten-...

tracker18• 10 years ago

It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...

kibwen4• 10 years ago

The initial release of WebAssembly won't have any support for well-integrated runtimes, which complicates support for any language that isn't C or C++ or Rust. Theoretically you could probably ship the Go runtime with each webpage, but I don't know how you'd interact with the DOM from there.

iagooar• 10 years ago

When I read news like this, I think: this is the cool stuff you should be doing, not maintaining a lousy e-commerce shop...

cududa• 10 years ago

I work on OS level stuff myself, but I find this comment insulting. What are you even working on?

bobajeff3• 10 years ago

I wonder if Google has any plans on using C++ in any of their web applications now.

Might help them improve Google Docs a lot if they could utilize some mature C++ libraries from a desktop word processor.

nly• 10 years ago

Google can already run whatever code they want on your docs server side.

formula1• 10 years ago

More importantly, will rust compile to wasm one day?

sp3323• 10 years ago

It's already an LLVM backend, so yes?

rbalicki• 10 years ago

https://users.rust-lang.org/t/rust-to-js-with-emscripten/587 There's been interest in compiling to JS for a while. I don't follow Rust closely, so I'm not sure how much progress there has been.

steveklabnik• 10 years ago

Lots! We're getting really close, actually.

stuaxo• 10 years ago

Run Servo in Servo

legutierr• 10 years ago

Does anyone who is familiar with WebAssembly development know what kinds of things Dynamic Linking (mentioned among the future features) will enable? For instance, would it permit the creation of optimized WebAssembly libraries written in C++ that could be called by a JavasSript program (say, for things like image processing)? Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser?

Because that would pretty cool.

tyingq• 10 years ago

>Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser?

The hard part there is the "eventually". They do state that the missing pieces will come some time after the "Minimum Viable Product", but none of it sounds high priority.

- The current course omits features that would be needed for any dynamically typed language (including Python) to work. (garbage collectors, polymorphic inline cache, etc)

- The current course also prevents anything running in the WebAssembly space from accessing the DOM. You can call your WebAssembly from javascript, but that's it.

I suspect it will be quite a while before there's more available than "call LLVM created libraries from javascript". Technically, you could, I suppose put the entire cpython codebase into webassembly, but that seems like more of parlor trick than something useful.

titzer2• 10 years ago

You can already do some of that without the dynamic linking feature. There is a JS API to instantiate a WebAssembly module, providing JS functions that are callable as external functions from within the WASM module. Conversely the WASM module exports functions that are callable directly from JS.

This allows rudimentary interop between JS and WASM, and dynamic linking will make it possible to deliver your WASM application in separate pieces, e.g. a large, rarely-changing library that is cached, precompiled, by the browser, and a small, often-changing application piece.

megaman821• 10 years ago

Would there be any benefit to compiling dynamic languages with GCs (like Python or Ruby) to WASM? It is cool that is technically possible, but this looks like a target for C, C++, and Rust code.

jfbastien15• 10 years ago

C Python and Ruby should "just work" because you can compile their GC into you wasm module.

More general-purpose GC will be supported, but not in the initial release: https://github.com/WebAssembly/design/blob/master/GC.md

abhianet• 10 years ago

It is more attractive to look at WASM as a way to bring a lot of other languages into the web. We are already transpiling a lot of code, ES7, TypeScript, ClojureScript, Dart, and so on. I would say WASM makes a lot better target than JS will ever be.

tracker18• 10 years ago

I can't help but to think that this could be a huge win for binary modules in node.js, as it could finally allow for cross-platform, prebuilt binary modules without the tight coupling and build dependencies that are currently needed.

spriggan35• 10 years ago

Great news, this is the beginning of the "Javascript Less" movement.

ludamad3• 10 years ago

It'll be really interesting if people think of JavaScript more as a highly available scripting language, rather than a necessity.

spriggan35• 10 years ago

So who's going to be first to recreate an entire Flash runtime for WASM? ;)

bobajeff3• 10 years ago

Well hopefully Adobe does this. No one else has really been able to make a full flash implementation.

It probably won't be as fast though but for legacy Flash content that would be fine.

ludamad3• 10 years ago

I don't see enough about Shumway given the recognized security impetus

al2o3cr• 10 years ago

Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.

spriggan35• 10 years ago

Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.

You cant port the entire applet infrastructure since WASM is limited to the same API as Javascript. If WASM doesn't support multithreading, languages targetting WASM wont.

mobiuscog• 10 years ago

Why bother with applets ? Just run 'native' Java apps.

shurcooL• 10 years ago

This is really exciting, because it's going on a great path and it's a matter of time before all this is available out of the box!

Is anyone working on a Go to WebAssembly compiler yet?

ZenoArrow4• 10 years ago

"Is anyone working on a Go to WebAssembly compiler yet?"

I don't think that'll work until WebAssembly has GC, which isn't likely to be ready for a while.

nulltype• 10 years ago

Go has it's own GC, so why would it need WebAssembly's? Does web assembly disallow programs from doing their own GC?

neals• 10 years ago

Is this in a state where I can go and try making experiments in webassembly?

azakai3• 10 years ago

It's a little early, so things are not easy to use yet. Spec still changes, tools still change and break, nothing is optimized for convenience yet, etc. But here is how to use emscripten to emit WebAssembly currently,

https://github.com/kripken/emscripten/wiki/WebAssembly

dccoolgai2• 10 years ago

For all the complaining about it, I think I will actually be a little sad to see Javascript go. It wasn't perfect, but it had a powerful unifying effect on the Web Community when we could write, share and learn about our code in a higher-level scripting language that we could all read. (Even if there were some surprising little quirks that took a while to get used to.) Despite the stated intention from WASM - there is just something fundamental about AST trees - no matter how well you pretty-print them - that doesn't allow sharing and shared learning the same way. As a run-of-the-mill guy who makes my bread maintaining websites as much as greenfield-developing them, I feel like I'm in for a bit of a rough ride trying to decipher and debug binary/AST code compiled from Perl (or whatever). Guess I'll have to suck it up and learn to do it, though.

jfbastien15• 10 years ago

JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.

kelvin0• 10 years ago

Yeah, the VM is the same but allows low-level JS instructions to run. So next step, is to build a <your favorite language> to webasm transpiler and not have to use JS again ... :) I believe emscriptem is already doing this for C/C++

dccoolgai2• 10 years ago

It seems like they "could" complement each other, but that's not a defining characteristic of WASM. WASM, as I understand it, essentially allows me to take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and compile an AST that can be interpreted by the engine on the client-side. Which is great for Python/Haskell/Perl developers that they no longer have to pay the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe they shouldn't have to contribute to JS. We can call that a good thing, but let's not pretend that doesn't marginalize JS (which - again!! - maybe it should). "But they still don't have access to the DOM" is not much of an impediment to that Perl dev, and means as your run-of-the-mill guy I now have to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it in 5 hours instead of 12, but I'm still reading binary/AST which does not seem like an awesome time) and the cruft from whatever Perl-WASM binding library they forked from Github. Again - I know this makes life better for that Perl dev, and maybe he/she deserves it. But unless I'm missing something, I don't see how allowing that dev to (basically) skip JS in their path from whatever IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it seems like now that dev will start making/contributing to libraries that conform to their stack (Perl-specific web libraries that compile to WASM). Now if I want to contribute to that library - which is now a part of the web - I have to learn Perl. Before, that Perl dev would have had to learn Javascript - which I know sucks for them - but it was good for me and good for Javascript... and I would say "good for the web". We were all speaking the same language, which led to an explosion of learning and collaboration. Sure, .3 != .1 + .2 But it was that way for all of us. Now everyone is going to go back to their own little feifdoms and just tipping their hat to JS along the way with a lightweight DOM binding port.

ilaksh• 10 years ago

Nim, which is objectively the best programming language, is perfect for Web Assembly.

randyrand• 10 years ago

Anyone gonna write an LLVM backend for this? =D mouth waters

jfbastien15• 10 years ago

Done https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W...

sunfish4• 10 years ago

Already on it :-).

https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W...

(linked to the Github mirror because the LLVM viewvc is currently down)

Experimental support for WebAssembly in V8

Related Stories