11 ms·

WebAssembly, an executable format for the web

128 points by arnoooooo 9y ago

jwilk 9y ago
"#include " was meant to be "#include <webassembly.h>", but somebody forgot to escape <> in HTML source.
- arnoooooo 9y ago
  I thought I fixed that one :/ It's fixed for good this time. Thanks !
danschumann 9y ago
Is there a way to compile javascript in web-assembly, to protect the source code? IE, you'd have to convert the javascript to C, and then compile the C into web-assembly, right? Does V8 have a method to convert JS to C?
- slededit 9y ago
  WASM doesn't have access to the DOM yet so it's unlikely your JS could would work anyways.
- skybrian 9y ago
  That's unlikely to be efficient and it wouldn't help much anyway. Running JavaScript through an optimizing compiler and minifier will obscure pretty much the same information. But either way, you can step through the code in your browser's debugger to see what it does.
  - dangerbird2 9y ago
    Also, wasm is a fairly high-level bytecode, more comparable to jvm or llvm code than arm or x86 code. It's pretty easy to follow the logic of disassembled web assembly
- justinpombrio 9y ago
  If you just want to obfuscate your JavaScript, there's nothing to be gained by compiling to a different language. There are already plenty of JS->JS obfuscation libraries that work well.
- _greim_ 9y ago
  No. wasm needs to be able to interact with the DOM and other web APIs, which I understand isn't the case currently. Then you need hooks into GC. Although I guess nothing would stop you from embedding a JS runtime in your wasm blob, other than download size.
- s-macke 9y ago
  This repository compiles asm.js into webassembly [1]. Otherwise, you will have a hard time to convert your Javascript code. You have to implement a JIT compiler and GC too. Webassembly was never designed to be a replacement for JavaScript. And especially, it was never designed to protect your source code. A minimizer/obsfucator does a great job of making your JavaScript code unreadable. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
  - baybal2 9y ago
    >And especially, it was never designed to protect your source code. I hardly get that, all and every major backer of WASM did effectively admit at some point that "ip protection" was the one and only reason they back it. The absence of a native dom interface or proper I/O implementation at this point means that WASM compiled code actually runs slower for everyday web apps than non-compiled code.
    - the_duke 9y ago
      > all and every major backer of WASM did effectively admit at some point that "ip protection" was the one and only reason they back it. I'm sure you wouldn't mind providing sources for this bold claim?
    - s-macke 9y ago
      I have looked at obsfucated JavaScript code as well as webassembly disassembly. I don't see much difference. What might obfuscate is the fact, that it comes without any libraries. You have to program like in C without any library support, which is more or less what you do with bare metal programming now.
- icebraining 9y ago
  Apparently http://enclosejs.com http://enclosejs.com can compile JS to regular binaries, but I don't know if there's any way of converting an ELF binary to wasm. You could always run a full emulator + kernel (using JSLinux) to run that binary :)
- Schampu 9y ago
  NW.js offers Javascript code protection [0] by allowing to distribute code in bytecode form. I just tested it yesterday and my code runs as fast as the original. [0] http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/ http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%2...
- kuschku 9y ago
  > Is there a way to compile javascript in web-assembly, to protect the source code? This kind of obfuscation is harmful to the web, don’t do it. Also, any compsci student with a summer of free time can easily break it, so it’s useless, too. You’re just wasting your own time and the bandwidth and performance of your users. In fact, if you tell me what site you want to obfuscate your code on with WASM, I (an average compsci student) will spend my next summer reversing it, deobfuscating it, and publishing the results publicly (just to demonstrate you how useless your obfuscation is).
  - danschumann 9y ago
    Is photoshop harmful to the web? Should they give away their source code? Their source code is what's valuable in their company. So, art programs kind of need source protection. I won't be making a web-version until this is the case. If you can crack NW.js source protection, let me know http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/ http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%2...
    - kuschku 9y ago
      > Is photoshop harmful to the web? Photoshop isn't on the web, but I oppose closed source in principle. > Should they give away their source code? Ideally, yes. If you do it is still your decision, but you still should be aware that if you introduce truly new concepts, someone will clean-room reverse them, and publish them. > So, art programs kind of need source protection. The Krita project begs to differ. > I won't be making a web-version until this is the case. If you can crack NW.js source protection, let me know Then you shouldn't make any build where the business code runs on the client. Even native binaries can be reversed, their functionality analyzed, and copied. Which is how LibreOffice/OpenOffice originally discovered how to parse the Microsoft Office formats.
      - danschumann 9y ago
        It's possible, but not very ideal to have all the operations done on the server, and just serve interface stuff, maybe even as a streaming video, to the client. When people paint, they want it responsive, no stream lag, no server hiccups. I must allow people to install the software on their computer. I would still like to protect the work I've done, because I'm just one guy making software, and I don't have marketing money. What would stop big companies from taking my source and spending more on advertising? I need source protection.
skocznymroczny 9y ago
WebAssembly might be a Javascript killer for high-performance uses. Javascript for uses such as game development is dragged down by the garbage collector, forcing you to orient entire code around minimizing allocations. Without garbage collection, you have to manage memory yourself, but allocations aren't as scary as they are with GC languages and they are more explicit.
- vardump 9y ago
  Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.
  - austincheney 9y ago
    GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.
    - vardump 9y ago
      CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
    - imtringued 9y ago
      GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.
kodablah 9y ago
I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of course but as GC and threading specs come along, I can hope one day it will reach parity. Granted it isn't as low level, but that has benefits for compiler backend implementers (they can choose how they target their arch) and compiler frontend implementers (they don't have to do different things per platform). Basically, imagine if Java bytecode was developed less around OO semantics, wasn't lumped in with its stdlib by the community, didn't have encumbered JCK and other tests, etc, etc. Edit: Changed "LLVM" to "LLVM IR" to clarify as requested.
- wyldfire 9y ago
  Your comment was confusing to read. I think it would be easier to understand if you replaced "LLVM" with "Intermediate Representation".
- RussianCow 9y ago
  To me, this is the most exciting prospect of WebAssembly by far: an IR that works natively across all major platforms, including the web. It's funny because it makes Gary Bernhardt's "The Birth & Death of JavaScript"[1] seem a lot less like a joke. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- rhelmer 9y ago
  This use case is interesting to me too. I looked into this a few months ago and found that there is a page on non-web embeddings: http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/
- mike_hearn 9y ago
  I'm not sure your criticisms of Java bytecode are all that reasonable to be honest. You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages. Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC. Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation. Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.
stromgo 9y ago
Those of you who tried WebAssembly, what kind of performance are you getting compared to native? In my application, execution time is about 200% of native, which is quite bad compared to the few benchmarks I could find: https://hacks.mozilla.org/2016/10/webassembly-browser-preview/ https://hacks.mozilla.org/2016/10/webassembly-browser-previe... https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/ https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s... It's a head-scratcher as my code is nothing special and I don't see what I could be doing wrong. Then it occurred to me that these benchmarks look suspicious, with many scores below 100%. Are there fair benchmark results somewhere, measured by someone not trying to promote WebAssembly? What performance ratios are HN readers getting currently, and what performance ratios should we expect in the long term?
- vanderZwan 9y ago
  Do you have your code online somewhere? What kind of tasks are you trying out? How much time is spent sending data back and forth between WASM?
- steveklabnik 9y ago
  I haven’t done much personally yet, but I hear it can vary quite a bit between browsers.
- jdright 9y ago
  https://floooh.github.io/sokol-html5/index.html https://floooh.github.io/sokol-html5/index.html You can compile these samples natively and compare yourself.
Thaxll 9y ago
ActiveX is back. Can't wait to see all the exploits escaping the browser sandbox.
- anomie31 9y ago
  Did ActiveX even have a sandbox?
  - jamesgeck0 9y ago
    Nope! But you had to promise Verisign that you wouldn't build any malware.
- cdancette 9y ago
  Isn't it the same with JavaScript?
  - chungy 9y ago
    Yes, and WebAssembly runs on top of the existing JavaScript VM engines.
    - Thaxll 9y ago
      I don't think it runs on the same V8 ( chrome ) that the one runs JS, I remember 2 engines running.
      - DiThi 9y ago
        The wasm binary itself may be using a separate engine, but heavily sandboxed: it can only communicate with JS, and nothing else. The (newly added) attack surface is minimal when compared with Flash, Java, etc (each with its own APIs). Almost any flaw must be in the JS side, and that's already battle-proven for years. ActiveX didn't even have a sandbox, so not even related.
        chungy 9y ago
hughes 9y ago
I'm admittedly inexperienced with WebAssembly, but I'm a little unclear on going beyond the basic "hello world" implementations. Is the idea to write an entire application in WebAssembly, or is it to break out parts of the application that benefit from performance improvements and potentially cross-platform code bases? Also, how do you do things like make network requests or decode JSON in webassembly? Do you need to implement these things yourself, or pass things back to the browser to handle them, or find C libraries that do that for you?
- kodablah 9y ago
  Case by case situation. WASM is nothing but a spec and impl for CPU tasks. If you want to do something like networking, you call out to JS (today). If you want to decode JSON, you could call out to JS, or populate some part of the WASM-accessible mem (a byte array) and then ask WASM to operate on it. It could be a C library compiled to WASM or hand-written or in some other compile-to-WASM lang.
TekMol 9y ago
Is WebAssembly related to asm.js? I don't like to compile stuff. But improving performance by writing certain functions directly in assembler or in a subset of js would be awesome.
- giancarlostoro 9y ago
  Yes: https://en.wikipedia.org/wiki/WebAssembly#Development https://en.wikipedia.org/wiki/WebAssembly#Development
- acemarke 9y ago
  In a way, yes. asm.js was a deliberately limited subset of JS syntax. By adding a "use asm;" statement, you signaled to the JS engine that everything after that was limited to the asm.js subset, allowing it to simplify the parsing logic and use a fast path for loading the code. You would rarely write asm.js syntax by hand, but rather use it as a compiler output format. WebAssembly takes that further by defining a bytecode that the JS engine doesn't even have to parse, but can accept and work with more directly. This speeds up loading time. Also, loosely put, the way it's defined allows the JS engine to execute it faster. WebAssembly is definitely not intended to be written by hand. Languages like C++ and Rust can now compile to WebAssembly, allowing non-JS source code to be run in a browser. (There _is_ a textual representation of the bytecode as well.)
- brian-armstrong 9y ago
  Compiling stuff is awesome. I never want to discover my bugs at runtime.
  - goatlover 9y ago
    Even when prototyping, exploring or doing one-offs? I'd rather have the flexibility in those situations.
    - brian-armstrong 9y ago
      Absolutely, yes. It's preferrable to trying to debug inexplicable glitches in the prototype that the compiler could have caught. And with incremental builds, compilation should be pretty lightweight anyway.
LyndsySimon 9y ago
This is the first time I've seen disassembled WASM. It's actually quite readable!
dchest 9y ago
function readUtf8String(memory, pointer) { let s = ""; for (i = pointer; memory[i]!==0; i++) { s += String.fromCharCode(memory[i]); } return s; } This doesn't read UTF-8, this reads bytes and converts them to UTF-16 char codes, so it works only with ASCII or some other 0-255 encoding. To read UTF-8 into a JavaScript string (which is UTF-16), bytes should be properly decoded from UTF-8 (e.g. with TextDecoder).
- arnoooooo 9y ago
  Thanks ! I've renamed the function accordingly.
  - chrismorgan 9y ago
    ASCII only covers values 0–127; this function allows 128–255 as well, which makes it ISO-8859-1 (latin1), the first 256 code points of Unicode being the entirety of ISO-8859-1.
thephyber 9y ago
Can someone explain to me why we would expect WebAssembly to be much different than Java Applets? There are inevitably defects in the design and/or implementation which will open up browsers to gaping security vulnerabilities until they are found and fixed.
- AgentME 9y ago
  WebAssembly only uses the same web APIs as javascript, has generally been implemented using code already used for supporting javascript, and was designed from the ground up for this use inside the web sandbox, as opposed to Java which was designed in the same way as most language runtimes based around unsandboxed access to a system and then had a security layer grafted onto it.
- nipplesurvey 9y ago
  operating from the premise that most applet exploits functioned by elevating a sandboxed applet out of its sandbox (no idea if thats accurate), perhaps because java applets had an un-sandboxed mode built in, whereas wasm is always sandboxed and has no equivalent to applet's un-sandboxed mode.
  - mike_hearn 9y ago
    It's a bit tricky. I don't know if you can categorically say wasm is or will be more secure than applets. Both of them rely on a runtime that is more privileged than the code being executed, of course. Both of them can have runtime bugs that allow privilege escalation of various forms. There was a recent perma-root bug in ChromeOS and one of the exploits along the chain was based on exploiting a WebAssembly runtime bug. If you look at Java's security track record in recent years, there's been just a couple of zero days in the past five years. That's probably a mix of genuinely better security and less attention due to being kicked out of web browsers. But if you go look at the security histories of other sandboxes like browsers or kernels, it starts to look pretty good. A new paper that just came out introduced a new Linux kernel fuzzer and discovered, I think, over 30 zero day exploits across several different Android phones. So ordinary UNIX style process isolation is pretty useless if you can reach device drivers from inside the processes. Even the quite aggressive and resource intensive browser sandboxes that browsers use routinely have escapes, often because they're always adding large new attack surfaces like WebAssembly, WebGL etc (all written in C++).
tux1968 9y ago
Am I being paranoid to think this is going to be heavily used to introduce proprietary and locked down protocols and content? How long is it until this is used to render web content onto a canvas without using individual DOM elements that can be stripped by ad blockers etc. We're all focused on the potential performance rather than what this will actually be used to deliver -- so maybe i'm just missing what prevents this technology from subverting the open web.
- api 9y ago
  This is already possible using emscripten without too much effort. Emscripten JS is basically binary code. It's also been possible with Flash for over a decade, though fewer and fewer people have that installed.
- klodolph 9y ago
  "The open web" is a platform where everyone can publish and access content because the standards are open. WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like. Back in the day we had Flash-only web sites. They died off because it turns out that it's easier to just throw HTML, CSS, and JS at people, and since these were open standards, there was a fair bit of competition between different vendors to make better tools for consumption, authoring, and delivery. If you want to reimplement that experience in WebAssembly, the ROI is going to be horrible and if you render everything to a canvas your site won't be indexable by Google (goodbye traffic) or workable with screen readers (hello lawsuits).
  - wruza 9y ago
    Are lawsuits like that a real thing in EU? We’re considering to make ui, at least hard part of it, in a canvas for new web-based projects. Of course, there is no intention to discriminate people with sight issues. I think we could provide different/better interface to cover this area. Besides that, are modern sites actually accessible in that regard?
    - klodolph 9y ago

128 points by arnoooooo 9y ago

jwilk 9y ago

"#include " was meant to be "#include <webassembly.h>", but somebody forgot to escape <> in HTML source.

arnoooooo 9y ago
I thought I fixed that one :/ It's fixed for good this time. Thanks !

danschumann 9y ago

Is there a way to compile javascript in web-assembly, to protect the source code? IE, you'd have to convert the javascript to C, and then compile the C into web-assembly, right? Does V8 have a method to convert JS to C?

slededit 9y ago
WASM doesn't have access to the DOM yet so it's unlikely your JS could would work anyways.
skybrian 9y ago
That's unlikely to be efficient and it wouldn't help much anyway. Running JavaScript through an optimizing compiler and minifier will obscure pretty much the same information. But either way, you can step through the code in your browser's debugger to see what it does.
- dangerbird2 9y ago
  Also, wasm is a fairly high-level bytecode, more comparable to jvm or llvm code than arm or x86 code. It's pretty easy to follow the logic of disassembled web assembly
justinpombrio 9y ago
If you just want to obfuscate your JavaScript, there's nothing to be gained by compiling to a different language. There are already plenty of JS->JS obfuscation libraries that work well.
_greim_ 9y ago
No. wasm needs to be able to interact with the DOM and other web APIs, which I understand isn't the case currently. Then you need hooks into GC. Although I guess nothing would stop you from embedding a JS runtime in your wasm blob, other than download size.
s-macke 9y ago
This repository compiles asm.js into webassembly [1]. Otherwise, you will have a hard time to convert your Javascript code. You have to implement a JIT compiler and GC too. Webassembly was never designed to be a replacement for JavaScript. And especially, it was never designed to protect your source code. A minimizer/obsfucator does a great job of making your JavaScript code unreadable. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
- baybal2 9y ago
  >And especially, it was never designed to protect your source code. I hardly get that, all and every major backer of WASM did effectively admit at some point that "ip protection" was the one and only reason they back it. The absence of a native dom interface or proper I/O implementation at this point means that WASM compiled code actually runs slower for everyday web apps than non-compiled code.
  - the_duke 9y ago
    > all and every major backer of WASM did effectively admit at some point that "ip protection" was the one and only reason they back it. I'm sure you wouldn't mind providing sources for this bold claim?
  - s-macke 9y ago
    I have looked at obsfucated JavaScript code as well as webassembly disassembly. I don't see much difference. What might obfuscate is the fact, that it comes without any libraries. You have to program like in C without any library support, which is more or less what you do with bare metal programming now.
icebraining 9y ago
Apparently http://enclosejs.com http://enclosejs.com can compile JS to regular binaries, but I don't know if there's any way of converting an ELF binary to wasm. You could always run a full emulator + kernel (using JSLinux) to run that binary :)
Schampu 9y ago
NW.js offers Javascript code protection [0] by allowing to distribute code in bytecode form. I just tested it yesterday and my code runs as fast as the original. [0] http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/ http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%2...
kuschku 9y ago
> Is there a way to compile javascript in web-assembly, to protect the source code? This kind of obfuscation is harmful to the web, don’t do it. Also, any compsci student with a summer of free time can easily break it, so it’s useless, too. You’re just wasting your own time and the bandwidth and performance of your users. In fact, if you tell me what site you want to obfuscate your code on with WASM, I (an average compsci student) will spend my next summer reversing it, deobfuscating it, and publishing the results publicly (just to demonstrate you how useless your obfuscation is).
- danschumann 9y ago
  Is photoshop harmful to the web? Should they give away their source code? Their source code is what's valuable in their company. So, art programs kind of need source protection. I won't be making a web-version until this is the case. If you can crack NW.js source protection, let me know http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/ http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%2...
  - kuschku 9y ago
    > Is photoshop harmful to the web? Photoshop isn't on the web, but I oppose closed source in principle. > Should they give away their source code? Ideally, yes. If you do it is still your decision, but you still should be aware that if you introduce truly new concepts, someone will clean-room reverse them, and publish them. > So, art programs kind of need source protection. The Krita project begs to differ. > I won't be making a web-version until this is the case. If you can crack NW.js source protection, let me know Then you shouldn't make any build where the business code runs on the client. Even native binaries can be reversed, their functionality analyzed, and copied. Which is how LibreOffice/OpenOffice originally discovered how to parse the Microsoft Office formats.
    - danschumann 9y ago
      It's possible, but not very ideal to have all the operations done on the server, and just serve interface stuff, maybe even as a streaming video, to the client. When people paint, they want it responsive, no stream lag, no server hiccups. I must allow people to install the software on their computer. I would still like to protect the work I've done, because I'm just one guy making software, and I don't have marketing money. What would stop big companies from taking my source and spending more on advertising? I need source protection.

skocznymroczny 9y ago

WebAssembly might be a Javascript killer for high-performance uses. Javascript for uses such as game development is dragged down by the garbage collector, forcing you to orient entire code around minimizing allocations. Without garbage collection, you have to manage memory yourself, but allocations aren't as scary as they are with GC languages and they are more explicit.

vardump 9y ago
Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.
- austincheney 9y ago
  GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.
  - vardump 9y ago
    CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
  - imtringued 9y ago
    GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.

kodablah 9y ago

I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of course but as GC and threading specs come along, I can hope one day it will reach parity. Granted it isn't as low level, but that has benefits for compiler backend implementers (they can choose how they target their arch) and compiler frontend implementers (they don't have to do different things per platform). Basically, imagine if Java bytecode was developed less around OO semantics, wasn't lumped in with its stdlib by the community, didn't have encumbered JCK and other tests, etc, etc. Edit: Changed "LLVM" to "LLVM IR" to clarify as requested.

wyldfire 9y ago
Your comment was confusing to read. I think it would be easier to understand if you replaced "LLVM" with "Intermediate Representation".
RussianCow 9y ago
To me, this is the most exciting prospect of WebAssembly by far: an IR that works natively across all major platforms, including the web. It's funny because it makes Gary Bernhardt's "The Birth & Death of JavaScript"[1] seem a lot less like a joke. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
rhelmer 9y ago
This use case is interesting to me too. I looked into this a few months ago and found that there is a page on non-web embeddings: http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/
mike_hearn 9y ago
I'm not sure your criticisms of Java bytecode are all that reasonable to be honest. You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages. Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC. Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation. Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.

stromgo 9y ago

Those of you who tried WebAssembly, what kind of performance are you getting compared to native? In my application, execution time is about 200% of native, which is quite bad compared to the few benchmarks I could find: https://hacks.mozilla.org/2016/10/webassembly-browser-preview/ https://hacks.mozilla.org/2016/10/webassembly-browser-previe... https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/ https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s... It's a head-scratcher as my code is nothing special and I don't see what I could be doing wrong. Then it occurred to me that these benchmarks look suspicious, with many scores below 100%. Are there fair benchmark results somewhere, measured by someone not trying to promote WebAssembly? What performance ratios are HN readers getting currently, and what performance ratios should we expect in the long term?

vanderZwan 9y ago
Do you have your code online somewhere? What kind of tasks are you trying out? How much time is spent sending data back and forth between WASM?
steveklabnik 9y ago
I haven’t done much personally yet, but I hear it can vary quite a bit between browsers.
jdright 9y ago
https://floooh.github.io/sokol-html5/index.html https://floooh.github.io/sokol-html5/index.html You can compile these samples natively and compare yourself.

Thaxll 9y ago

ActiveX is back. Can't wait to see all the exploits escaping the browser sandbox.

anomie31 9y ago
Did ActiveX even have a sandbox?
- jamesgeck0 9y ago
  Nope! But you had to promise Verisign that you wouldn't build any malware.
cdancette 9y ago
Isn't it the same with JavaScript?
- chungy 9y ago
  Yes, and WebAssembly runs on top of the existing JavaScript VM engines.
  - Thaxll 9y ago
    I don't think it runs on the same V8 ( chrome ) that the one runs JS, I remember 2 engines running.
    - DiThi 9y ago
      The wasm binary itself may be using a separate engine, but heavily sandboxed: it can only communicate with JS, and nothing else. The (newly added) attack surface is minimal when compared with Flash, Java, etc (each with its own APIs). Almost any flaw must be in the JS side, and that's already battle-proven for years. ActiveX didn't even have a sandbox, so not even related.
      - chungy 9y ago

hughes 9y ago

I'm admittedly inexperienced with WebAssembly, but I'm a little unclear on going beyond the basic "hello world" implementations. Is the idea to write an entire application in WebAssembly, or is it to break out parts of the application that benefit from performance improvements and potentially cross-platform code bases? Also, how do you do things like make network requests or decode JSON in webassembly? Do you need to implement these things yourself, or pass things back to the browser to handle them, or find C libraries that do that for you?

kodablah 9y ago
Case by case situation. WASM is nothing but a spec and impl for CPU tasks. If you want to do something like networking, you call out to JS (today). If you want to decode JSON, you could call out to JS, or populate some part of the WASM-accessible mem (a byte array) and then ask WASM to operate on it. It could be a C library compiled to WASM or hand-written or in some other compile-to-WASM lang.

TekMol 9y ago

Is WebAssembly related to asm.js? I don't like to compile stuff. But improving performance by writing certain functions directly in assembler or in a subset of js would be awesome.

giancarlostoro 9y ago
Yes: https://en.wikipedia.org/wiki/WebAssembly#Development https://en.wikipedia.org/wiki/WebAssembly#Development
acemarke 9y ago
In a way, yes. asm.js was a deliberately limited subset of JS syntax. By adding a "use asm;" statement, you signaled to the JS engine that everything after that was limited to the asm.js subset, allowing it to simplify the parsing logic and use a fast path for loading the code. You would rarely write asm.js syntax by hand, but rather use it as a compiler output format. WebAssembly takes that further by defining a bytecode that the JS engine doesn't even have to parse, but can accept and work with more directly. This speeds up loading time. Also, loosely put, the way it's defined allows the JS engine to execute it faster. WebAssembly is definitely not intended to be written by hand. Languages like C++ and Rust can now compile to WebAssembly, allowing non-JS source code to be run in a browser. (There _is_ a textual representation of the bytecode as well.)
brian-armstrong 9y ago
Compiling stuff is awesome. I never want to discover my bugs at runtime.
- goatlover 9y ago
  Even when prototyping, exploring or doing one-offs? I'd rather have the flexibility in those situations.
  - brian-armstrong 9y ago
    Absolutely, yes. It's preferrable to trying to debug inexplicable glitches in the prototype that the compiler could have caught. And with incremental builds, compilation should be pretty lightweight anyway.

LyndsySimon 9y ago

This is the first time I've seen disassembled WASM. It's actually quite readable!

dchest 9y ago

function readUtf8String(memory, pointer) { let s = ""; for (i = pointer; memory[i]!==0; i++) { s += String.fromCharCode(memory[i]); } return s; } This doesn't read UTF-8, this reads bytes and converts them to UTF-16 char codes, so it works only with ASCII or some other 0-255 encoding. To read UTF-8 into a JavaScript string (which is UTF-16), bytes should be properly decoded from UTF-8 (e.g. with TextDecoder).

arnoooooo 9y ago
Thanks ! I've renamed the function accordingly.
- chrismorgan 9y ago
  ASCII only covers values 0–127; this function allows 128–255 as well, which makes it ISO-8859-1 (latin1), the first 256 code points of Unicode being the entirety of ISO-8859-1.

thephyber 9y ago

Can someone explain to me why we would expect WebAssembly to be much different than Java Applets? There are inevitably defects in the design and/or implementation which will open up browsers to gaping security vulnerabilities until they are found and fixed.

AgentME 9y ago
WebAssembly only uses the same web APIs as javascript, has generally been implemented using code already used for supporting javascript, and was designed from the ground up for this use inside the web sandbox, as opposed to Java which was designed in the same way as most language runtimes based around unsandboxed access to a system and then had a security layer grafted onto it.
nipplesurvey 9y ago
operating from the premise that most applet exploits functioned by elevating a sandboxed applet out of its sandbox (no idea if thats accurate), perhaps because java applets had an un-sandboxed mode built in, whereas wasm is always sandboxed and has no equivalent to applet's un-sandboxed mode.
- mike_hearn 9y ago
  It's a bit tricky. I don't know if you can categorically say wasm is or will be more secure than applets. Both of them rely on a runtime that is more privileged than the code being executed, of course. Both of them can have runtime bugs that allow privilege escalation of various forms. There was a recent perma-root bug in ChromeOS and one of the exploits along the chain was based on exploiting a WebAssembly runtime bug. If you look at Java's security track record in recent years, there's been just a couple of zero days in the past five years. That's probably a mix of genuinely better security and less attention due to being kicked out of web browsers. But if you go look at the security histories of other sandboxes like browsers or kernels, it starts to look pretty good. A new paper that just came out introduced a new Linux kernel fuzzer and discovered, I think, over 30 zero day exploits across several different Android phones. So ordinary UNIX style process isolation is pretty useless if you can reach device drivers from inside the processes. Even the quite aggressive and resource intensive browser sandboxes that browsers use routinely have escapes, often because they're always adding large new attack surfaces like WebAssembly, WebGL etc (all written in C++).

tux1968 9y ago

Am I being paranoid to think this is going to be heavily used to introduce proprietary and locked down protocols and content? How long is it until this is used to render web content onto a canvas without using individual DOM elements that can be stripped by ad blockers etc. We're all focused on the potential performance rather than what this will actually be used to deliver -- so maybe i'm just missing what prevents this technology from subverting the open web.

api 9y ago
This is already possible using emscripten without too much effort. Emscripten JS is basically binary code. It's also been possible with Flash for over a decade, though fewer and fewer people have that installed.
klodolph 9y ago
"The open web" is a platform where everyone can publish and access content because the standards are open. WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like. Back in the day we had Flash-only web sites. They died off because it turns out that it's easier to just throw HTML, CSS, and JS at people, and since these were open standards, there was a fair bit of competition between different vendors to make better tools for consumption, authoring, and delivery. If you want to reimplement that experience in WebAssembly, the ROI is going to be horrible and if you render everything to a canvas your site won't be indexable by Google (goodbye traffic) or workable with screen readers (hello lawsuits).
- wruza 9y ago
  Are lawsuits like that a real thing in EU? We’re considering to make ui, at least hard part of it, in a canvas for new web-based projects. Of course, there is no intention to discriminate people with sight issues. I think we could provide different/better interface to cover this area. Besides that, are modern sites actually accessible in that regard?
  - klodolph 9y ago