24 ms·

WebAssembly support now shipping in all major browsers

574 points by subir 9y ago

fergie 9y ago
Can anybody ELI5? The documentation is pretty fluffy. Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? Whats new avenues of development is WebAssembly expected to open up? Is the whole point just to enable an easy way to compile games made on other platforms (Unity) to the web?
- SirHound 9y ago
  I can address at least the first misconception here - this isn’t transpilation to JS. This is native code that has browser APIs exposed to it, so in theory there should be massive performance wins.
  - poizan42 9y ago
    This is also a misconception, it is just a bytecode. asm.js is already running at around 50% native speed so there is no massive performance wins to find. What you get with WebAssembly is reduced startup time because it doesn't have to be parsed first. The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- exDM69 9y ago
  WASM is used to run native code in the Web browser without going through JavaScript. With it, it should be possible to run code at near-native performance in the browser. WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code. WASM is a bit similar to LLVM IR, but it's architecture independent. Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code. > I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.
  - fergie 9y ago
    Oh I see- that makes sense.
  - qaq 9y ago
    But is this how it is implemented by actual browsers? if memory serves v8 is pretty much reusing most of JS VM for WASM?
    - exDM69 9y ago
      Yes, the browsers do share parts of their JavaScript execution engine with WASM. Which makes sense because WASM still needs to interact with JS. That doesn't mean it can't be fast or start quickly (or at least quicker than asm.js). From the developer's point of view that doesn't matter. You're delivering WASM and not C or JS code over to the clients.
    - marcosdumay 9y ago
      WASM requires a much simpler VM than JS. It doesn't take most of a JS VM.
- steveklabnik 9y ago
  WebAssembly is a specification of a small assembly language. This language can call into functions in its host environment. The "web" part is that all evergreen web browsers have implemented this language, and you can use it from inside your browser, and call JavaScript functions into it. This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain. It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.
- Fredx87 9y ago
  Today the browsers virtual machines can work only with Javascript code. That means that if you want to use another language you have to convert in to Javascript, and you are obviously limited by the features of Javascript. The goal of WASM is to provide a language similar to Assembly (or bytecode of Java) that can be understood by the virtual machines of browser, and so to have a new way to compile languages and use them in the browsers. WASM can also be optimized better, having more features than Javascript (for example javascript uses only double as number types, while WASM has integers and floats)
- nfriedly 9y ago
  WebAssembly is (currently) the same as asm.js, but with smaller file size and faster parse times. Asm.js is just a subset of JavaScript that can be optimized because it doesn't use certain features (like strings or garbage collection). WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them. The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for. There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app. Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.
dmitriid 9y ago
Ok, now we need GC and DOM interop. Because reinventing layouts is pain.
- zaarn 9y ago
  IIRC you can do GC within WebAssembly (though it's less nice and awkward as I've been told). But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)
  - lj3 9y ago
    It doesn't sound like that will be possible. DOM interop is baked into the Garbage Collection task[0]. It sounds like there's a dependency there, somewhere. [0]: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/
    - steveklabnik 9y ago
      Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.
      - lj3 9y ago
        Do you have a link to the separated proposals? It certainly seems entwined on the official roadmap.
        steveklabnik 9y ago
        https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/
        lj3 9y ago
p49k 9y ago
Do any mobile browsers support it yet? The article is unclear.
- clouddrover 9y ago
  Safari does on iOS 11: https://webkit.org/blog/7956/new-webkit-features-in-safari-11/ https://webkit.org/blog/7956/new-webkit-features-in-safari-1... https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html https://developer.apple.com/library/content/releasenotes/Gen...
  - Klathmon 9y ago
    But does a WebView? I recently discovered that while Safari supports WebRTC, a "WebView" or a safari view that is added to the home screen does not.
    - shurcooL 9y ago
      It works in Chrome on iOS.
    - om2 9y ago
      WKWebView and SFSafariViewController both support Web Assembly in iOS 11.
baybal2 9y ago
Java applets 2.0, we are back to square one, yet again. People don't learn. The web dev community have just managed to force browsermakers to unify web development on browser side JS, and throw Java applets, activex, and action script to the bucket, just to have a kind of JVM being made a part of the web standard, and forced upon us yet again.
- eknkc 9y ago
  Having a unified VM with established sandboxing requirements is nothing like JVM. It's more like JavaScript itself, only lower level. What's bad about this?
- everheardofc 9y ago
  Webkit only has 10k LOC specific to WebAssembly because like every other browser it reuses the javascript JIT. That's an incredibly tiny part of the entire browser.
- RX14 9y ago
  There are some clear and defining differences between Java applets and webassembly. The core problems with Java were that the security sucked, and that applets were non-native and didn't use the dom. I doubt there is any desire in web developers to overuse canvasses and do layout in wasm, and the security model should hopefully be as successful as JS's has been over the years.
  - baybal2 9y ago
    > The core problems with Java were that the security sucked The core problem with Java applets was that they were Java applets An option to keep the source of the web app closed will fragment the web dev community yet again.
    - MaxBarraclough 9y ago
      > An option to keep the source of the web app closed will fragment the web dev community yet again. But this changes nothing. It was always possible to obfuscate JavaScript, just like every other programming language.
chkuendig 9y ago
Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not having an existing C fallback as all other platforms we target have SIMD support)
- steveklabnik 9y ago
  My understanding is that SIMD support has a proposal that most people are happy with, and will be landing in 2018.
  - titzer 9y ago
    Right now there are SIMD prototypes in 3 engines (SpiderMonkey, ChakraCore, and V8) and the remaining work is standardization between them, tool support, and performance tuning. There will be an official SIMD proposal for WASM in 2018 and it should move through the standardization process pretty quickly.
- zurn 9y ago
  SIMD is like the kids version of GLSL, which works today :)
  - tomxor 9y ago
    Not sure what you mean (maybe i'm missing your point) but those two things are not very comparable. GLSL is an uncompiled GPU language and SIMD is a class of CPU instructions that exploit parallelism opportunities at the block level (apposed to core level like a GPU).
    - zurn 9y ago
      Both can be be used to accelerate the image processing application in question. GLSL is compiled on the fly to GPU instructions that exploit parallelism opportunities, but more so than SIMD because GPUs have greater internal paralllelism.
holydude 9y ago
Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)
- phkahler 9y ago
  >> Seriously JS should not be the lingua franca of the web But neither should this. Really, keep your code off my computer as much as possible.
  - jazoom 9y ago
    But what is a computer for if not running other people's code? I can't imagine there are many people in this world who have a computer with more than even 1% their own code running on it.
    - phkahler 9y ago
      Red herring. People install or explicitly download code they want to run. The general public doesn't even realize that most web pages are full of code (js not html) and most developers have gotten so used to it they feel entitled. The goal should be to try harder to use less code, not enable native execution. I understand, engineers like to think about what is possible (wouldn't it be cool if..!) but sometime they need to check their ego and consider context.
      - jazoom 9y ago
        99%+ of people don't think like you and don't care about the distinction between code on the browser and code on the OS. "A red herring is something that misleads or distracts from a relevant or important issue. It may be either a logical fallacy or a literary device that leads readers or audiences towards a false conclusion." I don't see how my comment is a red herring. Computers are for running code. That's what they do. You said you don't want other people's code running on your computer. Bad news for you, that's all your computer does.
indy 9y ago
For people wondering about features like SIMD and GC support, here is a good status page: http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/
- tom_mellior 9y ago
  Specifically for GC, all that page does is to refer to a GitHub issue that is invisible to anyone but WASM contributors :-(
  - Ajedi32 9y ago
    Invisible? You mean locked? https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
    - tom_mellior 9y ago
      Yes, I see that there is an issue there, but the discussion is invisible. Hidden. Locked.
      - Ajedi32 9y ago
        > invisible. Hidden It's not. It's just that there are no other posts on that issue. GitHub does not have a way to make an issue visible to the public but hide all discussion on it. > Locked That's not the same thing. Locked just means you can't add your own comments, not that you can't see comments from other users.
        tom_mellior 9y ago
        Ah ok, thanks. That there is no discussion is even more disappointing.
dalbasal 9y ago
For those in the know, what doors is web assembly expected to open? Better cross platform platforms via a browser wrap? Will new types of browser applications be possible that aren't now in JS only world? What are they?
- pjmlp 9y ago
  Expect every language out there to have a WebAssembly implementation, including Flash.
  - tonyg 9y ago
    Until wasm supports proper tail calls, only the ones with uninteresting control structures.
    - simias 9y ago
      Couldn't the compiler take care of optimizing those when necessary? After all I don't know of any "real" assembly with tail call support...
      - panic 9y ago
        Most assembly languages have a "jump" instruction, though -- wasm supports only structured control flow.
        pjmlp 9y ago
        It has br and loop, good enough.
        int_19h 9y ago
        I don't think it's sufficient for full-fledged generalized tail call elimination. You can certainly optimize a self-recursive call down to a loop, but consider a case where a function accepts another function as a pointer, and invokes that pointer in a tail call position, for example (i.e. anything written in continuation-passing style).
KeitIG 9y ago
A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- steveklabnik 9y ago
  Also relevant: callahad a few weeks ago: https://twitter.com/nybblr/status/923569208935493632 https://twitter.com/nybblr/status/923569208935493632 Netscape navigator on DOS in Firefox via WebAssembly.
- indescions_2017 9y ago
  Or how about a live coding environment for a Atari VCS (1200) emulator ;) http://8bitworkshop.com/?platform=vcs&file=examples%2Fhello http://8bitworkshop.com/?platform=vcs&file=examples%2Fhello
- sp332 9y ago
  And for a somewhat more practical but at the same time more exotic example, the Internet Archive has a ton of old minicomputers and arcade games running in MESS/MAME, each compiled to webasm. One click and you can boot anything and play it in your browser. https://archive.org/details/softwarelibrary https://archive.org/details/softwarelibrary https://archive.org/donate/ https://archive.org/donate/
  - ricw 9y ago
    This is amazing. If only it would also work in my phone. Probably for the best to stop me “wasting” time ;).
  - Ajedi32 9y ago
    Are you sure that's actually using WASM? It sounds to me like it's currently using ASM.js compiled via Emscripten. (Though in theory there's no reason why it _couldn't_ be WASM, since Emscripten supports WASM as a compiler target.)
singularity2001 9y ago
did they improve external stacktrace support? the last time I checked debugging was imposible due to bad stacktraces.
- steveklabnik 9y ago
  My understanding is that the current debugging tools can show you the text format of wasm, but showing the original code you compiled to wasm doesn't work quite yet. It's under discussion.
pjmlp 9y ago
Great, time to port SWF to WebAssembly.
Yuioup 9y ago
Can't wait for a port of Angular2+ to C#.
bitL 9y ago
How do I compile/target stuff for WebAssembly and integrate it with "usual web" (I need to use some advanced math & WebGL real-time that is too slow in JS)? Is there any good tutorial? Thanks!
- steveklabnik 9y ago
  Currently, the best supported languages are C, C++, and Rust. Languages that have runtimes require their runtimes to also be compiled in, and so are much heavier weight. For C and C++, you have emscripten. For Rust, we have an emscripten-based toolchain that works today, but have a PR open for using LLVM's built-in wasm backend. For emscripten: https://kripken.github.io/emscripten-site/docs/# https://kripken.github.io/emscripten-site/docs/# For Rust: https://hackernoon.com/compiling-rust-to-webassembly-guide-411066a69fde https://hackernoon.com/compiling-rust-to-webassembly-guide-4... (slightly older but still should work afaik) And the new backend https://github.com/rust-lang/rust/pull/45905 https://github.com/rust-lang/rust/pull/45905
- flohofwoe 9y ago
  The "awesome wasm" link collection has many good starting points: https://github.com/mbasso/awesome-wasm https://github.com/mbasso/awesome-wasm
deleted 9y ago
[deleted]
bitL 9y ago
Soon we will all have JDK, .NET runtime and WAsm runtime running on our machines.
etatoby 9y ago
Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on. Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer wanted to use Python or whatever. The web is getting better by the day.
- moron4hire 9y ago
  Then there should be a huge market opportunity to provide identical services at far smaller and faster downloads.
- steveklabnik 9y ago
  wasm is modular, so in theory, you could produce a jvm9.wasm file, put it on a CDN with caching, and every site that wanted to do that could share it, and you'd only download it once. I do agree that runtime-less languages have an advantage here though.
- rl3 9y ago
  We're still a long ways off from garbage-collected languages inside wasm. That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.
  - boomlinde 9y ago
    > We're still a long ways off from garbage-collected languages inside wasm. I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua
    - FRex 9y ago
hannofcart 9y ago
All the excitement around wasm seems quite puzzling to me. Yes, I understand that you can program in whatever language you love but what new language are you hoping would be supported? C? C++? Fortran? As far as I am concerned, all the languages I care about already have compilers that target JS.
- drchickensalad 9y ago
  There is a massive performance difference between compiling to js and compiling to wasm.
- bluejekyll 9y ago
  Rust is the big one for me, personally. The idea of being to write in one language for embedded software, system software, cli tools, web applications, distributed applications, and now the web client? That's a very enticing idea. It might finally be the realization of what Java failed to accomplish (technically it did, but never gained a lot of traction on the client b/c it was too slow at the time).
- orthecreedence 9y ago
  Another Rustacean checking in. I'd love to write Rust and run it in the browser. Rust uses LLVM so it can use emscripten already, but having closer to native speeds would be great.
- int_19h 9y ago
  JS imposes a memory/object model that doesn't map to other languages particularly well, so you either have to play fast and loose with semantics (effectively creating a dialect of the language that you're transpiling), or pay extra overhead for faithfully emulating the original behavior. WASM is much lower level, and should allow compilers and VMs to use best-fitting data structures and layout.
jlebrech 9y ago
I want to see a WASM+react framework where the application state/logic is fully in WASM and merely the rendering is done by react.
- twfarland 9y ago
  I would want the inverse of that, where the application logic is in some high-level language, and the rendering is done in WASM, i.e. react-dom and the diffing parts of react are in WASM.
pfalke 9y ago
„...all major browsers“ Is Internet Explorer not a major browser anymore? I’m talking relevant as in your webpage needs to work fine in Internet Explorer. For example, my company still has Internet Explorer configured as default browser as Edge is not compatible with some internal pages.
- olegkikin 9y ago
  IE is not a major browser anymore http://gs.statcounter.com/ http://gs.statcounter.com/ Look at your Google Analytics, it's really not that important anymore.
  - sametmax 9y ago
    In corporate env it is.
    - foodstances 9y ago
      Either the computers in these mysterious corporate environments are exposed to the internet, in which case they'd be reflected in these public stats collected by them visiting public websites from IE, or they aren't, in which case they don't matter in the slightest because they're not going to visit webpages using WebAssembly.
      - dragonwriter 9y ago
        Or, as is absolutely the case, because of the aggressive blocking and monitoring policies and restrictive usage policies in place in the kind of enterprises where IE remains common, they are exposed to the public internet and use public webpages, but with usage patterns which leave them underrepresented on the kind of sites that use third-party stat counters. OTOH, for certain other public websites, they are very large numbers of users.
      - romaniv 9y ago
        IE can account for a fraction of total traffic, but it still can affect large percentage of users. The same person can use several devices (work, home, mobile) to browse the web at different times. I can't recount how many times I saw some page at work only to send myself the link to read it later. I'm not forced to use IE anywhere, but if I were, loosing that initial visit would also lower the number of visits from other browsers.
isaiahg 9y ago
I'm not as excited for this as I used to be. In most user applications JavaScript is good enough or better. If it wasn't then we wouldn't be taking the browser to make desktop applications. Recently I decided to make a desktop app and asked around about the different UI libraries. The answer I keep getting is "just use electron and JavaScript". Why? Because love it or hate it the Dom is fantastic and simple for making UIs that are interactive and reliable. And you can't beat JavaScript for manipulating the Dom. The only benefit I can think of that benefits is specialized software like games or scientific analysis/simulation. But for what most users want, JavaScript is fast enough. The example I keep hearing is "imagine gimp in the browser" but it's already possible to make a gimp like application in the browser using things like canvas and the file api. So by the time webassembly is ready for the prime and has needed features like memory management and Dom access, will it even by worth it beyond a few specific applications?
- mythmon_ 9y ago
  One interesting thing to me is that you don't have to write an entire app using only WebAssembly or JS. You can take the classic approach of benchmarking to find hotspots, and then optimizing those. Migrating these performance sensitive sections to more performant code can be a win.
- steven777400 9y ago
  I'll agree with you that modern HTML and CSS for presentation is best-of-breed. I'll accept that the DOM API is sufficient. But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.
- wruza 9y ago
  >you can't beat JavaScript for manipulating the Dom. Exactly. Only javascript can access attributes and call functions so good on exported document and window objects.
- andrewingram 9y ago
  I know that Figma is built on WebAssembly now, and has quite impressive performance.
themihai 9y ago
Without DOM it's not really that exciting.
- steveklabnik 9y ago
  There is a lot of processing that doesn't inherently need the DOM, and there's also server-side stuff as well. I think you'd be surprised!
  - themihai 9y ago
    Yeah, but WASM was supposed to democratise the web development not to do just server-side stuff. Without DOM and Web APIs you can't do much Web related.
    - steveklabnik 9y ago
      There's tons of tooling written in JS for JS that doesn't need DOM access to work, for example.
      - themihai 9y ago
        If you talk about Node I would say that only proves my point that people go to great lengths to use their preferred language whenever possible. Tell them to use JS only for DOM stuff and wasm for things that don't need DOM. Nobody would prefers a FFI between wasm and js instead of plain wasm if given the option to choose.
    - CyberDildonics 9y ago
      > not to do just server-side stuff He didn't say anything about 'only server side stuff'. There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.
      - themihai 9y ago
blaze33 9y ago
If you're looking for an introduction to WebAssembly my "WebAssembly 101: a developer's first steps" post had some success here: https://blog.openbloc.fr/webassembly-first-steps/ https://blog.openbloc.fr/webassembly-first-steps/ HN discussion: https://news.ycombinator.com/item?id=14495893 https://news.ycombinator.com/item?id=14495893 The awesome-wasm list is also a good start: https://github.com/mbasso/awesome-wasm https://github.com/mbasso/awesome-wasm
dmix 9y ago
The math site they linked to in the examples of sites powered by WebAssembly is awesome: http://mathstud.io/ http://mathstud.io/ I almost wish I was a student again so I could relearn math for the first time with all of these great tools...
- ZeroCool2u 9y ago
  Wow, that is really cool actually. Impressive performance on my OG Pixel XL too.
vanderZwan 9y ago
Aside: how is WebAssembly's binary form currently shipped? In a demo I saw yesterday it was written out inline as a Uint8Array of integers between 0-255. Even with gzip enabled this can't be very efficient. For completely unrelated reasons, I was already thinking of adapting (my fork of) the LZ-string library[0] to directly compress/decompress typed arrays to "websafe" UTF16 strings, similar to the already existing `compressToUTF16` functionality in LZ-string. Essentially, the strings would represent LZ-compressed bitstreams, using 15 bits per string character. Could this be useful for reducing the size of WASM binary when encoded in plain JavaScript? (the minified library would probably be around 1kb after gzip) [0] https://github.com/JobLeonard/lz-string/tree/array-lookup https://github.com/JobLeonard/lz-string/tree/array-lookup [1] http://pieroxy.net/blog/pages/lz-string/index.html#inline_menu_6 http://pieroxy.net/blog/pages/lz-string/index.html#inline_me...
- esrauch 9y ago
  wasm files are already a binary format, an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.
  - vanderZwan 9y ago
    Right, I thought it was odd; I remember reading that part of the big benefit of WASM was more compact, faster-to-parse source code. Going all the way up to text form and back down to binary data is at odds with that. > an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it. Are there any realistic scenarios where this is the more sensible option? Anyway, I should have searched MDN first, the relevant bit of documentation is pretty clear: fetch('simple.wasm').then(response => response.arrayBuffer() ).then(bytes => WebAssembly.instantiate(bytes, importObject) ).then(results => { results.instance.exports.exported_func(); }); https://developer.mozilla.org/en-US/docs/WebAssembly/Loading_and_running#Using_Fetch https://developer.mozilla.org/en-US/docs/WebAssembly/Loading...
    - esrauch 9y ago
rhabarba 9y ago
WebAssembly is not worth the effort unless it finally is supported by the LINK tag. Seriously, using JS to load a JS alternative is ridiculous.
- themihai 9y ago
  I can't agree more...but I believe the issue is that WASM sold a lie. Right now if you read between the lines it is argued that WASM is there just to help JS do more not to replace it.
  - rhabarba 9y ago
    I played a bit with WASM and I like its approach, but the one thing that annoys me most with web development is the limited number of client-side languages. WASM can be great if they allow it to.
  - saosebastiao 9y ago
    > WASM is there just to help JS do more not to replace it That certainly is a shame, but it's not like we have to accept that as the future. HTML is a document markup language, but we've hijacked it to build interactive UIs. It might be that WASM is just a native-ish FFI system for javascript today, but tomorrow it could be something completely different.
  - moosingin3space 9y ago
    > WASM sold a lie What? The original WebAssembly announcement[1], which can be viewed as the manifesto for how WASM was envisioned, it clearly says "once browsers support the WebAssembly syntax natively, JS and wasm can diverge". Eich's goal with WebAssembly is not replacing JS, it's providing a better compilation target for other languages. WebAssembly is a replacement for asm.js, not JavaScript. No one is selling a lie here. [1]: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
- krapp 9y ago
  Before HTML5 deprecated it, it was assumed that browsers would just supply plugins to support various scripting languages or whatever, which is why the <script> tag had a type attribute. Unfortunately, integrating a new runtime like <script type="text/lua" src="main.lua" module="lua.wasm"/> will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a difference.) <object> might be a good candidate but I don't know if it's still supported. But, we can't get rid of JS altogether. Browsers will have to support javascript indefinitely, otherwise most of the web becomes unreadable. That being the case, using JS to load WebAssembly seems like the most reasonable backwards-compatible compromise available.
pier25 9y ago
Any news on access to DOM progress?
- steveklabnik 9y ago
  I commented elsewhere in the thread about the latest proposal.
capablemonkey 9y ago
Who wants to write a faster CryptoNight miner in wasm?
kyzlaitis 9y ago
Nice advertisement
r00fus 9y ago
Based on the unbridled capabilities, I can't wait for a way to block WASM. Does noscript do this yet?
- steveklabnik 9y ago
  What "unbridled capabilities" are you referring to?

574 points by subir 9y ago

Can anybody ELI5? The documentation is pretty fluffy. Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? Whats new avenues of development is WebAssembly expected to open up? Is the whole point just to enable an easy way to compile games made on other platforms (Unity) to the web?

SirHound 9y ago
I can address at least the first misconception here - this isn’t transpilation to JS. This is native code that has browser APIs exposed to it, so in theory there should be massive performance wins.
- poizan42 9y ago
  This is also a misconception, it is just a bytecode. asm.js is already running at around 50% native speed so there is no massive performance wins to find. What you get with WebAssembly is reduced startup time because it doesn't have to be parsed first. The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
exDM69 9y ago
WASM is used to run native code in the Web browser without going through JavaScript. With it, it should be possible to run code at near-native performance in the browser. WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code. WASM is a bit similar to LLVM IR, but it's architecture independent. Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code. > I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.
- fergie 9y ago
  Oh I see- that makes sense.
- qaq 9y ago
  But is this how it is implemented by actual browsers? if memory serves v8 is pretty much reusing most of JS VM for WASM?
  - exDM69 9y ago
    Yes, the browsers do share parts of their JavaScript execution engine with WASM. Which makes sense because WASM still needs to interact with JS. That doesn't mean it can't be fast or start quickly (or at least quicker than asm.js). From the developer's point of view that doesn't matter. You're delivering WASM and not C or JS code over to the clients.
  - marcosdumay 9y ago
    WASM requires a much simpler VM than JS. It doesn't take most of a JS VM.
steveklabnik 9y ago
WebAssembly is a specification of a small assembly language. This language can call into functions in its host environment. The "web" part is that all evergreen web browsers have implemented this language, and you can use it from inside your browser, and call JavaScript functions into it. This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain. It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.
Fredx87 9y ago
Today the browsers virtual machines can work only with Javascript code. That means that if you want to use another language you have to convert in to Javascript, and you are obviously limited by the features of Javascript. The goal of WASM is to provide a language similar to Assembly (or bytecode of Java) that can be understood by the virtual machines of browser, and so to have a new way to compile languages and use them in the browsers. WASM can also be optimized better, having more features than Javascript (for example javascript uses only double as number types, while WASM has integers and floats)
nfriedly 9y ago
WebAssembly is (currently) the same as asm.js, but with smaller file size and faster parse times. Asm.js is just a subset of JavaScript that can be optimized because it doesn't use certain features (like strings or garbage collection). WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them. The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for. There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app. Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.

dmitriid 9y ago

Ok, now we need GC and DOM interop. Because reinventing layouts is pain.

zaarn 9y ago
IIRC you can do GC within WebAssembly (though it's less nice and awkward as I've been told). But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)
- lj3 9y ago
  It doesn't sound like that will be possible. DOM interop is baked into the Garbage Collection task[0]. It sounds like there's a dependency there, somewhere. [0]: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/
  - steveklabnik 9y ago
    Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.
    - lj3 9y ago
      Do you have a link to the separated proposals? It certainly seems entwined on the official roadmap.
      - steveklabnik 9y ago
        https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/
        lj3 9y ago

p49k 9y ago

Do any mobile browsers support it yet? The article is unclear.

clouddrover 9y ago
Safari does on iOS 11: https://webkit.org/blog/7956/new-webkit-features-in-safari-11/ https://webkit.org/blog/7956/new-webkit-features-in-safari-1... https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html https://developer.apple.com/library/content/releasenotes/Gen...
- Klathmon 9y ago
  But does a WebView? I recently discovered that while Safari supports WebRTC, a "WebView" or a safari view that is added to the home screen does not.
  - shurcooL 9y ago
    It works in Chrome on iOS.
  - om2 9y ago
    WKWebView and SFSafariViewController both support Web Assembly in iOS 11.

baybal2 9y ago

Java applets 2.0, we are back to square one, yet again. People don't learn. The web dev community have just managed to force browsermakers to unify web development on browser side JS, and throw Java applets, activex, and action script to the bucket, just to have a kind of JVM being made a part of the web standard, and forced upon us yet again.

eknkc 9y ago
Having a unified VM with established sandboxing requirements is nothing like JVM. It's more like JavaScript itself, only lower level. What's bad about this?
everheardofc 9y ago
Webkit only has 10k LOC specific to WebAssembly because like every other browser it reuses the javascript JIT. That's an incredibly tiny part of the entire browser.
RX14 9y ago
There are some clear and defining differences between Java applets and webassembly. The core problems with Java were that the security sucked, and that applets were non-native and didn't use the dom. I doubt there is any desire in web developers to overuse canvasses and do layout in wasm, and the security model should hopefully be as successful as JS's has been over the years.
- baybal2 9y ago
  > The core problems with Java were that the security sucked The core problem with Java applets was that they were Java applets An option to keep the source of the web app closed will fragment the web dev community yet again.
  - MaxBarraclough 9y ago
    > An option to keep the source of the web app closed will fragment the web dev community yet again. But this changes nothing. It was always possible to obfuscate JavaScript, just like every other programming language.

chkuendig 9y ago

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not having an existing C fallback as all other platforms we target have SIMD support)

steveklabnik 9y ago
My understanding is that SIMD support has a proposal that most people are happy with, and will be landing in 2018.
- titzer 9y ago
  Right now there are SIMD prototypes in 3 engines (SpiderMonkey, ChakraCore, and V8) and the remaining work is standardization between them, tool support, and performance tuning. There will be an official SIMD proposal for WASM in 2018 and it should move through the standardization process pretty quickly.
zurn 9y ago
SIMD is like the kids version of GLSL, which works today :)
- tomxor 9y ago
  Not sure what you mean (maybe i'm missing your point) but those two things are not very comparable. GLSL is an uncompiled GPU language and SIMD is a class of CPU instructions that exploit parallelism opportunities at the block level (apposed to core level like a GPU).
  - zurn 9y ago
    Both can be be used to accelerate the image processing application in question. GLSL is compiled on the fly to GPU instructions that exploit parallelism opportunities, but more so than SIMD because GPUs have greater internal paralllelism.

holydude 9y ago

Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)

phkahler 9y ago
>> Seriously JS should not be the lingua franca of the web But neither should this. Really, keep your code off my computer as much as possible.
- jazoom 9y ago
  But what is a computer for if not running other people's code? I can't imagine there are many people in this world who have a computer with more than even 1% their own code running on it.
  - phkahler 9y ago
    Red herring. People install or explicitly download code they want to run. The general public doesn't even realize that most web pages are full of code (js not html) and most developers have gotten so used to it they feel entitled. The goal should be to try harder to use less code, not enable native execution. I understand, engineers like to think about what is possible (wouldn't it be cool if..!) but sometime they need to check their ego and consider context.
    - jazoom 9y ago
      99%+ of people don't think like you and don't care about the distinction between code on the browser and code on the OS. "A red herring is something that misleads or distracts from a relevant or important issue. It may be either a logical fallacy or a literary device that leads readers or audiences towards a false conclusion." I don't see how my comment is a red herring. Computers are for running code. That's what they do. You said you don't want other people's code running on your computer. Bad news for you, that's all your computer does.

indy 9y ago

For people wondering about features like SIMD and GC support, here is a good status page: http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/

tom_mellior 9y ago
Specifically for GC, all that page does is to refer to a GitHub issue that is invisible to anyone but WASM contributors :-(
- Ajedi32 9y ago
  Invisible? You mean locked? https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
  - tom_mellior 9y ago
    Yes, I see that there is an issue there, but the discussion is invisible. Hidden. Locked.
    - Ajedi32 9y ago
      > invisible. Hidden It's not. It's just that there are no other posts on that issue. GitHub does not have a way to make an issue visible to the public but hide all discussion on it. > Locked That's not the same thing. Locked just means you can't add your own comments, not that you can't see comments from other users.
      - tom_mellior 9y ago
        Ah ok, thanks. That there is no discussion is even more disappointing.

dalbasal 9y ago

For those in the know, what doors is web assembly expected to open? Better cross platform platforms via a browser wrap? Will new types of browser applications be possible that aren't now in JS only world? What are they?

pjmlp 9y ago
Expect every language out there to have a WebAssembly implementation, including Flash.
- tonyg 9y ago
  Until wasm supports proper tail calls, only the ones with uninteresting control structures.
  - simias 9y ago
    Couldn't the compiler take care of optimizing those when necessary? After all I don't know of any "real" assembly with tail call support...
    - panic 9y ago
      Most assembly languages have a "jump" instruction, though -- wasm supports only structured control flow.
      - pjmlp 9y ago
        It has br and loop, good enough.
        int_19h 9y ago
        I don't think it's sufficient for full-fledged generalized tail call elimination. You can certainly optimize a self-recursive call down to a loop, but consider a case where a function accepts another function as a pointer, and invokes that pointer in a tail call position, for example (i.e. anything written in continuation-passing style).

KeitIG 9y ago

A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

steveklabnik 9y ago
Also relevant: callahad a few weeks ago: https://twitter.com/nybblr/status/923569208935493632 https://twitter.com/nybblr/status/923569208935493632 Netscape navigator on DOS in Firefox via WebAssembly.
indescions_2017 9y ago
Or how about a live coding environment for a Atari VCS (1200) emulator ;) http://8bitworkshop.com/?platform=vcs&file=examples%2Fhello http://8bitworkshop.com/?platform=vcs&file=examples%2Fhello
sp332 9y ago
And for a somewhat more practical but at the same time more exotic example, the Internet Archive has a ton of old minicomputers and arcade games running in MESS/MAME, each compiled to webasm. One click and you can boot anything and play it in your browser. https://archive.org/details/softwarelibrary https://archive.org/details/softwarelibrary https://archive.org/donate/ https://archive.org/donate/
- ricw 9y ago
  This is amazing. If only it would also work in my phone. Probably for the best to stop me “wasting” time ;).
- Ajedi32 9y ago
  Are you sure that's actually using WASM? It sounds to me like it's currently using ASM.js compiled via Emscripten. (Though in theory there's no reason why it _couldn't_ be WASM, since Emscripten supports WASM as a compiler target.)

singularity2001 9y ago

did they improve external stacktrace support? the last time I checked debugging was imposible due to bad stacktraces.

steveklabnik 9y ago
My understanding is that the current debugging tools can show you the text format of wasm, but showing the original code you compiled to wasm doesn't work quite yet. It's under discussion.

pjmlp 9y ago

Great, time to port SWF to WebAssembly.

Yuioup 9y ago

Can't wait for a port of Angular2+ to C#.

bitL 9y ago

How do I compile/target stuff for WebAssembly and integrate it with "usual web" (I need to use some advanced math & WebGL real-time that is too slow in JS)? Is there any good tutorial? Thanks!

steveklabnik 9y ago
Currently, the best supported languages are C, C++, and Rust. Languages that have runtimes require their runtimes to also be compiled in, and so are much heavier weight. For C and C++, you have emscripten. For Rust, we have an emscripten-based toolchain that works today, but have a PR open for using LLVM's built-in wasm backend. For emscripten: https://kripken.github.io/emscripten-site/docs/# https://kripken.github.io/emscripten-site/docs/# For Rust: https://hackernoon.com/compiling-rust-to-webassembly-guide-411066a69fde https://hackernoon.com/compiling-rust-to-webassembly-guide-4... (slightly older but still should work afaik) And the new backend https://github.com/rust-lang/rust/pull/45905 https://github.com/rust-lang/rust/pull/45905
flohofwoe 9y ago
The "awesome wasm" link collection has many good starting points: https://github.com/mbasso/awesome-wasm https://github.com/mbasso/awesome-wasm

deleted 9y ago

[deleted]

bitL 9y ago

Soon we will all have JDK, .NET runtime and WAsm runtime running on our machines.

etatoby 9y ago

Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on. Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer wanted to use Python or whatever. The web is getting better by the day.

moron4hire 9y ago
Then there should be a huge market opportunity to provide identical services at far smaller and faster downloads.
steveklabnik 9y ago
wasm is modular, so in theory, you could produce a jvm9.wasm file, put it on a CDN with caching, and every site that wanted to do that could share it, and you'd only download it once. I do agree that runtime-less languages have an advantage here though.
rl3 9y ago
We're still a long ways off from garbage-collected languages inside wasm. That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.
- boomlinde 9y ago
  > We're still a long ways off from garbage-collected languages inside wasm. I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua
  - FRex 9y ago

hannofcart 9y ago

All the excitement around wasm seems quite puzzling to me. Yes, I understand that you can program in whatever language you love but what new language are you hoping would be supported? C? C++? Fortran? As far as I am concerned, all the languages I care about already have compilers that target JS.

drchickensalad 9y ago
There is a massive performance difference between compiling to js and compiling to wasm.
bluejekyll 9y ago
Rust is the big one for me, personally. The idea of being to write in one language for embedded software, system software, cli tools, web applications, distributed applications, and now the web client? That's a very enticing idea. It might finally be the realization of what Java failed to accomplish (technically it did, but never gained a lot of traction on the client b/c it was too slow at the time).
orthecreedence 9y ago
Another Rustacean checking in. I'd love to write Rust and run it in the browser. Rust uses LLVM so it can use emscripten already, but having closer to native speeds would be great.
int_19h 9y ago
JS imposes a memory/object model that doesn't map to other languages particularly well, so you either have to play fast and loose with semantics (effectively creating a dialect of the language that you're transpiling), or pay extra overhead for faithfully emulating the original behavior. WASM is much lower level, and should allow compilers and VMs to use best-fitting data structures and layout.

jlebrech 9y ago

I want to see a WASM+react framework where the application state/logic is fully in WASM and merely the rendering is done by react.

twfarland 9y ago
I would want the inverse of that, where the application logic is in some high-level language, and the rendering is done in WASM, i.e. react-dom and the diffing parts of react are in WASM.

pfalke 9y ago

„...all major browsers“ Is Internet Explorer not a major browser anymore? I’m talking relevant as in your webpage needs to work fine in Internet Explorer. For example, my company still has Internet Explorer configured as default browser as Edge is not compatible with some internal pages.

olegkikin 9y ago
IE is not a major browser anymore http://gs.statcounter.com/ http://gs.statcounter.com/ Look at your Google Analytics, it's really not that important anymore.
- sametmax 9y ago
  In corporate env it is.
  - foodstances 9y ago
    Either the computers in these mysterious corporate environments are exposed to the internet, in which case they'd be reflected in these public stats collected by them visiting public websites from IE, or they aren't, in which case they don't matter in the slightest because they're not going to visit webpages using WebAssembly.
    - dragonwriter 9y ago
      Or, as is absolutely the case, because of the aggressive blocking and monitoring policies and restrictive usage policies in place in the kind of enterprises where IE remains common, they are exposed to the public internet and use public webpages, but with usage patterns which leave them underrepresented on the kind of sites that use third-party stat counters. OTOH, for certain other public websites, they are very large numbers of users.
    - romaniv 9y ago
      IE can account for a fraction of total traffic, but it still can affect large percentage of users. The same person can use several devices (work, home, mobile) to browse the web at different times. I can't recount how many times I saw some page at work only to send myself the link to read it later. I'm not forced to use IE anywhere, but if I were, loosing that initial visit would also lower the number of visits from other browsers.

isaiahg 9y ago

I'm not as excited for this as I used to be. In most user applications JavaScript is good enough or better. If it wasn't then we wouldn't be taking the browser to make desktop applications. Recently I decided to make a desktop app and asked around about the different UI libraries. The answer I keep getting is "just use electron and JavaScript". Why? Because love it or hate it the Dom is fantastic and simple for making UIs that are interactive and reliable. And you can't beat JavaScript for manipulating the Dom. The only benefit I can think of that benefits is specialized software like games or scientific analysis/simulation. But for what most users want, JavaScript is fast enough. The example I keep hearing is "imagine gimp in the browser" but it's already possible to make a gimp like application in the browser using things like canvas and the file api. So by the time webassembly is ready for the prime and has needed features like memory management and Dom access, will it even by worth it beyond a few specific applications?

mythmon_ 9y ago
One interesting thing to me is that you don't have to write an entire app using only WebAssembly or JS. You can take the classic approach of benchmarking to find hotspots, and then optimizing those. Migrating these performance sensitive sections to more performant code can be a win.
steven777400 9y ago
I'll agree with you that modern HTML and CSS for presentation is best-of-breed. I'll accept that the DOM API is sufficient. But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.
wruza 9y ago
>you can't beat JavaScript for manipulating the Dom. Exactly. Only javascript can access attributes and call functions so good on exported document and window objects.
andrewingram 9y ago
I know that Figma is built on WebAssembly now, and has quite impressive performance.

themihai 9y ago

Without DOM it's not really that exciting.

steveklabnik 9y ago
There is a lot of processing that doesn't inherently need the DOM, and there's also server-side stuff as well. I think you'd be surprised!
- themihai 9y ago
  Yeah, but WASM was supposed to democratise the web development not to do just server-side stuff. Without DOM and Web APIs you can't do much Web related.
  - steveklabnik 9y ago
    There's tons of tooling written in JS for JS that doesn't need DOM access to work, for example.
    - themihai 9y ago
      If you talk about Node I would say that only proves my point that people go to great lengths to use their preferred language whenever possible. Tell them to use JS only for DOM stuff and wasm for things that don't need DOM. Nobody would prefers a FFI between wasm and js instead of plain wasm if given the option to choose.
  - CyberDildonics 9y ago
    > not to do just server-side stuff He didn't say anything about 'only server side stuff'. There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.
    - themihai 9y ago

blaze33 9y ago

If you're looking for an introduction to WebAssembly my "WebAssembly 101: a developer's first steps" post had some success here: https://blog.openbloc.fr/webassembly-first-steps/ https://blog.openbloc.fr/webassembly-first-steps/ HN discussion: https://news.ycombinator.com/item?id=14495893 https://news.ycombinator.com/item?id=14495893 The awesome-wasm list is also a good start: https://github.com/mbasso/awesome-wasm https://github.com/mbasso/awesome-wasm

dmix 9y ago

The math site they linked to in the examples of sites powered by WebAssembly is awesome: http://mathstud.io/ http://mathstud.io/ I almost wish I was a student again so I could relearn math for the first time with all of these great tools...

ZeroCool2u 9y ago
Wow, that is really cool actually. Impressive performance on my OG Pixel XL too.

vanderZwan 9y ago

Aside: how is WebAssembly's binary form currently shipped? In a demo I saw yesterday it was written out inline as a Uint8Array of integers between 0-255. Even with gzip enabled this can't be very efficient. For completely unrelated reasons, I was already thinking of adapting (my fork of) the LZ-string library[0] to directly compress/decompress typed arrays to "websafe" UTF16 strings, similar to the already existing `compressToUTF16` functionality in LZ-string. Essentially, the strings would represent LZ-compressed bitstreams, using 15 bits per string character. Could this be useful for reducing the size of WASM binary when encoded in plain JavaScript? (the minified library would probably be around 1kb after gzip) [0] https://github.com/JobLeonard/lz-string/tree/array-lookup https://github.com/JobLeonard/lz-string/tree/array-lookup [1] http://pieroxy.net/blog/pages/lz-string/index.html#inline_menu_6 http://pieroxy.net/blog/pages/lz-string/index.html#inline_me...

esrauch 9y ago
wasm files are already a binary format, an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.
- vanderZwan 9y ago
  Right, I thought it was odd; I remember reading that part of the big benefit of WASM was more compact, faster-to-parse source code. Going all the way up to text form and back down to binary data is at odds with that. > an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it. Are there any realistic scenarios where this is the more sensible option? Anyway, I should have searched MDN first, the relevant bit of documentation is pretty clear: fetch('simple.wasm').then(response => response.arrayBuffer() ).then(bytes => WebAssembly.instantiate(bytes, importObject) ).then(results => { results.instance.exports.exported_func(); }); https://developer.mozilla.org/en-US/docs/WebAssembly/Loading_and_running#Using_Fetch https://developer.mozilla.org/en-US/docs/WebAssembly/Loading...
  - esrauch 9y ago

rhabarba 9y ago

WebAssembly is not worth the effort unless it finally is supported by the LINK tag. Seriously, using JS to load a JS alternative is ridiculous.

themihai 9y ago
I can't agree more...but I believe the issue is that WASM sold a lie. Right now if you read between the lines it is argued that WASM is there just to help JS do more not to replace it.
- rhabarba 9y ago
  I played a bit with WASM and I like its approach, but the one thing that annoys me most with web development is the limited number of client-side languages. WASM can be great if they allow it to.
- saosebastiao 9y ago
  > WASM is there just to help JS do more not to replace it That certainly is a shame, but it's not like we have to accept that as the future. HTML is a document markup language, but we've hijacked it to build interactive UIs. It might be that WASM is just a native-ish FFI system for javascript today, but tomorrow it could be something completely different.
- moosingin3space 9y ago
  > WASM sold a lie What? The original WebAssembly announcement[1], which can be viewed as the manifesto for how WASM was envisioned, it clearly says "once browsers support the WebAssembly syntax natively, JS and wasm can diverge". Eich's goal with WebAssembly is not replacing JS, it's providing a better compilation target for other languages. WebAssembly is a replacement for asm.js, not JavaScript. No one is selling a lie here. [1]: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
krapp 9y ago
Before HTML5 deprecated it, it was assumed that browsers would just supply plugins to support various scripting languages or whatever, which is why the <script> tag had a type attribute. Unfortunately, integrating a new runtime like <script type="text/lua" src="main.lua" module="lua.wasm"/> will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a difference.) <object> might be a good candidate but I don't know if it's still supported. But, we can't get rid of JS altogether. Browsers will have to support javascript indefinitely, otherwise most of the web becomes unreadable. That being the case, using JS to load WebAssembly seems like the most reasonable backwards-compatible compromise available.

pier25 9y ago

Any news on access to DOM progress?

steveklabnik 9y ago
I commented elsewhere in the thread about the latest proposal.

capablemonkey 9y ago

Who wants to write a faster CryptoNight miner in wasm?

kyzlaitis 9y ago

Nice advertisement

r00fus 9y ago

Based on the unbridled capabilities, I can't wait for a way to block WASM. Does noscript do this yet?

steveklabnik 9y ago
What "unbridled capabilities" are you referring to?