26 ms·

WebAssembly: a binary format for the web

216 points by olalonde 11y ago

corysama 11y ago
A good talk from a week ago on WebAssembly: https://www.youtube.com/watch?v=NhAPPQqKCi8 https://www.youtube.com/watch?v=NhAPPQqKCi8
- mstade 11y ago
  Merits of the contents aside, the guy presenting has a very judgmental and condescending tone making it difficult to appreciate what he's actually saying. Saying things like "this doesn't look anything like a programming language, especially if you're coming from the javascript world" or "I will explain shared memory multi-threading in a bit, especially for the front end developers" really doesn't help. I find statements like that offensive, and detrimental to getting good conversations going. I've not finished watching that presentation on these grounds, and I'm not sure I will. It's not out of principle either, but simply because I get too annoyed to continue. For the record, I identify myself as a software engineer. These days I mostly do front end development, but I have written code in many languages and contexts (asm, javascript, c, python, vb, whatever fits) and been well remunerated for it. I find the front/back/native/whatever splits to be silly, probably fueled by trying to make more efficient job listings. Fine that HR folks do this, but as engineers we should know better.
  - ZenoArrow 11y ago
    So you're a full stack developer. Some coders are only familiar with their domain. For example, most of my coding experience has been backend database scripting stuff, I have very little familiarity with the front end. I don't see why you would get offended, he was talking to the specialists, not the generalists. You have to understand there's no shame in not knowing something outside your domain. For example, if you've never done AI programming before, would you be offended if an experienced AI coder skipped over some details in order to provide a more friendly introduction? It's not meant as an insult, it's not a reflection on your capability to learn about it, but rather it could be based on a consideration that you may not have taken the time to learn about it yet.
    - roel_v 11y ago
      A good communicator is careful in his phrasing and keeps 'the human factor' in mind. It's not something that engineers are usually willing to admit or cater to, of course, but doesn't make it less true. As a corollary, this is the same point that people asking 'why aren't engineers paid better' are really asking about, but can't or won't see...
      - ZenoArrow 11y ago
        Engineers don't like being talked down too, but if something is outside your field then simplifying is still pragmatic, regardless if you have extensive knowledge in other fields. Let's put it like this, if I was the guy giving the talk, and I knew I'd get this reaction, I would do nothing differently. I'm not going to waste my time pandering to people who would take a tech talk personally. I don't care if managers get paid more, if they want to water down their words to ensure no offence to anyone, they're welcome to take that burden.
        mstade 11y ago
        It's not about pandering, but about being inclusive in an educational setting. You're giving a talk so as to inform people, not imply they are lesser in some way. To concretize, consider replacing "the front-end developers" with "those unfamiliar with the concept": > I will explain shared memory multi-threading in a bit, especially for those unfamiliar with the concept. Versus the condescending: > I will explain shared memory multi-threading in a bit, especially for the front-end developers. Tiny change, makes all the difference. Be inclusive; don't be condescending.
  - Stratoscope 11y ago
    I'm really sensitive to the issue you mention, and I appreciate your bringing it up. It annoys me no end when someone talks down to me, or maybe even worse, asks about my skill level in a particular area when the implication is that they will then know how to dumb down what they're saying to a level that even I may understand. But after watching the first 15 minutes of the video, I'm not seeing any kind of judgmental or condescending tone. Was it something in the remaining half hour? He did ask for a show of hands of front end vs. native developers, but you have to admit that front end developers who've only done front end may never have been exposed to the concept of threads with shared memory - his topic for the next few minutes. So my suggestion is to give it another shot. Based on the first 15 minutes, it seems like a fairly interesting and insightful talk.
  - jitix 11y ago
    This is a very disturbing trend in the software industry (starting around mid 2000s). A person who knows programming semantics can code in any language, but because of over-reliance on frameworks and the hesitation to try and write deep code, developers are being segregated into frond-end, middleware, db, big data, etc. I don't think it's sustainable in the long term.
denniskane 11y ago
"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!
- Blackthorn 11y ago
  If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...
  - denniskane 11y ago
    Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.
  - bobajeff 11y ago
    Either he's mixing narratives here or he's using standard web development practices as the context of it failing. Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.
- josteink 11y ago
  PNaCl is cancer to the web and requires Google Spyware. No thanks.
  - denniskane 11y ago
    PNaCl allows me to run vim and python natively in my browser. Thanks. (Shout out to my boys, Sam Clegg, Brad Nelson and company!)
    - icebraining 11y ago
      Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/ https://brendaneich.com/2005/09/python-for-xul-scripting/
Animats 11y ago
From Java applets to Java applets in twenty years.
- bobajeff 11y ago
  Except with C++ instead of Java and the DOM instead of Java API's.
  - niccaluim 11y ago
    That doesn't sound like an improvement.
    - pmelendez 11y ago
      It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.
      - niccaluim 11y ago
        Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
        RyanZAG 11y ago
        At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.
jacquesm 11y ago
Write once, run anywhere.
huuu 11y ago
Posted some time ago, a .NET implementation and discussion: https://github.com/WebAssembly/ilwasm https://github.com/WebAssembly/ilwasm https://news.ycombinator.com/item?id=10162793 https://news.ycombinator.com/item?id=10162793 I also have to think about the new image file format posted some time ago: FLIF (http://flif.info/ http://flif.info/). With WebAssembly you could implement this in the browser by just embedding a lib. No need to wait for the vendors to support it.
rasz_pl 11y ago
can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.
- RussianCow 11y ago
  No, but one of the goals of WebAssembly is to have a textual representation, so in theory you could still View Source. Not sure how that'll work out in practice, though.
  - rasz_pl 11y ago
    doesnt need to be the original source, as long as every browser has some form of decompiler to high level language (C like) Im good. But I cant imagine a future where we are served blobs with no way of knowing whats inside.
    - icebraining 11y ago
      Have you seen the source of google.com? x86 assembly is more readable than the current minified JS.
  - userbinator 11y ago
    In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too. What's wrong with that argument is the fact that although most users don't need it, it's an excellent way for those interested to explore into and find out how things work, and essentially get into web development with nearly no effort. If this trend continues, in the future when browsers become nothing more than dumbed-down interactive TVs, I think there will be very few, if any, web developers who started out of their own interest and exploration instead of solely thinking of it as a profession, and that's a really bad thing. (For the corporations who want to take control, this could be viewed as a good thing - why would they want to encourage independent thought and exploration when they could have dogmatic obedience?) Computing systems are becoming more closed and proprietary, and this will be a big step backwards in terms of openness of the Web that lead to its growth and freedom in the first place.
yjgyhj 11y ago
What does this mean for compile-to-js languages, like Clojurescript, Elm (and ES2015 one might argue)?
- corysama 11y ago
  So far, not much. Clojurescript, Elm and most others assume that JS is taking care of garbage collection for them. Meanwhile, WebAssembly so far does not include GC support. If someone were to implement a custom GC for Elm on top of wasm's "here's a big array of bytes" memory model, it would be very interesting indeed. But, at the moment wasm is primarily a target for C/C++.
  - MichaelGG 11y ago
    That's rather weak. How do you interop with the DOM? Explicit FFI? Are there plans to make WebAssembly catch up with the last several decades? There's no reason we can't have a proper IL like .Net or even Java at worst.
    - corysama 11y ago
      Yep, FFI. GC/DOM/Web API integration is in the eventual plans. https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md You want .NET on bare metal? Implement it on x64, ARM, MIPs and maybe PPC. You want .NET in the browser, implement it on wasm. You want Java in the browser, implement it on wasm. You want BEAM in the browser, implement it on wasm. You want Parrot in the browser, implement it on wasm. What you are not going to do is to get Google, Apple, Mozilla and Microsoft to all agree on any of those ILs.
jgalt212 11y ago
If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you are not forced too, I do not think most will.
- coldtea 11y ago
  >If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source What "open source"? Open Source is dead in web services, because everybody can just hide the source behind the server. Even with SPAs, you could have 90% of the actual functionality on the server side, behind REST APIs and the like.
  - Spivak 11y ago
    Sure, but you at least you have the ability to inspect the code which is running on your machine. A FOSS client to a proprietary service is still meaningful.
- mrec 11y ago
  How is this any worse than minified Javascript? Without meaningful names or comments you're not much better off than you would be with WASM+disassembler.
  - roel_v 11y ago
    It's the difference between a 'java decompiler' and a 'c++ decompiler'. Which is significant enough for there to be a market for commercial 'java obfuscators', but not for 'c++ obfuscators'.
dbpokorny 11y ago
As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s. I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context. For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution. (Yes I understand JavaScript is code from an untrusted source that runs in a sandbox on your computer, the browser client; in this context I'm referring to the ability of a JavaScript web app to load objects (from a JavaScript source code file hosted on ANY domain, in defiance of XSS dogma) which the browser client guarantees does not exceed the bounds of a specified "sandbox" built to spec, a "security envelope" for loading and evaluating code. For example the ability to tell the client, "execute procedure P with arguments A, but kill it if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB of memory" or "only load this source code as long as the global variables it uses is on this list: ..., the names of properties is uses is on this list: ..., and it refrains from using the following syntactic keywords: ...) Python put up a warning against its own "restricted execution" a long time ago: https://docs.python.org/2/library/restricted.html https://docs.python.org/2/library/restricted.html In the age of GitHub, why is there no interest in building infrastructure that allows programmers to define such "security envelopes" for JavaScript, Python, C, and so on and create systems which are composed of mutually distrusting modules which would, I think, simplify reasoning about their security characteristics?
- toyg 11y ago
  Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that security is a trade-off, the trade-off in this case is likely not worth it.
omphalos 11y ago
It would be nice if the ability to reason about execution timings were one of the design goals of WebAssembly, because this could make it safer to port to crypto to the web.
spo81rty 11y ago
So could someone theoretically make flash or silverlight work via this?
- elcritch 11y ago
  Theoretically you can make those work in JavaScript. The performance might even be ok, but the limitations would still be the huge effort in reverse engineering flash or silver light code and features and secondly the browser sandbox policies which AFAIK aren't changed for WASM.
  - icebraining 11y ago
    It's not just a theory, Mozilla has already implemented Flash in JS: https://github.com/mozilla/shumway https://github.com/mozilla/shumway
hannob 11y ago
I haven't looked at WebAssembly in Detail, but my feeling and worry is that this is a can of worms for security issues. Javascript wasn't designed with security in mind and it has taken us decades to understand what implications that had (and we haven't really fixed them yet). The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. (pnacl already introduced some quite unexpected issues, e.g. allowing control over cache flushes and thus making rowhammer attacks easier.) Given that neither the linked text nor the FAQ they have does even mention and discuss that I'm even more worried.
- pcwalton 11y ago
  > The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. What can you do today in Web Assembly that you can't already do in asm.js?
  - hackcasual 11y ago
    Nothing. WebAssembly in its current implementation is basically a binary representation of asm.js.
- netheril96 11y ago
  With all the lessons learned, I would think that a completely new implementation would have less security issues.
kmicklas 11y ago
Why does everything about WebAssembly make such a big deal about it being AST based rather than a stack or register machine? Sure this is a meaningful technical difference but I don't see why it's really a "selling point".
- pinealservo 11y ago
  Here are some arguments from the guys who did something like this before for Oberon: ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf To summarize: 1. Much smaller representation, which will mean faster download times 2. More control-flow structure retained, which means less needs to be rebuilt by JIT-compilers. 3. As a corollary of #2, we get easier and more helpful 'decompiling' of code blobs 4. Another corollary of #2: easier analysis for safety properties
denniskane 11y ago
Okay, seriously. The only possible benefit that this technology could have for the planet is to give Brendan Eich a reason to run yet another one of those video-game-inside-of-a-video-game demos at another one of those JS conferences that frontend devs go so nuts about. Except this time, there will be yet another video game inside of that inner video game!
zobzu 11y ago
The future! serve binaries instead of web pages!
- pekk 11y ago
  Web pages are already a far cry from human-readable semantic markup. That's not a hill worth dying on.
  - zobzu 11y ago
    careful what you wish for
drvortex 11y ago
Binary blobs on the web? Have we learnt nothing from ActiveX?
- yuhong 11y ago
  ActiveX had full access to the user's system.
  - deleted 11y ago
    [deleted]
zmmmmm 11y ago
As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implementation techniques and technologies, hide poor code and poor security. I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. It is only an accident of history that it worked out that way. But the effect has been to spread knowledge far and wide and it has greatly contributed to the success of web technologies. Furthermore, I can easily look at the source code for my bank web site or any web site I want to trust and get a good idea of how solid their implementation is. Yes I can't inspect the back end, but a whole slice of front-end security issues are easy for me to check for myself. This kind of scrutiny will get a good bit harder if web assembly becomes adopted.
- asdfologist 11y ago
  https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
- luhn 11y ago
  > I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. Not really. Almost all websites obfuscate/minify their Javascript now, making manually interpreting the code much less than "trivial." I think WebAssembly will be no worse to figure out than obfuscated Javascript.
  - zmmmmm 11y ago
    I think it will be much worse. Minified Javascript is pretty easy to turn back into something moderately understandable just by "prettifying" it. I do this all the time. It works pretty well because it started as Javascript, so turning it back into Javascript has a relatively clean mapping. WebAssembly will have started as some other language or even as no language at all - there may be no mapping back to anything Javascript could represent. It will be much closer to disassembly of machine code, or Java byte code, which is possible but challenging enough that most ordinary developers never do it.
jtwebman 11y ago
I hope to see so the developers that don't like JavaScript stop writing bad JavaScript and just write it in whatever class based type based system they want instead of adding classes and types to Javascript.
- runn1ng 11y ago
  But adding type system to JavaScript - as Facebook has done with Flow - and class system - as in ES6 - actually makes complex JavaScript better and easier...
  - ilaksh 11y ago
    I have literally heard the argument that React basically doesn't count as OOP anymore because they are now emphasizing 'functional' Javascript, even though they still rely on the main base class.
    - runn1ng 11y ago
      I don't really know. I use Flow, but I don't use React.
no1youknowz 11y ago
I am someone who makes a living having a SaaS that clients use. I've had clients who have tried to "clone" my work, but eventually come back because they couldn't figure out the backend code or scale. I would love something that is the equivalent of installing an app on a phone, that is using a compiled app in a browser. Where the source can't be viewed. Even better, if I can give a rich UX. By having access to the system. Yes, I believe in some very small cases this will be welcomed. Otherwise, I think for everyone like 95% of the web, html, js, css, etc, will see be the way to go.
- nv-vn 11y ago
  So even though they can't succeed at 'stealing' your job by copying the code you still don't want them to have access?
  - no1youknowz 11y ago
    I don't have a job. I offer a service to clients. I get paid when they use my software. If they created their own software, they would not have to pay me any money. So without money, I have to go on welfare. You get my point? No, I don't want any of my clients to get access to my source code. I am not a giant corporation like redhat, google, oracle or other company that open sources it's software and then sells support or other services. I'm a small company, who with more clients. Is hoping to them employ a small workforce and grow the company.
ilaksh 11y ago
The big advantage for web assembly is that is really language agnostic (besides the performance).
masswerk 11y ago
Hm – Client-side web programming is all about resource management. I can't see, how cross-compiled C++ code that originated for a completely other platform with object code in the MBs range will do a decent job. And even, if this is not the original idea of WebAssembly, this is sure to come. (We've seen similar with emscripten: As much as I love it as an experiment, it's highly problematic in production.) And of course, as others have already pointed out, it's likely to ruin the vision of the web as a mosaic of just a few trivial technologies that can be investigated with modest knowledge. (Compare the comment by zmmmmm.)
JoshMnem 11y ago
What will this mean for blocking ads and certain trackers? If the source of the page isn't viewable, how will users know what the code is doing?
- pritambaral 11y ago
  I'm sure you can still inspect the DOM and the network calls made by the page. DOMs, URLs, and HTTP aren't going anywhere. And the current ad-blockers almost never go through the source code of a script, only the src and the URLs
alkonaut 11y ago
I see a future in which I write apps that run JS for the DOM, but I need to worry about neither JS nor the DOM. Glorious.
einrealist 11y ago
The major flaw in WebAssembly is the byte code itself. We will end up in a compatibility hell, because of course the specification will change. And there will be several implementations of WebAssembly, which will have their own quirks and flaws. So the WebAssembly future will look like this: You will compile into WebAssembly multiple times, for different versions and implementations and you will need to deliver the correct artifacts to the clients. The reason, the web still works is that everything is shipped to the client in source. And the client will then interpret and compile everything according to its capabilities. WebAssembly will probably never gain traction because of this reality.
luancestari 11y ago
Awesome, I would love to see an helloworld application hosted in github
androi 11y ago
Hi i have also found one good example here ... <a href="http://androidexample.com/Global_Variable_Or_Application_Context http://androidexample.com/Global_Variable_Or_Application_Con... _Variable_-_Android_Example /index.php?view=article_discription&aid=114&aaid=136">http://androidexample.com http://androidexample.com /Global_Variable_Or _Application_Context_Variable_-_Android_Example/ index.php?view=article_discription&aid=114&aaid=136</a>
androi 11y ago
Hi i have also found one good example here ... <a href="http://androidexample.com/Global_Variable_Or_Application_Context http://androidexample.com/Global_Variable_Or_Application_Con... _Variable_-_Android_Example /index.php?view=article_discription&aid=114&aaid=136">http://androidexample.com http://androidexample.com /Global_Variable_Or _Application_Context_Variable_-_Android_Example/ index.php?view=article_discription&aid=114&aaid=136</a>

216 points by olalonde 11y ago

A good talk from a week ago on WebAssembly: https://www.youtube.com/watch?v=NhAPPQqKCi8 https://www.youtube.com/watch?v=NhAPPQqKCi8

mstade 11y ago
Merits of the contents aside, the guy presenting has a very judgmental and condescending tone making it difficult to appreciate what he's actually saying. Saying things like "this doesn't look anything like a programming language, especially if you're coming from the javascript world" or "I will explain shared memory multi-threading in a bit, especially for the front end developers" really doesn't help. I find statements like that offensive, and detrimental to getting good conversations going. I've not finished watching that presentation on these grounds, and I'm not sure I will. It's not out of principle either, but simply because I get too annoyed to continue. For the record, I identify myself as a software engineer. These days I mostly do front end development, but I have written code in many languages and contexts (asm, javascript, c, python, vb, whatever fits) and been well remunerated for it. I find the front/back/native/whatever splits to be silly, probably fueled by trying to make more efficient job listings. Fine that HR folks do this, but as engineers we should know better.
- ZenoArrow 11y ago
  So you're a full stack developer. Some coders are only familiar with their domain. For example, most of my coding experience has been backend database scripting stuff, I have very little familiarity with the front end. I don't see why you would get offended, he was talking to the specialists, not the generalists. You have to understand there's no shame in not knowing something outside your domain. For example, if you've never done AI programming before, would you be offended if an experienced AI coder skipped over some details in order to provide a more friendly introduction? It's not meant as an insult, it's not a reflection on your capability to learn about it, but rather it could be based on a consideration that you may not have taken the time to learn about it yet.
  - roel_v 11y ago
    A good communicator is careful in his phrasing and keeps 'the human factor' in mind. It's not something that engineers are usually willing to admit or cater to, of course, but doesn't make it less true. As a corollary, this is the same point that people asking 'why aren't engineers paid better' are really asking about, but can't or won't see...
    - ZenoArrow 11y ago
      Engineers don't like being talked down too, but if something is outside your field then simplifying is still pragmatic, regardless if you have extensive knowledge in other fields. Let's put it like this, if I was the guy giving the talk, and I knew I'd get this reaction, I would do nothing differently. I'm not going to waste my time pandering to people who would take a tech talk personally. I don't care if managers get paid more, if they want to water down their words to ensure no offence to anyone, they're welcome to take that burden.
      - mstade 11y ago
        It's not about pandering, but about being inclusive in an educational setting. You're giving a talk so as to inform people, not imply they are lesser in some way. To concretize, consider replacing "the front-end developers" with "those unfamiliar with the concept": > I will explain shared memory multi-threading in a bit, especially for those unfamiliar with the concept. Versus the condescending: > I will explain shared memory multi-threading in a bit, especially for the front-end developers. Tiny change, makes all the difference. Be inclusive; don't be condescending.
- Stratoscope 11y ago
  I'm really sensitive to the issue you mention, and I appreciate your bringing it up. It annoys me no end when someone talks down to me, or maybe even worse, asks about my skill level in a particular area when the implication is that they will then know how to dumb down what they're saying to a level that even I may understand. But after watching the first 15 minutes of the video, I'm not seeing any kind of judgmental or condescending tone. Was it something in the remaining half hour? He did ask for a show of hands of front end vs. native developers, but you have to admit that front end developers who've only done front end may never have been exposed to the concept of threads with shared memory - his topic for the next few minutes. So my suggestion is to give it another shot. Based on the first 15 minutes, it seems like a fairly interesting and insightful talk.
- jitix 11y ago
  This is a very disturbing trend in the software industry (starting around mid 2000s). A person who knows programming semantics can code in any language, but because of over-reliance on frameworks and the hesitation to try and write deep code, developers are being segregated into frond-end, middleware, db, big data, etc. I don't think it's sustainable in the long term.

denniskane 11y ago

"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!

Blackthorn 11y ago
If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...
- denniskane 11y ago
  Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.
- bobajeff 11y ago
  Either he's mixing narratives here or he's using standard web development practices as the context of it failing. Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.
josteink 11y ago
PNaCl is cancer to the web and requires Google Spyware. No thanks.
- denniskane 11y ago
  PNaCl allows me to run vim and python natively in my browser. Thanks. (Shout out to my boys, Sam Clegg, Brad Nelson and company!)
  - icebraining 11y ago
    Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/ https://brendaneich.com/2005/09/python-for-xul-scripting/

Animats 11y ago

From Java applets to Java applets in twenty years.

bobajeff 11y ago
Except with C++ instead of Java and the DOM instead of Java API's.
- niccaluim 11y ago
  That doesn't sound like an improvement.
  - pmelendez 11y ago
    It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.
    - niccaluim 11y ago
      Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
      - RyanZAG 11y ago
        At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.

jacquesm 11y ago

Write once, run anywhere.

huuu 11y ago

Posted some time ago, a .NET implementation and discussion: https://github.com/WebAssembly/ilwasm https://github.com/WebAssembly/ilwasm https://news.ycombinator.com/item?id=10162793 https://news.ycombinator.com/item?id=10162793 I also have to think about the new image file format posted some time ago: FLIF (http://flif.info/ http://flif.info/). With WebAssembly you could implement this in the browser by just embedding a lib. No need to wait for the vendors to support it.

rasz_pl 11y ago

can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.

RussianCow 11y ago
No, but one of the goals of WebAssembly is to have a textual representation, so in theory you could still View Source. Not sure how that'll work out in practice, though.
- rasz_pl 11y ago
  doesnt need to be the original source, as long as every browser has some form of decompiler to high level language (C like) Im good. But I cant imagine a future where we are served blobs with no way of knowing whats inside.
  - icebraining 11y ago
    Have you seen the source of google.com? x86 assembly is more readable than the current minified JS.
- userbinator 11y ago
  In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too. What's wrong with that argument is the fact that although most users don't need it, it's an excellent way for those interested to explore into and find out how things work, and essentially get into web development with nearly no effort. If this trend continues, in the future when browsers become nothing more than dumbed-down interactive TVs, I think there will be very few, if any, web developers who started out of their own interest and exploration instead of solely thinking of it as a profession, and that's a really bad thing. (For the corporations who want to take control, this could be viewed as a good thing - why would they want to encourage independent thought and exploration when they could have dogmatic obedience?) Computing systems are becoming more closed and proprietary, and this will be a big step backwards in terms of openness of the Web that lead to its growth and freedom in the first place.

yjgyhj 11y ago

What does this mean for compile-to-js languages, like Clojurescript, Elm (and ES2015 one might argue)?

corysama 11y ago
So far, not much. Clojurescript, Elm and most others assume that JS is taking care of garbage collection for them. Meanwhile, WebAssembly so far does not include GC support. If someone were to implement a custom GC for Elm on top of wasm's "here's a big array of bytes" memory model, it would be very interesting indeed. But, at the moment wasm is primarily a target for C/C++.
- MichaelGG 11y ago
  That's rather weak. How do you interop with the DOM? Explicit FFI? Are there plans to make WebAssembly catch up with the last several decades? There's no reason we can't have a proper IL like .Net or even Java at worst.
  - corysama 11y ago
    Yep, FFI. GC/DOM/Web API integration is in the eventual plans. https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md You want .NET on bare metal? Implement it on x64, ARM, MIPs and maybe PPC. You want .NET in the browser, implement it on wasm. You want Java in the browser, implement it on wasm. You want BEAM in the browser, implement it on wasm. You want Parrot in the browser, implement it on wasm. What you are not going to do is to get Google, Apple, Mozilla and Microsoft to all agree on any of those ILs.

jgalt212 11y ago

If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you are not forced too, I do not think most will.

coldtea 11y ago
>If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source What "open source"? Open Source is dead in web services, because everybody can just hide the source behind the server. Even with SPAs, you could have 90% of the actual functionality on the server side, behind REST APIs and the like.
- Spivak 11y ago
  Sure, but you at least you have the ability to inspect the code which is running on your machine. A FOSS client to a proprietary service is still meaningful.
mrec 11y ago
How is this any worse than minified Javascript? Without meaningful names or comments you're not much better off than you would be with WASM+disassembler.
- roel_v 11y ago
  It's the difference between a 'java decompiler' and a 'c++ decompiler'. Which is significant enough for there to be a market for commercial 'java obfuscators', but not for 'c++ obfuscators'.

dbpokorny 11y ago

As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s. I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context. For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution. (Yes I understand JavaScript is code from an untrusted source that runs in a sandbox on your computer, the browser client; in this context I'm referring to the ability of a JavaScript web app to load objects (from a JavaScript source code file hosted on ANY domain, in defiance of XSS dogma) which the browser client guarantees does not exceed the bounds of a specified "sandbox" built to spec, a "security envelope" for loading and evaluating code. For example the ability to tell the client, "execute procedure P with arguments A, but kill it if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB of memory" or "only load this source code as long as the global variables it uses is on this list: ..., the names of properties is uses is on this list: ..., and it refrains from using the following syntactic keywords: ...) Python put up a warning against its own "restricted execution" a long time ago: https://docs.python.org/2/library/restricted.html https://docs.python.org/2/library/restricted.html In the age of GitHub, why is there no interest in building infrastructure that allows programmers to define such "security envelopes" for JavaScript, Python, C, and so on and create systems which are composed of mutually distrusting modules which would, I think, simplify reasoning about their security characteristics?

toyg 11y ago
Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that security is a trade-off, the trade-off in this case is likely not worth it.

omphalos 11y ago

It would be nice if the ability to reason about execution timings were one of the design goals of WebAssembly, because this could make it safer to port to crypto to the web.

spo81rty 11y ago

So could someone theoretically make flash or silverlight work via this?

elcritch 11y ago
Theoretically you can make those work in JavaScript. The performance might even be ok, but the limitations would still be the huge effort in reverse engineering flash or silver light code and features and secondly the browser sandbox policies which AFAIK aren't changed for WASM.
- icebraining 11y ago
  It's not just a theory, Mozilla has already implemented Flash in JS: https://github.com/mozilla/shumway https://github.com/mozilla/shumway

hannob 11y ago

I haven't looked at WebAssembly in Detail, but my feeling and worry is that this is a can of worms for security issues. Javascript wasn't designed with security in mind and it has taken us decades to understand what implications that had (and we haven't really fixed them yet). The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. (pnacl already introduced some quite unexpected issues, e.g. allowing control over cache flushes and thus making rowhammer attacks easier.) Given that neither the linked text nor the FAQ they have does even mention and discuss that I'm even more worried.

pcwalton 11y ago
> The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. What can you do today in Web Assembly that you can't already do in asm.js?
- hackcasual 11y ago
  Nothing. WebAssembly in its current implementation is basically a binary representation of asm.js.
netheril96 11y ago
With all the lessons learned, I would think that a completely new implementation would have less security issues.

kmicklas 11y ago

Why does everything about WebAssembly make such a big deal about it being AST based rather than a stack or register machine? Sure this is a meaningful technical difference but I don't see why it's really a "selling point".

pinealservo 11y ago
Here are some arguments from the guys who did something like this before for Oberon: ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf To summarize: 1. Much smaller representation, which will mean faster download times 2. More control-flow structure retained, which means less needs to be rebuilt by JIT-compilers. 3. As a corollary of #2, we get easier and more helpful 'decompiling' of code blobs 4. Another corollary of #2: easier analysis for safety properties

denniskane 11y ago

Okay, seriously. The only possible benefit that this technology could have for the planet is to give Brendan Eich a reason to run yet another one of those video-game-inside-of-a-video-game demos at another one of those JS conferences that frontend devs go so nuts about. Except this time, there will be yet another video game inside of that inner video game!

zobzu 11y ago

The future! serve binaries instead of web pages!

pekk 11y ago
Web pages are already a far cry from human-readable semantic markup. That's not a hill worth dying on.
- zobzu 11y ago
  careful what you wish for

drvortex 11y ago

Binary blobs on the web? Have we learnt nothing from ActiveX?

yuhong 11y ago
ActiveX had full access to the user's system.
- deleted 11y ago
  [deleted]

zmmmmm 11y ago

As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implementation techniques and technologies, hide poor code and poor security. I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. It is only an accident of history that it worked out that way. But the effect has been to spread knowledge far and wide and it has greatly contributed to the success of web technologies. Furthermore, I can easily look at the source code for my bank web site or any web site I want to trust and get a good idea of how solid their implementation is. Yes I can't inspect the back end, but a whole slice of front-end security issues are easy for me to check for myself. This kind of scrutiny will get a good bit harder if web assembly becomes adopted.

asdfologist 11y ago
https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
luhn 11y ago
> I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. Not really. Almost all websites obfuscate/minify their Javascript now, making manually interpreting the code much less than "trivial." I think WebAssembly will be no worse to figure out than obfuscated Javascript.
- zmmmmm 11y ago
  I think it will be much worse. Minified Javascript is pretty easy to turn back into something moderately understandable just by "prettifying" it. I do this all the time. It works pretty well because it started as Javascript, so turning it back into Javascript has a relatively clean mapping. WebAssembly will have started as some other language or even as no language at all - there may be no mapping back to anything Javascript could represent. It will be much closer to disassembly of machine code, or Java byte code, which is possible but challenging enough that most ordinary developers never do it.

jtwebman 11y ago

I hope to see so the developers that don't like JavaScript stop writing bad JavaScript and just write it in whatever class based type based system they want instead of adding classes and types to Javascript.

runn1ng 11y ago
But adding type system to JavaScript - as Facebook has done with Flow - and class system - as in ES6 - actually makes complex JavaScript better and easier...
- ilaksh 11y ago
  I have literally heard the argument that React basically doesn't count as OOP anymore because they are now emphasizing 'functional' Javascript, even though they still rely on the main base class.
  - runn1ng 11y ago
    I don't really know. I use Flow, but I don't use React.

no1youknowz 11y ago

I am someone who makes a living having a SaaS that clients use. I've had clients who have tried to "clone" my work, but eventually come back because they couldn't figure out the backend code or scale. I would love something that is the equivalent of installing an app on a phone, that is using a compiled app in a browser. Where the source can't be viewed. Even better, if I can give a rich UX. By having access to the system. Yes, I believe in some very small cases this will be welcomed. Otherwise, I think for everyone like 95% of the web, html, js, css, etc, will see be the way to go.

nv-vn 11y ago
So even though they can't succeed at 'stealing' your job by copying the code you still don't want them to have access?
- no1youknowz 11y ago
  I don't have a job. I offer a service to clients. I get paid when they use my software. If they created their own software, they would not have to pay me any money. So without money, I have to go on welfare. You get my point? No, I don't want any of my clients to get access to my source code. I am not a giant corporation like redhat, google, oracle or other company that open sources it's software and then sells support or other services. I'm a small company, who with more clients. Is hoping to them employ a small workforce and grow the company.

ilaksh 11y ago

The big advantage for web assembly is that is really language agnostic (besides the performance).

masswerk 11y ago

Hm – Client-side web programming is all about resource management. I can't see, how cross-compiled C++ code that originated for a completely other platform with object code in the MBs range will do a decent job. And even, if this is not the original idea of WebAssembly, this is sure to come. (We've seen similar with emscripten: As much as I love it as an experiment, it's highly problematic in production.) And of course, as others have already pointed out, it's likely to ruin the vision of the web as a mosaic of just a few trivial technologies that can be investigated with modest knowledge. (Compare the comment by zmmmmm.)

JoshMnem 11y ago

What will this mean for blocking ads and certain trackers? If the source of the page isn't viewable, how will users know what the code is doing?

pritambaral 11y ago
I'm sure you can still inspect the DOM and the network calls made by the page. DOMs, URLs, and HTTP aren't going anywhere. And the current ad-blockers almost never go through the source code of a script, only the src and the URLs

alkonaut 11y ago

I see a future in which I write apps that run JS for the DOM, but I need to worry about neither JS nor the DOM. Glorious.

einrealist 11y ago

The major flaw in WebAssembly is the byte code itself. We will end up in a compatibility hell, because of course the specification will change. And there will be several implementations of WebAssembly, which will have their own quirks and flaws. So the WebAssembly future will look like this: You will compile into WebAssembly multiple times, for different versions and implementations and you will need to deliver the correct artifacts to the clients. The reason, the web still works is that everything is shipped to the client in source. And the client will then interpret and compile everything according to its capabilities. WebAssembly will probably never gain traction because of this reality.

luancestari 11y ago

Awesome, I would love to see an helloworld application hosted in github

androi 11y ago

Hi i have also found one good example here ... <a href="http://androidexample.com/Global_Variable_Or_Application_Context http://androidexample.com/Global_Variable_Or_Application_Con... _Variable_-_Android_Example /index.php?view=article_discription&aid=114&aaid=136">http://androidexample.com http://androidexample.com /Global_Variable_Or _Application_Context_Variable_-_Android_Example/ index.php?view=article_discription&aid=114&aaid=136</a>

androi 11y ago