24 ms·

Brendan Eich: WebAssembly is a game-changer

316 points by alex_hirner 11y ago

vruiz 11y ago
I want to agree with him, I'd like to see a future where WebAssembly closes the gap between native apps and the web. For better or worse browsers are the new OSes, and I dream of a future were all vendors come up with the equivalent of a POSIX standard where any web application can access all (or a wide common subset) of any device's capabilities, from the filesystem to native UI elements.
- aidanhs 11y ago
  Your comment reminded me of this highly entertaining talk - https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Although tongue in cheek, I think it gives some food for thought. I feel like WebAssembly is to asm.js what the modern JS profession is to old follow-your-cursor effect on webpages - it becomes something to take seriously and use, and having done a bunch of porting things with Emscripten the idea of a browser within a browser doesn't sound as crazy as it used to!
  - jerf 11y ago
    To be honest, WebAssembly isn't really javascript anymore. asm.js was, albeit only sorta-kinda-just-barely (but in an important way), but WebAssembly isn't. There's a reasonable case to be made that in 20 years "everything" will be WebAssembly, but we won't be calling it Javascript, thinking of it like Javascript, or using it like Javascript. In the long term, this is the death knell for Javascript-as-the-only-choice. Javascript will live on, but when left to fend for itself on its own merits, it's just another 1990s-style dynamic scripting language with little to particularly recommend it over all the other 1990s-style dynamic scripting languages. But Javascript programmers need not fear this... it will be a very long, gradual transition. You'll have abundant time to make adjustments if you need to, and should you not want to, there will still be Javascript jobs for a very long time.
    - Klathmon 11y ago
      You act like JavaScript's only upside is the fact that it's required in the browser. IME the opposite is true. I'm seeing companies flock to it outside of browser contexts in areas where "code reuse" or "isometric/universal" style programs aren't even possible.
      - jerf 11y ago
        It's not that it's the only upside. It's that once out of the browser, it isn't really a standout language. For instance, if you're going to have a "fair fight" out there, one can't help but notice that Python already has everything that we're standing around waiting for in ES6, plus the next couple of iterations. And that's just Python. You should also check into Perl, Ruby, Lua, and PHP, and that's without straying even a little outside of the "1990s dynamic scripting language" field, to say nothing of what you can find if you leave that behind. It just isn't that impressive of a language once you remove the browser prop. It isn't necessarily bad, or at least no worse than some other popular languages as well, but there's nothing uniquely good about it in the greater language landscape. To be honest, anyone who thinks that Javascript does have some sort of unique advantage needs to get out more and learn a few more languages. Even Python, which you'll find goes very quickly if you already know JS. Javascript is very, very not special. Again, since people seem to confuse these things, that does not make it bad, but it's very not special. Very boring, middle-of-the-road scripting lanugage that is, if anything, well behind the other ones in features because of its multihead, no-leader-in-practice development model.
        Klathmon 11y ago
        But JS isn't just a "worse python" either. I've gotten around when it comes to languages, from business-basic to c++ to go to python, php, ruby, js, lua, and lisp. Having spent a non-trivial amount of time in each, JS has by far one of the best ecosystems i've ever seen. See, I hate talking about languages because it's hard to define what a language even is. Is it purely the syntax? Is it syntax+standard library? Or is it the whole set of syntax+libraries+ecosystem+idioms? From a purely syntax point of view, js is lacking some things and while they are getting fixed, it's taking longer than most would like. And i agree that in this aspect js is currently "mediocre" at best. From a "whole ecosystem" point of view, js is wonderful. It's fast, secure enough to give arbitrary code from anyone in a browser, has a stupidly huge set of libraries, an "idiomatic" style which works very well for some problems, and it's almost literally everywhere and on everything, has multiple competing implementations that helps drive performance and reduce bugs. Yeah, it's got it's quirks (and in JS's case, a lot of them), but every language it's age and older does. Now if there was some way to magically take all of the "other" parts from js and apply them to another language, you'd have an overnight success, but the fact is that the language syntax is such a small part of what a language truly is.
- serge2k 11y ago
  Hey, I've got an idea. How about we just implement this POSIX like standard at the OS layer. We can call it POSIX.
  - fennecfoxen 11y ago
    Build some nice sandboxed hypermedia-application APIs into POSIX and get them adopted all over, and then sure, we can talk!
  - mindcrime 11y ago
    It's a shame you got downvoted for that, as you make a very good point. This whole trend of making the web browser a poor man's OS is definitely a bit hinky. I mean, how many layers of abstractions built on top of other (redundant) layers of abstraction really make sense? This stuff is one reason that, despite the advances associated with Moore's Law, the advent of SSD's, and increasing RAM counts, computers don't feel any faster than they did in 1995. It's ridiculous in a way. Just to play Devil's Advocate: maybe web browsers should be good at, ya know, browsing and leave the other stuff for something else.
    - vectorpush 11y ago
      > It's a shame you got downvoted for that, as you make a very good point. I think this is because the comment comes off as flippant and snarky. > This stuff is one reason that, despite the advances associated with Moore's Law, the advent of SSD's, and increasing RAM counts, computers don't feel any faster than they did in 1995. It's ridiculous in a way. That statement is ridiculous. I've never heard anyone claim that the computers of today don't "feel" any faster than computers of 20 years ago, but if you feel that way I just don't think you're living in the same universe as those of us who walk around with quad core computers in our pockets. > maybe web browsers should be good at, ya know, browsing and leave the other stuff for something else. Please define "other stuff" and where you draw the line between that and simply "browsing"
      - jblow 11y ago
        As someone who has been around since before the Web, I can confirm that computers today do not feel any faster... despite the fact that your phone is faster than the fastest computer in the world from that time. In fact I gave a speech about this at Berkeley last week. I think it'll be online pretty soon. So now you have at least heard someone claim this.
- ebbv 11y ago
  Allowing web sites to access the file system is not a great idea.
  - drvdevd 11y ago
    Not exactly disagreeing with you but for a long time now the web has been our primary path to most forms of code execution hasn't it? I mean if you count HTTP as the web in addition to browsers?
  - vruiz 11y ago
    Having the capability does not imply having the permissions.
    - jacquesm 11y ago
      What could possibly go wrong with that.
      - esailija 11y ago
        The permission to read a file's contents in a web app is given by either dragging the file from your desktop to the web app or choosing it with file picker. To save a file, a web app will have to ask the user to do a save as dialog. This permission model has pretty much always existed it was just extremely wasteful because you had to first send the file to server and then send the contents back. The new web file apis therefore don't add any new security issue but add massively better ux. To me this is much smarter model than something like "can I have full access to your fs yes/no? Btw this app doesn't work if you say no". I think you are thinking of this stupid model when you say "what could possibly go wrong with that?" but if you don't, please elaborate.
- pdkl95 11y ago
  You're asking for the ability to make perfect UI-spoofing attacks (among other types of attack). It is vitally important to maintain a wall between the browser's UI anything the remote code can touch.
chrstphrhrt 11y ago
Has anyone tried NativeScript? https://www.nativescript.org https://www.nativescript.org Heard about it on a podcast recently, haven't had a chance to try.
- supernintendo 11y ago
  Just pointing this out to absolve future confusion: This comment is very off-topic. - WebAssembly is a new low level language for client-side scripting in web browsers. Future web browsers will support WebAssembly in the same way they currently support JavaScript. WebAssembly has a number of advantages over JavaScript, including performance and an AST-like syntax that makes it more suitable as a compilation target. - NativeScript is a framework for developing "cross-platform" mobile apps. It achieves this through a JavaScript/TypeScript API and common UI components that are implemented natively on both iOS and Android. I have not tried NativeScript and I am skeptical of projects that aim to "bridge the gap" in mobile development. iOS and Android are ever-evolving and so you must rely on the platforms that target them to stay up to date. Further, these platforms have very different design goals and the compromises that frameworks like NativeScript make often come at the expense of user experience. NativeScript could be great! But please be aware of the shortcomings of eschewing native development.
- koder2016 11y ago
  Spreading the worst part of web to other platforms?
talles 11y ago
Are those boxes in the picture Firefox OS phones? Is this an old picture?
- nacs 11y ago
  Good catch. The URL of that image [1] seems to indicate it's from April 2014 (or earlier). Seems Brendon Eich resigned that same month/year [2]. [1]: http://core0.staticworld.net/images/article/2014/04/brendan-eich-100259498-primary.idge.jpg http://core0.staticworld.net/images/article/2014/04/brendan-... [2]: http://recode.net/2014/04/03/mozilla-co-founder-brendan-eich-resigns-as-ceo-and-also-from-foundation-board/ http://recode.net/2014/04/03/mozilla-co-founder-brendan-eich...
mwilkison 11y ago
Video of the talk? EDIT: Here is the full-length one - https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...
- petercooper 11y ago
  Here's his Fluent keynote from yesterday: https://www.youtube.com/watch?v=9UYoKyuFXrM https://www.youtube.com/watch?v=9UYoKyuFXrM .. full at https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent... (click X on the popup window, you don't need to sign in)
- deleted 11y ago
  [deleted]
s3th 11y ago
As we get closer to having a WebAssembly demo ready in multiple browsers, the group has added a small little website on GitHub [0] that should provide a better overview of the project than browsing the disparate repos (design, spec, etc.). Since the last time WebAssembly hit HN, we've made a lot of progress designing the binary encoding [1] for WebAssembly. (Disclaimer: I'm on the V8 team.) [0]: http://webassembly.github.io/ http://webassembly.github.io/ [1]: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md https://github.com/WebAssembly/design/blob/master/BinaryEnco...
- KMag 11y ago
  About the binary encoding... It's a bit easy to armchair these things, and it's too late for WebAsm now... but if you're on the V8 team, you have access to Google's PrefixVarint implementation (originally by Doug Rhode, IIRC from my time as a Google engineer). A 128-bit prefix varint is exactly as big as an LEB128 int in all cases, but is dramatically faster to decode and encode. It's closely related to the encoding used by UTF-8. Doug benchmarked PrefixVarints and found both Protocol Buffer encoding and Protocol Buffer decoding would be significantly faster if they had thought of using a UTF-8-like encoding. LEB128 requires a mask operation and a branch operation on every single byte, maybe skipping the final byte, so 127 mask operations and 127 branches. Using 32-bit or 64-bit native loads gets tricky, and I suspect all of the bit twiddling necessary makes it slower than the naive byte-at-a-time mask-and-branch. 7 bits -> 0xxxxxxx 14 bits -> 1xxxxxxx 0xxxxxxx ... 35 bits -> 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx ... 128 bits -> 1xxxxxxx 1xxxxxxx 1xxxxxxx ... xxxxxxxx Prefix varints just shift that unary encoding to the front, so you have at most 2 single-byte switch statements, for less branch misprediction, and for larger sizes it's trivial make use of the processor's native 32-bit and 64-bit load instructions (assuming a processor that supports unaligned loads). 7 bits -> 0xxxxxxx 14 bits -> 10xxxxxx xxxxxxxx ... 35 bits -> 11110xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx ... 128 bits -> 11111111 11111111 xxxxxxxx xxxxxxxx ... xxxxxxxx There's literally no advantage to LEB128, other than more people have heard about it. A PrefixVarInt 128 is literally always the same number of bytes, it just puts the length-encoding bits all together so you can more easily branch on them, and doesn't make them get in the way of native loads for your data bits. Also, zigzag encoding and decoding is faster than sign extension, for variable-length integers. Protocol Buffers got that part right. Note that for security reasons, if there are no non-canonical representations, there can't be security bugs due to developers forgetting to check non-canonical representations. For this reason, you may want to use a bijective base 256[0] encoding, so that there aren't multiple encodings for a single integer. In the UTF-8 world, there have been several security issues due to UTF-8 decoders not properly checking for non-canonical encodings and programmers doing slightly silly checks against constant byte arrays. A bijective base 256 saves you less than half a percent in space usage, but the cost is only one subtraction at encoding time and one addition at decoding time. [0]https://en.wikipedia.org/wiki/Bijective_numeration https://en.wikipedia.org/wiki/Bijective_numeration
petercooper 11y ago
If you want to see Brendan's keynote from O'Reilly Fluent yesterday, a sample went up https://www.youtube.com/watch?v=9UYoKyuFXrM https://www.youtube.com/watch?v=9UYoKyuFXrM with the full one at https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...
- smartbit 11y ago
  And Alex Russel's keynote (Google) "Progressive web apps and what's next for mobile" can be found at https://www.oreilly.com/ideas/progressive-web-apps-and-whats-next-for-mobile https://www.oreilly.com/ideas/progressive-web-apps-and-whats...
vbezhenar 11y ago
What exactly will be better? One can compile a lot of languages to JavaScript today. JavaScript is fast enough and size doesn't really matter for most use cases. Is WebAssembly going to be much faster than JavaScript?
- bobajeff 11y ago
  Compared to asm.js today it'll start-up faster because the format parses quicker. It will also be smaller in size compared to a gzipped asm.js equivalent. Edit: Also, browser vendors will optimize it more consistently than they do with asm.js currently. Also, compared to Emscripten the llvm backend for WebAssembly is upstream so you might see more frontend languages like Swift and Rust add support for it.
- Mikeb85 11y ago
  Webassembly is basically a portably assembly language (as in, lower level than C), that then gets translated instruction for instruction into actual assembly language. It's several layers 'below' JavaScript. It's basically cross-platform, native code.
  - acqq 11y ago
    And moreover, the resulting native code is executed inside the same VM that executes normal Javascript, so it's not anything like starting some Flash file, it's just that we can have native code speed, when needed, inside of the Javascript. That existed already with asm.js. This step now should allow less overhead in parsing such code, which matters when there is a lot of code like in the games or big programs directly translated from lower-language code base. Less overhead means less battery drain and faster start of the program, as an example.
- r1ch 11y ago
  "Fast enough" still isn't fast enough for mobile devices. I have a high end phone and still get multi second freezes from all the JS parsing and executing on modern websites.
- tromp 11y ago
rl3 11y ago
Considering how critical SharedArrayBuffer is for achieving parallelism in WebAssembly, I'm hoping we see major browsers clean up their Worker API implementations, or even just comply with spec in the first place. Right now things are a mess in Web Worker land, and have been for quite some time.
- jvilk 11y ago
  Absolutely agreed. We should be able to debug Web Workers with development tools (e.g. set breakpoints / examine state / etc), nest Web Workers, use console.log from within a Worker, and construct Web Workers from Blob URLs. It's infuriatingly difficult to work with Web Workers without these features, which are missing from most browsers! I think there's a chicken-and-egg problem with regards to Web Workers: Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. Someone needs to break the cycle.
  - rl3 11y ago
    There's also a host of nasty bugs and implementation deficiencies, depending on the browser. My favorite is in Chrome with simple DedicatedWorker instances communicating with each other directly via the MessageChannel API. It works, except when the UI thread is blocked, because messages are routed through the UI thread. Firefox doesn't have this problem, but it has its own issues—namely the UI thread for each tab runs in the same OS process, unlike Chrome where tabs are isolated processes. That said, Firefox and Chrome are far ahead of every other browser in terms of how they implement workers. Other implementations are borderline destitute by comparison (e.g. no DOMHighResTimeStamp available in worker context, no Transferable support for important items). >Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. You hit the nail on the head. I think it's also a dislike for the API as a whole, because really workers are just a convoluted way of enforcing thread safety. Personally I'd prefer a far more simple and traditional shared memory model, with developers being afforded enough rope to hang themselves with if they so desired. The existing methods of transferring data to and from workers are frankly crap, the only light at the end of the tunnel being SharedArrayBuffer and the Atomics API designed around it. The problem is that both are essentially designed for compiled applications, ala asm.js and WebAssembly. In a compiled [browser] environment, the heap is seamlessly allocated on a SharedArrayBuffer, so writing parallel code is nearly identical to the traditional desktop experience from a developer's point of view. In plain old Javascript however, you have to serialize and deserialize native types to and from the buffer, which is expensive. It really makes Javascript seem like a second-class citizen with regards to parallelism.
twsted 11y ago
I don't know. I am not sure yet. What the HN folks think about this?
- deleted 11y ago
  [deleted]
gsmethells 11y ago
To me, it's more about choice of programming language than performance. Though the latter is very important, I think the former is what will open up doors to making the browser a platform of choice (pun intended). Currently, it feels like JavaScript is the Comcast of the web. Everyone uses it, but that's only because there aren't any other options available to them.
- gbersac 11y ago
  Definitely agree ! I really hope that web asm will kill javascript and (css by the way). I just hate this language.
jacquesm 11y ago
Personally, I think this is terrible (and it really is a game-changer, only not the kind that I'd be happy about). The further we get away from the web as a content delivery vehicle and more and more a delivery for executables that only run as long as you are on a page the more we will lose those things that made the web absolutely unique. For once the content was the important part, the reader was in control, for once universal accessibility was on the horizon and the peer-to-peer nature of the internet had half a chance of making the web a permanent read/write medium. It looks very much as if we're going to lose all of that to vertical data silos that will ship you half-an-app that you can't use without the associated service. We'll never really know what we lost. It's sad that we don't seem to be able to have the one without losing the other, theoretically it should be possible to do that but for some reason the trend is definitely in the direction of a permanent eradication of the 'simple' web where pages rather than programs were the norm. Feel free to call me a digital Luddite, I just don't think this is what we had in mind when we heralded the birth of the www.
- danharaj 11y ago
  I think the solution is to think of code as data that should be freely distributed and hackable as well. It isn't the garden that is the issue, but its walls.
  - jacquesm 11y ago
    We're heading straight for native code sandboxed in the browser via a bit of a detour. It will be just as hackable as any closed source code that you get from some vendor. Think of it as a slightly more modern version of Java, this time it really is run 'anywhere' as long as 'anywhere' is a browser and the source code stays with the supplier of the web-app.
    - simoncion 11y ago
      Yep. The web-heads are slowly reimplementing Unix in the browser. [0] We could have avoided this with better, wider-spread support for sandboxing of untrusted executables. Alas. [0] They don't have crashdumps yet, but I expect that they soon will.
kibwen 11y ago
On the Rust side, we're working on integrating Emscripten support into the compiler so that we're ready for WebAssembly right out of the gate. Given that the initial release of WebAssembly won't support managed languages, Rust is one of the few languages that is capable of competing with C/C++ in this specific space for the near future. And of course it helps that WebAssembly, Emscripten, and Rust all have strong cross-pollination through Mozilla. :) If anyone would like to get involved with helping us prepare, please see https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-... EDIT: See also asajeffrey's wasm repo for Rust-native WebAssembly support that will hopefully land in Servo someday: https://github.com/asajeffrey/wasm https://github.com/asajeffrey/wasm
no1youknowz 11y ago
I think the web may split into two. 1) 'Simple' web pages will stick with jquery, react, angular, etc type code. Where you can still click view source and see whats going on. Where libs are pulled from CDNs etc. 2) 'Complex' saas web apps, where you need native functionality. This will be a huge bonus. I'm in this space. I would love to see my own application as a native app. The UI wins alone make it worth it!
- ash_gti 11y ago
  What does 'native functionality' mean for a web app? Do you mean skipping the DOM and making a Canvas for displaying content? Or do you mean something else?
  - deleted 11y ago
    [deleted]
stevenh 11y ago
If anyone at infoworld.com reads these comments: On the top of the page, there is a horizontal menu containing "App Dev • Cloud • Data Center • Mobile ..." When I position my cursor above this menu and then use the scroll wheel to begin scrolling down the page, once this menu becomes aligned with my cursor, the page immediately stops scrolling and the scroll wheel functionality is hijacked and used to scroll this menu horizontally instead. It took a few seconds to realize what was happening. At first I thought the browser was lagging - why else would scrolling ever abruptly stop like that? I closed the page without reading a single word.
ape4 11y ago
The format of WebAssembly could be Java ByteCode.
- rubber_duck 11y ago
  It's lower level than that.
n00b101 11y ago
What is the upgrade path for Emscripten users? I understand that LLVM will have WebAssembly backend, but how will OpenGL to WebGL translation work, for example?
- azakai 11y ago
  Emscripten can already compile to both asm.js and WebAssembly, with just flipping a switch between them. All the JS library support code is unchanged, so Emscripten's OpenGL to WebGL layer is used just like before, and the same for all the other libraries. The WebAssembly backend in LLVM will eventually be used by Emscripten as another way to emit WebAssembly (right now it translates asm.js to WebAssembly), but the new backend is not ready yet. See also https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly
jimmcslim 11y ago
I wish the browser vendors focused on CSS Grid module support as much as they did WebAssembly.
machuidel 11y ago
Since I started hearing about WebAssembly I cannot stop thinking about the possibilities. For example: NPM compiling C-dependencies together with ECMAScript/JavaScript into a single WebAssembly package that can then run inside the browser. For people thinking this will close the web even more because the source will not be "human"readable. Remember that JavaScript gets minified and compiled into (using Emscripten) as well. The benefits I see compared to what we have now: - Better sharing of code between different applications (desktop, mobile apps, server, web etc.) - People can finally choose their own favorite language for web-development. - Closer to the way it will be executed which will improve performance. - Code compiled from different languages can work / link together. Then for the UI part there are those common languages / vocabularies we can use to communicate with us humans: HTML, SVG, CSS etc. I only hope this will improve the "running same code on client or server to render user-interface" situation as well.
- spb 11y ago
  More importantly, if we want to make "view source" more palatable in a WebAssembly age, we need to have it support source maps from day 1.
  - machuidel 11y ago
    Yes, that would be good for development / debugging (like debug symbols) or as an optional way to give people access to the source.
- rubber_duck 11y ago
  >For example: NPM compiling C-dependencies together with ECMAScript/JavaScript into a single WebAssembly package that can then run inside the browser. The reason you'd write stuff in C is (aside from performance) to access native API. Browsers and WASM doesn't let you do that. WASM in the Node could let you do that - meaning that you would get cross platform assembly packages instead of ELF or w/e binary - but you would still need APIs on the platform and often for C the way that's handled is preprocesor macros that choses which platform you are compiling to - so you can't just "compile to WASM and then magic" even with WASM you'd have to "compile to WASM + POSIX and WASM + Win32" if you want to run on POSIX/Win32, etc. for all platform/API permutations. TL;DR WASM is big but it won't quite be the abstract virtual machine like say JVM or CLR
opacityIsCool 11y ago
Yeah, great. Transform everything into opaque binary blobs, as far as the eye can see. Wonderful. Thanks for nothing.
- T-A 11y ago
  From http://webassembly.github.io/ http://webassembly.github.io/ : "Open and debuggable: WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. The textual format will be used when viewing the source of wasm modules on the web."
  - opacityIsCool 11y ago
    Yeah, nice, this and and so many other formats, that people just throw up their hands and give up on, when confronted with the raw binaries they work with on a daily basis, are simply open and wonderful all the time. Except not. Portable Executables. ELF binaries. Zip Files. Open Image Formats. All of these are theoretically open, and perfectly accessible to all, in their raw form. And yet broadly inaccessible to like 90% of the world's lay people, since the concept of an interpreter eludes them, and in some cases is explicitly denied to them. The same will happen with this. This puts things on a shelf, well out of reach to many more people. And a very small group of people love that. So, while encrypted smart phones and email "go dark" on mass surveillance, the rest of everything else "goes dark" for ordinary people.
icedchai 11y ago
WebAssembly... Wow, if we keep going, we'll re-invent what Sun achieved 20 years ago with Java. If only they hadn't f-ed it up...
- protomyth 11y ago
  The JVM problem was that it had applets and did not have the DOM integration of Javascript. I do often wonder if instead of Javascript in 1995 we had got WebAssembly and WebSockets.
  - icedchai 11y ago
    You could actually call into JavaScript from Applets, using something called LiveConnect. See https://docs.oracle.com/javase/tutorial/deployment/applet/invokingJavaScriptFromApplet.html https://docs.oracle.com/javase/tutorial/deployment/applet/in... Was it simply/easy? No. But, you probably wouldn't want to.. The DOM is a crappy way to build an application UI. Someday we might figure that out.
    - esailija 11y ago
      If you consider custom elements, how is it different from any other way of building ui?
    - cheez 11y ago
      The concept of the DOM is so widely considered to be useful in declaring user interfaces, that multiple languages have copied it. http://fxexperience.com/wp-content/uploads/2011/08/Introducing-FXML.pdf http://fxexperience.com/wp-content/uploads/2011/08/Introduci... https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://en.wikipedia.org/wiki/Extensible_Application_Markup_... The HTML DOM sucks, but what other DOM is widely available and already installed on literally every machine on the planet?
  - Touche 11y ago
    Probably the 2 minute startup time was a bigger problem for applets.
bitL 11y ago
Brendan, looking at your photo, please take your time off, get into a shape and have more fun! Thanks for all your work so far but don't overdo it please!
icosta 11y ago
WebAssembly = SWF with diff name. Come on!
- deleted 11y ago
  [deleted]
bcoates 11y ago
If you think WebAssembly (or asm.js) is a good idea, I would very much like you to do the thought experiment of what design decisions something like WebAssembly would have made 15 or 25 years ago, and what consequences those would have today. Helpful research keywords: Itanium RISC Alpha WAP Power EPIC Java ARM Pentium4 X.25
- smitherfield 11y ago
  I can't think of any software development API that ended up being perfect 15 or 25 years later. Javascript certainly isn't. Java applets, ActiveX controls and Flash very much weren't, but, at the time, they did things you couldn't with the standard web stack. And we're better off for learning the lessons of the failures, creating improved technologies to replace them (HTML5, JIT Javascript engines, etc), and building on the successes to continuously do more things that previously couldn't be done in the browser. Will WebAssembly be perfect? Of course not. Will there be unanticipated problems? Of course. I would not at all be surprised if it becomes the next Flash. But it's better to move forward and keep innovating with new web technologies instead of letting the platform stagnate. We've tried feature-freezing the web for a few years; it was called "Internet Explorer 6" and it sucked.
Pxtl 11y ago
If we keep this up, the web will be almost as good of an application framework as a '90s era desktop application. Yay, progress!
deleted 11y ago
[deleted]
xaduha 11y ago
WebAssembly shouldn't be for the end users to use, it should used for implementations of other languages so they can access the same APIs Javascript can. Add Lua to the browser, add Perl 6 to the browser, etc. There are plenty of decade old W3C specifications that never made it to the browser properly, like XSLT 2.0, XQuery 1.0, XForms, never mind the latest versions of the specs.
- esailija 11y ago
  I don't see how it can be feasible to use it for implementations of other languages that don't directly map to webassembly like C. You would have to ship a runtime for the other language along with your application code. The runtime will be either huge with long startup time or small but too slow to be feasible.
  - xaduha 11y ago
    Whichever it is it can't be worse than implementing other languages in Javascript directly or using stuff like GWT and there are plenty of those already (including development for running Perl 6, btw). Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached.
    - esailija 11y ago
      > Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached. Web Assembly isn't related to this. You can standardize on a new language VM that browsers should ship, like was attempted with Dart. What Web Assembly enables is more efficient VM with better interop to Web APIs than currently is possible, but the most prohibitive thing will not change (having to ship multi megabyte VM along with your application code).
      - xaduha 11y ago
        Lots of things will change. If it makes sense to do that, then there will be demand for it. Here's something already https://news.ycombinator.com/item?id=11269736 https://news.ycombinator.com/item?id=11269736
spitfire 11y ago
I wonder if along with these byte code engines we'll get capability grained control systems too. Somehow I doubt it though. So in the future, when you visit a website they'll be able to Eg: open windows, pop up unblockable modals, webGL, bytecode loaded spam/ads, etc. The end users option will be to block everything, or live with it. I do not like this bold new world we're entering.
- esailija 11y ago
  This is a common confusion somehow. The programming language has nothing to do with the APIs provided by an environment. JavaScript can do all those things now, as long as you run it in an environment that provides APIs to do those things (node.js, electron etc). The browser is not that environment. When you write a keylogger virus in C, you are relying on the APIs provided by the environment to do it, they don't come from the C language.
  - spitfire 11y ago
    I wasn't confused at all. Technically there is a difference between a language, an API and a platform. That's all true in the case of NodeJS and the like, but not true for web browsers. There the language the API and the platform come as one. The result is, remote websites can execute code on a users computer. With no control except for simple technical measures.
eggy 11y ago
I still think there is a lot of room for static pages with links in the style that people seem to be prematurely waxing melancholy about when forecasting where WebAssembly _may_ lead the internet. I was always able to find sites of interest that didn't include Flash, Java applets, and company when I just wanted to read something. I find some of the scroll-hijacking, and other javascript goodies on modern pages to either be a distraction, or non-functional on some different devices. On the other hand, I am particularly happy about, and working with Pollen in Racket, a creation by Matthew Butterick. Pollen is a language created with Racket for making digital books, books as code, and bringing some long-needed, real-world publishing aesthetics back to the web [1,2]. I may even by a font of his to get going and support him at the same time! [1] http://docs.racket-lang.org/pollen/ [2] http://practical.typography.com
travisty 11y ago
Thanks for that update that no one asked for.
- whyever 11y ago
  Do you think someone asked for this comment?
- oconnor663 11y ago
  I'm excited to hear the Rust news, but I don't want to make a "+1" comment or whatever, since that clutters the thread. There might be other people who feel the same.
- dang 11y ago
  Please don't be rude. We detached this subthread from https://news.ycombinator.com/item?id=11262923 https://news.ycombinator.com/item?id=11262923 and marked it off-topic.
ak39 11y ago
Is WebAssembly going to be host url resource based (like current .js files are) or will it be used as part of some centralized global assembly cache (GAC) solution where assemblies are only usable from a CDN type of authority?
nadam 11y ago
A question to WebAssembly experts: How easy it is to use WebAssembly as a sandboxed embedded scripting mechanism in my own native (C++) application? I am writing a native real-time system (a distributed 3D engine for VR) in which I send scripts on the wire between machines, and I need to call an update() method of these sent scripts like 90 times a frame. I need complete sandboxing, because my trust model is that what is trusted on machine A may be absolutely not trusted on machine B: not only not letting the scripts do any functions other than what I explicitly let them call, but I need to have hard limit on their memory usage and execution time also, but preferably they should execute in-process, so they can reach memory I let them and be called from the thread I want. Currently I go wtih Lua, but to have really good performance I will need to research this topic more deeply later.
hutzlibu 11y ago
Sorry, but most of the discussion here is completly missing the point about WebAssembler. It is just a technology, to make things brought through the web, faster. And it is open. And no less secure, than js. So I think it's great. Good technology does exactly, what the creator wants. And if people don't like some of the things, that gets created with it, then it is not a problem of the technology itself. So people can do good things, or bad things with it. But in the web, we have the freedom to choose, where we go. And if we don't like ads for example, we should be aware, that Web-Site creators still want money for their work, so maybe we should focus and support a different funding model. I like the pay-what-you-want or donation model the most, Wikipedia shows, that this is possible on a large scale ...
deleted 11y ago
[deleted]
madsravn 11y ago
This looks AWESOME
Executor 11y ago
I'm conflicted. One one hand I support open data/raw documents. But this prevents native-like, real-time applications. It also forces developers to work on Javascript which is a terrible language. On the other hand we have lock-in ecosystems, closed silos, that are detrimental to the commons. The only consolation I have is that if WebAssembly provides a bytecode instead of machine code then we still have the ability to perform reverse engineering. In the end, we have ALL have to do the hard task to inform every single person why Apple/FB/MS/Google are harmful to us and why we should boycott their programs/services.

316 points by alex_hirner 11y ago

vruiz 11y ago

I want to agree with him, I'd like to see a future where WebAssembly closes the gap between native apps and the web. For better or worse browsers are the new OSes, and I dream of a future were all vendors come up with the equivalent of a POSIX standard where any web application can access all (or a wide common subset) of any device's capabilities, from the filesystem to native UI elements.

aidanhs 11y ago
Your comment reminded me of this highly entertaining talk - https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Although tongue in cheek, I think it gives some food for thought. I feel like WebAssembly is to asm.js what the modern JS profession is to old follow-your-cursor effect on webpages - it becomes something to take seriously and use, and having done a bunch of porting things with Emscripten the idea of a browser within a browser doesn't sound as crazy as it used to!
- jerf 11y ago
  To be honest, WebAssembly isn't really javascript anymore. asm.js was, albeit only sorta-kinda-just-barely (but in an important way), but WebAssembly isn't. There's a reasonable case to be made that in 20 years "everything" will be WebAssembly, but we won't be calling it Javascript, thinking of it like Javascript, or using it like Javascript. In the long term, this is the death knell for Javascript-as-the-only-choice. Javascript will live on, but when left to fend for itself on its own merits, it's just another 1990s-style dynamic scripting language with little to particularly recommend it over all the other 1990s-style dynamic scripting languages. But Javascript programmers need not fear this... it will be a very long, gradual transition. You'll have abundant time to make adjustments if you need to, and should you not want to, there will still be Javascript jobs for a very long time.
  - Klathmon 11y ago
    You act like JavaScript's only upside is the fact that it's required in the browser. IME the opposite is true. I'm seeing companies flock to it outside of browser contexts in areas where "code reuse" or "isometric/universal" style programs aren't even possible.
    - jerf 11y ago
      It's not that it's the only upside. It's that once out of the browser, it isn't really a standout language. For instance, if you're going to have a "fair fight" out there, one can't help but notice that Python already has everything that we're standing around waiting for in ES6, plus the next couple of iterations. And that's just Python. You should also check into Perl, Ruby, Lua, and PHP, and that's without straying even a little outside of the "1990s dynamic scripting language" field, to say nothing of what you can find if you leave that behind. It just isn't that impressive of a language once you remove the browser prop. It isn't necessarily bad, or at least no worse than some other popular languages as well, but there's nothing uniquely good about it in the greater language landscape. To be honest, anyone who thinks that Javascript does have some sort of unique advantage needs to get out more and learn a few more languages. Even Python, which you'll find goes very quickly if you already know JS. Javascript is very, very not special. Again, since people seem to confuse these things, that does not make it bad, but it's very not special. Very boring, middle-of-the-road scripting lanugage that is, if anything, well behind the other ones in features because of its multihead, no-leader-in-practice development model.
      - Klathmon 11y ago
        But JS isn't just a "worse python" either. I've gotten around when it comes to languages, from business-basic to c++ to go to python, php, ruby, js, lua, and lisp. Having spent a non-trivial amount of time in each, JS has by far one of the best ecosystems i've ever seen. See, I hate talking about languages because it's hard to define what a language even is. Is it purely the syntax? Is it syntax+standard library? Or is it the whole set of syntax+libraries+ecosystem+idioms? From a purely syntax point of view, js is lacking some things and while they are getting fixed, it's taking longer than most would like. And i agree that in this aspect js is currently "mediocre" at best. From a "whole ecosystem" point of view, js is wonderful. It's fast, secure enough to give arbitrary code from anyone in a browser, has a stupidly huge set of libraries, an "idiomatic" style which works very well for some problems, and it's almost literally everywhere and on everything, has multiple competing implementations that helps drive performance and reduce bugs. Yeah, it's got it's quirks (and in JS's case, a lot of them), but every language it's age and older does. Now if there was some way to magically take all of the "other" parts from js and apply them to another language, you'd have an overnight success, but the fact is that the language syntax is such a small part of what a language truly is.
serge2k 11y ago
Hey, I've got an idea. How about we just implement this POSIX like standard at the OS layer. We can call it POSIX.
- fennecfoxen 11y ago
  Build some nice sandboxed hypermedia-application APIs into POSIX and get them adopted all over, and then sure, we can talk!
- mindcrime 11y ago
  It's a shame you got downvoted for that, as you make a very good point. This whole trend of making the web browser a poor man's OS is definitely a bit hinky. I mean, how many layers of abstractions built on top of other (redundant) layers of abstraction really make sense? This stuff is one reason that, despite the advances associated with Moore's Law, the advent of SSD's, and increasing RAM counts, computers don't feel any faster than they did in 1995. It's ridiculous in a way. Just to play Devil's Advocate: maybe web browsers should be good at, ya know, browsing and leave the other stuff for something else.
  - vectorpush 11y ago
    > It's a shame you got downvoted for that, as you make a very good point. I think this is because the comment comes off as flippant and snarky. > This stuff is one reason that, despite the advances associated with Moore's Law, the advent of SSD's, and increasing RAM counts, computers don't feel any faster than they did in 1995. It's ridiculous in a way. That statement is ridiculous. I've never heard anyone claim that the computers of today don't "feel" any faster than computers of 20 years ago, but if you feel that way I just don't think you're living in the same universe as those of us who walk around with quad core computers in our pockets. > maybe web browsers should be good at, ya know, browsing and leave the other stuff for something else. Please define "other stuff" and where you draw the line between that and simply "browsing"
    - jblow 11y ago
      As someone who has been around since before the Web, I can confirm that computers today do not feel any faster... despite the fact that your phone is faster than the fastest computer in the world from that time. In fact I gave a speech about this at Berkeley last week. I think it'll be online pretty soon. So now you have at least heard someone claim this.
ebbv 11y ago
Allowing web sites to access the file system is not a great idea.
- drvdevd 11y ago
  Not exactly disagreeing with you but for a long time now the web has been our primary path to most forms of code execution hasn't it? I mean if you count HTTP as the web in addition to browsers?
- vruiz 11y ago
  Having the capability does not imply having the permissions.
  - jacquesm 11y ago
    What could possibly go wrong with that.
    - esailija 11y ago
      The permission to read a file's contents in a web app is given by either dragging the file from your desktop to the web app or choosing it with file picker. To save a file, a web app will have to ask the user to do a save as dialog. This permission model has pretty much always existed it was just extremely wasteful because you had to first send the file to server and then send the contents back. The new web file apis therefore don't add any new security issue but add massively better ux. To me this is much smarter model than something like "can I have full access to your fs yes/no? Btw this app doesn't work if you say no". I think you are thinking of this stupid model when you say "what could possibly go wrong with that?" but if you don't, please elaborate.
pdkl95 11y ago
You're asking for the ability to make perfect UI-spoofing attacks (among other types of attack). It is vitally important to maintain a wall between the browser's UI anything the remote code can touch.

chrstphrhrt 11y ago

Has anyone tried NativeScript? https://www.nativescript.org https://www.nativescript.org Heard about it on a podcast recently, haven't had a chance to try.

supernintendo 11y ago
Just pointing this out to absolve future confusion: This comment is very off-topic. - WebAssembly is a new low level language for client-side scripting in web browsers. Future web browsers will support WebAssembly in the same way they currently support JavaScript. WebAssembly has a number of advantages over JavaScript, including performance and an AST-like syntax that makes it more suitable as a compilation target. - NativeScript is a framework for developing "cross-platform" mobile apps. It achieves this through a JavaScript/TypeScript API and common UI components that are implemented natively on both iOS and Android. I have not tried NativeScript and I am skeptical of projects that aim to "bridge the gap" in mobile development. iOS and Android are ever-evolving and so you must rely on the platforms that target them to stay up to date. Further, these platforms have very different design goals and the compromises that frameworks like NativeScript make often come at the expense of user experience. NativeScript could be great! But please be aware of the shortcomings of eschewing native development.
koder2016 11y ago
Spreading the worst part of web to other platforms?

talles 11y ago

Are those boxes in the picture Firefox OS phones? Is this an old picture?

nacs 11y ago
Good catch. The URL of that image [1] seems to indicate it's from April 2014 (or earlier). Seems Brendon Eich resigned that same month/year [2]. [1]: http://core0.staticworld.net/images/article/2014/04/brendan-eich-100259498-primary.idge.jpg http://core0.staticworld.net/images/article/2014/04/brendan-... [2]: http://recode.net/2014/04/03/mozilla-co-founder-brendan-eich-resigns-as-ceo-and-also-from-foundation-board/ http://recode.net/2014/04/03/mozilla-co-founder-brendan-eich...

mwilkison 11y ago

Video of the talk? EDIT: Here is the full-length one - https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...

petercooper 11y ago
Here's his Fluent keynote from yesterday: https://www.youtube.com/watch?v=9UYoKyuFXrM https://www.youtube.com/watch?v=9UYoKyuFXrM .. full at https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent... (click X on the popup window, you don't need to sign in)
deleted 11y ago
[deleted]

s3th 11y ago

As we get closer to having a WebAssembly demo ready in multiple browsers, the group has added a small little website on GitHub [0] that should provide a better overview of the project than browsing the disparate repos (design, spec, etc.). Since the last time WebAssembly hit HN, we've made a lot of progress designing the binary encoding [1] for WebAssembly. (Disclaimer: I'm on the V8 team.) [0]: http://webassembly.github.io/ http://webassembly.github.io/ [1]: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md https://github.com/WebAssembly/design/blob/master/BinaryEnco...

KMag 11y ago
About the binary encoding... It's a bit easy to armchair these things, and it's too late for WebAsm now... but if you're on the V8 team, you have access to Google's PrefixVarint implementation (originally by Doug Rhode, IIRC from my time as a Google engineer). A 128-bit prefix varint is exactly as big as an LEB128 int in all cases, but is dramatically faster to decode and encode. It's closely related to the encoding used by UTF-8. Doug benchmarked PrefixVarints and found both Protocol Buffer encoding and Protocol Buffer decoding would be significantly faster if they had thought of using a UTF-8-like encoding. LEB128 requires a mask operation and a branch operation on every single byte, maybe skipping the final byte, so 127 mask operations and 127 branches. Using 32-bit or 64-bit native loads gets tricky, and I suspect all of the bit twiddling necessary makes it slower than the naive byte-at-a-time mask-and-branch. 7 bits -> 0xxxxxxx 14 bits -> 1xxxxxxx 0xxxxxxx ... 35 bits -> 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx ... 128 bits -> 1xxxxxxx 1xxxxxxx 1xxxxxxx ... xxxxxxxx Prefix varints just shift that unary encoding to the front, so you have at most 2 single-byte switch statements, for less branch misprediction, and for larger sizes it's trivial make use of the processor's native 32-bit and 64-bit load instructions (assuming a processor that supports unaligned loads). 7 bits -> 0xxxxxxx 14 bits -> 10xxxxxx xxxxxxxx ... 35 bits -> 11110xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx ... 128 bits -> 11111111 11111111 xxxxxxxx xxxxxxxx ... xxxxxxxx There's literally no advantage to LEB128, other than more people have heard about it. A PrefixVarInt 128 is literally always the same number of bytes, it just puts the length-encoding bits all together so you can more easily branch on them, and doesn't make them get in the way of native loads for your data bits. Also, zigzag encoding and decoding is faster than sign extension, for variable-length integers. Protocol Buffers got that part right. Note that for security reasons, if there are no non-canonical representations, there can't be security bugs due to developers forgetting to check non-canonical representations. For this reason, you may want to use a bijective base 256[0] encoding, so that there aren't multiple encodings for a single integer. In the UTF-8 world, there have been several security issues due to UTF-8 decoders not properly checking for non-canonical encodings and programmers doing slightly silly checks against constant byte arrays. A bijective base 256 saves you less than half a percent in space usage, but the cost is only one subtraction at encoding time and one addition at decoding time. [0]https://en.wikipedia.org/wiki/Bijective_numeration https://en.wikipedia.org/wiki/Bijective_numeration

petercooper 11y ago

If you want to see Brendan's keynote from O'Reilly Fluent yesterday, a sample went up https://www.youtube.com/watch?v=9UYoKyuFXrM https://www.youtube.com/watch?v=9UYoKyuFXrM with the full one at https://www.oreilly.com/ideas/brendan-eich-javascript-fluent-2016 https://www.oreilly.com/ideas/brendan-eich-javascript-fluent...

smartbit 11y ago
And Alex Russel's keynote (Google) "Progressive web apps and what's next for mobile" can be found at https://www.oreilly.com/ideas/progressive-web-apps-and-whats-next-for-mobile https://www.oreilly.com/ideas/progressive-web-apps-and-whats...

vbezhenar 11y ago

What exactly will be better? One can compile a lot of languages to JavaScript today. JavaScript is fast enough and size doesn't really matter for most use cases. Is WebAssembly going to be much faster than JavaScript?

bobajeff 11y ago
Compared to asm.js today it'll start-up faster because the format parses quicker. It will also be smaller in size compared to a gzipped asm.js equivalent. Edit: Also, browser vendors will optimize it more consistently than they do with asm.js currently. Also, compared to Emscripten the llvm backend for WebAssembly is upstream so you might see more frontend languages like Swift and Rust add support for it.
Mikeb85 11y ago
Webassembly is basically a portably assembly language (as in, lower level than C), that then gets translated instruction for instruction into actual assembly language. It's several layers 'below' JavaScript. It's basically cross-platform, native code.
- acqq 11y ago
  And moreover, the resulting native code is executed inside the same VM that executes normal Javascript, so it's not anything like starting some Flash file, it's just that we can have native code speed, when needed, inside of the Javascript. That existed already with asm.js. This step now should allow less overhead in parsing such code, which matters when there is a lot of code like in the games or big programs directly translated from lower-language code base. Less overhead means less battery drain and faster start of the program, as an example.
r1ch 11y ago
"Fast enough" still isn't fast enough for mobile devices. I have a high end phone and still get multi second freezes from all the JS parsing and executing on modern websites.
tromp 11y ago

rl3 11y ago

Considering how critical SharedArrayBuffer is for achieving parallelism in WebAssembly, I'm hoping we see major browsers clean up their Worker API implementations, or even just comply with spec in the first place. Right now things are a mess in Web Worker land, and have been for quite some time.

jvilk 11y ago
Absolutely agreed. We should be able to debug Web Workers with development tools (e.g. set breakpoints / examine state / etc), nest Web Workers, use console.log from within a Worker, and construct Web Workers from Blob URLs. It's infuriatingly difficult to work with Web Workers without these features, which are missing from most browsers! I think there's a chicken-and-egg problem with regards to Web Workers: Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. Someone needs to break the cycle.
- rl3 11y ago
  There's also a host of nasty bugs and implementation deficiencies, depending on the browser. My favorite is in Chrome with simple DedicatedWorker instances communicating with each other directly via the MessageChannel API. It works, except when the UI thread is blocked, because messages are routed through the UI thread. Firefox doesn't have this problem, but it has its own issues—namely the UI thread for each tab runs in the same OS process, unlike Chrome where tabs are isolated processes. That said, Firefox and Chrome are far ahead of every other browser in terms of how they implement workers. Other implementations are borderline destitute by comparison (e.g. no DOMHighResTimeStamp available in worker context, no Transferable support for important items). >Developers do not use Web Workers because they are hard to use/debug/develop with, and browser vendors do not improve their Web Worker implementations because they have limited adoption. You hit the nail on the head. I think it's also a dislike for the API as a whole, because really workers are just a convoluted way of enforcing thread safety. Personally I'd prefer a far more simple and traditional shared memory model, with developers being afforded enough rope to hang themselves with if they so desired. The existing methods of transferring data to and from workers are frankly crap, the only light at the end of the tunnel being SharedArrayBuffer and the Atomics API designed around it. The problem is that both are essentially designed for compiled applications, ala asm.js and WebAssembly. In a compiled [browser] environment, the heap is seamlessly allocated on a SharedArrayBuffer, so writing parallel code is nearly identical to the traditional desktop experience from a developer's point of view. In plain old Javascript however, you have to serialize and deserialize native types to and from the buffer, which is expensive. It really makes Javascript seem like a second-class citizen with regards to parallelism.

twsted 11y ago

I don't know. I am not sure yet. What the HN folks think about this?

deleted 11y ago
[deleted]

gsmethells 11y ago

To me, it's more about choice of programming language than performance. Though the latter is very important, I think the former is what will open up doors to making the browser a platform of choice (pun intended). Currently, it feels like JavaScript is the Comcast of the web. Everyone uses it, but that's only because there aren't any other options available to them.

gbersac 11y ago
Definitely agree ! I really hope that web asm will kill javascript and (css by the way). I just hate this language.

jacquesm 11y ago

Personally, I think this is terrible (and it really is a game-changer, only not the kind that I'd be happy about). The further we get away from the web as a content delivery vehicle and more and more a delivery for executables that only run as long as you are on a page the more we will lose those things that made the web absolutely unique. For once the content was the important part, the reader was in control, for once universal accessibility was on the horizon and the peer-to-peer nature of the internet had half a chance of making the web a permanent read/write medium. It looks very much as if we're going to lose all of that to vertical data silos that will ship you half-an-app that you can't use without the associated service. We'll never really know what we lost. It's sad that we don't seem to be able to have the one without losing the other, theoretically it should be possible to do that but for some reason the trend is definitely in the direction of a permanent eradication of the 'simple' web where pages rather than programs were the norm. Feel free to call me a digital Luddite, I just don't think this is what we had in mind when we heralded the birth of the www.

danharaj 11y ago
I think the solution is to think of code as data that should be freely distributed and hackable as well. It isn't the garden that is the issue, but its walls.
- jacquesm 11y ago
  We're heading straight for native code sandboxed in the browser via a bit of a detour. It will be just as hackable as any closed source code that you get from some vendor. Think of it as a slightly more modern version of Java, this time it really is run 'anywhere' as long as 'anywhere' is a browser and the source code stays with the supplier of the web-app.
  - simoncion 11y ago
    Yep. The web-heads are slowly reimplementing Unix in the browser. [0] We could have avoided this with better, wider-spread support for sandboxing of untrusted executables. Alas. [0] They don't have crashdumps yet, but I expect that they soon will.

kibwen 11y ago

On the Rust side, we're working on integrating Emscripten support into the compiler so that we're ready for WebAssembly right out of the gate. Given that the initial release of WebAssembly won't support managed languages, Rust is one of the few languages that is capable of competing with C/C++ in this specific space for the near future. And of course it helps that WebAssembly, Emscripten, and Rust all have strong cross-pollination through Mozilla. :) If anyone would like to get involved with helping us prepare, please see https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-... EDIT: See also asajeffrey's wasm repo for Rust-native WebAssembly support that will hopefully land in Servo someday: https://github.com/asajeffrey/wasm https://github.com/asajeffrey/wasm

no1youknowz 11y ago

I think the web may split into two. 1) 'Simple' web pages will stick with jquery, react, angular, etc type code. Where you can still click view source and see whats going on. Where libs are pulled from CDNs etc. 2) 'Complex' saas web apps, where you need native functionality. This will be a huge bonus. I'm in this space. I would love to see my own application as a native app. The UI wins alone make it worth it!

ash_gti 11y ago
What does 'native functionality' mean for a web app? Do you mean skipping the DOM and making a Canvas for displaying content? Or do you mean something else?
- deleted 11y ago
  [deleted]

stevenh 11y ago

If anyone at infoworld.com reads these comments: On the top of the page, there is a horizontal menu containing "App Dev • Cloud • Data Center • Mobile ..." When I position my cursor above this menu and then use the scroll wheel to begin scrolling down the page, once this menu becomes aligned with my cursor, the page immediately stops scrolling and the scroll wheel functionality is hijacked and used to scroll this menu horizontally instead. It took a few seconds to realize what was happening. At first I thought the browser was lagging - why else would scrolling ever abruptly stop like that? I closed the page without reading a single word.

ape4 11y ago

The format of WebAssembly could be Java ByteCode.

rubber_duck 11y ago
It's lower level than that.

n00b101 11y ago

What is the upgrade path for Emscripten users? I understand that LLVM will have WebAssembly backend, but how will OpenGL to WebGL translation work, for example?

azakai 11y ago
Emscripten can already compile to both asm.js and WebAssembly, with just flipping a switch between them. All the JS library support code is unchanged, so Emscripten's OpenGL to WebGL layer is used just like before, and the same for all the other libraries. The WebAssembly backend in LLVM will eventually be used by Emscripten as another way to emit WebAssembly (right now it translates asm.js to WebAssembly), but the new backend is not ready yet. See also https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly

jimmcslim 11y ago

I wish the browser vendors focused on CSS Grid module support as much as they did WebAssembly.

machuidel 11y ago

Since I started hearing about WebAssembly I cannot stop thinking about the possibilities. For example: NPM compiling C-dependencies together with ECMAScript/JavaScript into a single WebAssembly package that can then run inside the browser. For people thinking this will close the web even more because the source will not be "human"readable. Remember that JavaScript gets minified and compiled into (using Emscripten) as well. The benefits I see compared to what we have now: - Better sharing of code between different applications (desktop, mobile apps, server, web etc.) - People can finally choose their own favorite language for web-development. - Closer to the way it will be executed which will improve performance. - Code compiled from different languages can work / link together. Then for the UI part there are those common languages / vocabularies we can use to communicate with us humans: HTML, SVG, CSS etc. I only hope this will improve the "running same code on client or server to render user-interface" situation as well.

spb 11y ago
More importantly, if we want to make "view source" more palatable in a WebAssembly age, we need to have it support source maps from day 1.
- machuidel 11y ago
  Yes, that would be good for development / debugging (like debug symbols) or as an optional way to give people access to the source.
rubber_duck 11y ago
>For example: NPM compiling C-dependencies together with ECMAScript/JavaScript into a single WebAssembly package that can then run inside the browser. The reason you'd write stuff in C is (aside from performance) to access native API. Browsers and WASM doesn't let you do that. WASM in the Node could let you do that - meaning that you would get cross platform assembly packages instead of ELF or w/e binary - but you would still need APIs on the platform and often for C the way that's handled is preprocesor macros that choses which platform you are compiling to - so you can't just "compile to WASM and then magic" even with WASM you'd have to "compile to WASM + POSIX and WASM + Win32" if you want to run on POSIX/Win32, etc. for all platform/API permutations. TL;DR WASM is big but it won't quite be the abstract virtual machine like say JVM or CLR

opacityIsCool 11y ago

Yeah, great. Transform everything into opaque binary blobs, as far as the eye can see. Wonderful. Thanks for nothing.

T-A 11y ago
From http://webassembly.github.io/ http://webassembly.github.io/ : "Open and debuggable: WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. The textual format will be used when viewing the source of wasm modules on the web."
- opacityIsCool 11y ago
  Yeah, nice, this and and so many other formats, that people just throw up their hands and give up on, when confronted with the raw binaries they work with on a daily basis, are simply open and wonderful all the time. Except not. Portable Executables. ELF binaries. Zip Files. Open Image Formats. All of these are theoretically open, and perfectly accessible to all, in their raw form. And yet broadly inaccessible to like 90% of the world's lay people, since the concept of an interpreter eludes them, and in some cases is explicitly denied to them. The same will happen with this. This puts things on a shelf, well out of reach to many more people. And a very small group of people love that. So, while encrypted smart phones and email "go dark" on mass surveillance, the rest of everything else "goes dark" for ordinary people.

icedchai 11y ago

WebAssembly... Wow, if we keep going, we'll re-invent what Sun achieved 20 years ago with Java. If only they hadn't f-ed it up...

protomyth 11y ago
The JVM problem was that it had applets and did not have the DOM integration of Javascript. I do often wonder if instead of Javascript in 1995 we had got WebAssembly and WebSockets.
- icedchai 11y ago
  You could actually call into JavaScript from Applets, using something called LiveConnect. See https://docs.oracle.com/javase/tutorial/deployment/applet/invokingJavaScriptFromApplet.html https://docs.oracle.com/javase/tutorial/deployment/applet/in... Was it simply/easy? No. But, you probably wouldn't want to.. The DOM is a crappy way to build an application UI. Someday we might figure that out.
  - esailija 11y ago
    If you consider custom elements, how is it different from any other way of building ui?
  - cheez 11y ago
    The concept of the DOM is so widely considered to be useful in declaring user interfaces, that multiple languages have copied it. http://fxexperience.com/wp-content/uploads/2011/08/Introducing-FXML.pdf http://fxexperience.com/wp-content/uploads/2011/08/Introduci... https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://en.wikipedia.org/wiki/Extensible_Application_Markup_... The HTML DOM sucks, but what other DOM is widely available and already installed on literally every machine on the planet?
- Touche 11y ago
  Probably the 2 minute startup time was a bigger problem for applets.

bitL 11y ago

Brendan, looking at your photo, please take your time off, get into a shape and have more fun! Thanks for all your work so far but don't overdo it please!

icosta 11y ago

WebAssembly = SWF with diff name. Come on!

deleted 11y ago
[deleted]

bcoates 11y ago

If you think WebAssembly (or asm.js) is a good idea, I would very much like you to do the thought experiment of what design decisions something like WebAssembly would have made 15 or 25 years ago, and what consequences those would have today. Helpful research keywords: Itanium RISC Alpha WAP Power EPIC Java ARM Pentium4 X.25

smitherfield 11y ago
I can't think of any software development API that ended up being perfect 15 or 25 years later. Javascript certainly isn't. Java applets, ActiveX controls and Flash very much weren't, but, at the time, they did things you couldn't with the standard web stack. And we're better off for learning the lessons of the failures, creating improved technologies to replace them (HTML5, JIT Javascript engines, etc), and building on the successes to continuously do more things that previously couldn't be done in the browser. Will WebAssembly be perfect? Of course not. Will there be unanticipated problems? Of course. I would not at all be surprised if it becomes the next Flash. But it's better to move forward and keep innovating with new web technologies instead of letting the platform stagnate. We've tried feature-freezing the web for a few years; it was called "Internet Explorer 6" and it sucked.

Pxtl 11y ago

If we keep this up, the web will be almost as good of an application framework as a '90s era desktop application. Yay, progress!

deleted 11y ago

[deleted]

xaduha 11y ago

WebAssembly shouldn't be for the end users to use, it should used for implementations of other languages so they can access the same APIs Javascript can. Add Lua to the browser, add Perl 6 to the browser, etc. There are plenty of decade old W3C specifications that never made it to the browser properly, like XSLT 2.0, XQuery 1.0, XForms, never mind the latest versions of the specs.

esailija 11y ago
I don't see how it can be feasible to use it for implementations of other languages that don't directly map to webassembly like C. You would have to ship a runtime for the other language along with your application code. The runtime will be either huge with long startup time or small but too slow to be feasible.
- xaduha 11y ago
  Whichever it is it can't be worse than implementing other languages in Javascript directly or using stuff like GWT and there are plenty of those already (including development for running Perl 6, btw). Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached.
  - esailija 11y ago
    > Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached. Web Assembly isn't related to this. You can standardize on a new language VM that browsers should ship, like was attempted with Dart. What Web Assembly enables is more efficient VM with better interop to Web APIs than currently is possible, but the most prohibitive thing will not change (having to ship multi megabyte VM along with your application code).
    - xaduha 11y ago
      Lots of things will change. If it makes sense to do that, then there will be demand for it. Here's something already https://news.ycombinator.com/item?id=11269736 https://news.ycombinator.com/item?id=11269736

spitfire 11y ago

I wonder if along with these byte code engines we'll get capability grained control systems too. Somehow I doubt it though. So in the future, when you visit a website they'll be able to Eg: open windows, pop up unblockable modals, webGL, bytecode loaded spam/ads, etc. The end users option will be to block everything, or live with it. I do not like this bold new world we're entering.

esailija 11y ago
This is a common confusion somehow. The programming language has nothing to do with the APIs provided by an environment. JavaScript can do all those things now, as long as you run it in an environment that provides APIs to do those things (node.js, electron etc). The browser is not that environment. When you write a keylogger virus in C, you are relying on the APIs provided by the environment to do it, they don't come from the C language.
- spitfire 11y ago
  I wasn't confused at all. Technically there is a difference between a language, an API and a platform. That's all true in the case of NodeJS and the like, but not true for web browsers. There the language the API and the platform come as one. The result is, remote websites can execute code on a users computer. With no control except for simple technical measures.

eggy 11y ago

I still think there is a lot of room for static pages with links in the style that people seem to be prematurely waxing melancholy about when forecasting where WebAssembly _may_ lead the internet. I was always able to find sites of interest that didn't include Flash, Java applets, and company when I just wanted to read something. I find some of the scroll-hijacking, and other javascript goodies on modern pages to either be a distraction, or non-functional on some different devices. On the other hand, I am particularly happy about, and working with Pollen in Racket, a creation by Matthew Butterick. Pollen is a language created with Racket for making digital books, books as code, and bringing some long-needed, real-world publishing aesthetics back to the web [1,2]. I may even by a font of his to get going and support him at the same time! [1] http://docs.racket-lang.org/pollen/ [2] http://practical.typography.com

travisty 11y ago

Thanks for that update that no one asked for.

whyever 11y ago
Do you think someone asked for this comment?
oconnor663 11y ago
I'm excited to hear the Rust news, but I don't want to make a "+1" comment or whatever, since that clutters the thread. There might be other people who feel the same.
dang 11y ago
Please don't be rude. We detached this subthread from https://news.ycombinator.com/item?id=11262923 https://news.ycombinator.com/item?id=11262923 and marked it off-topic.

ak39 11y ago

Is WebAssembly going to be host url resource based (like current .js files are) or will it be used as part of some centralized global assembly cache (GAC) solution where assemblies are only usable from a CDN type of authority?

nadam 11y ago

A question to WebAssembly experts: How easy it is to use WebAssembly as a sandboxed embedded scripting mechanism in my own native (C++) application? I am writing a native real-time system (a distributed 3D engine for VR) in which I send scripts on the wire between machines, and I need to call an update() method of these sent scripts like 90 times a frame. I need complete sandboxing, because my trust model is that what is trusted on machine A may be absolutely not trusted on machine B: not only not letting the scripts do any functions other than what I explicitly let them call, but I need to have hard limit on their memory usage and execution time also, but preferably they should execute in-process, so they can reach memory I let them and be called from the thread I want. Currently I go wtih Lua, but to have really good performance I will need to research this topic more deeply later.

hutzlibu 11y ago

Sorry, but most of the discussion here is completly missing the point about WebAssembler. It is just a technology, to make things brought through the web, faster. And it is open. And no less secure, than js. So I think it's great. Good technology does exactly, what the creator wants. And if people don't like some of the things, that gets created with it, then it is not a problem of the technology itself. So people can do good things, or bad things with it. But in the web, we have the freedom to choose, where we go. And if we don't like ads for example, we should be aware, that Web-Site creators still want money for their work, so maybe we should focus and support a different funding model. I like the pay-what-you-want or donation model the most, Wikipedia shows, that this is possible on a large scale ...

deleted 11y ago

[deleted]

madsravn 11y ago

This looks AWESOME

Executor 11y ago

I'm conflicted. One one hand I support open data/raw documents. But this prevents native-like, real-time applications. It also forces developers to work on Javascript which is a terrible language. On the other hand we have lock-in ecosystems, closed silos, that are detrimental to the commons. The only consolation I have is that if WebAssembly provides a bytecode instead of machine code then we still have the ability to perform reverse engineering. In the end, we have ALL have to do the hard task to inform every single person why Apple/FB/MS/Google are harmful to us and why we should boycott their programs/services.