25 ms·

WebAssembly: Mozilla Won

626 points by nachtigall 9y ago

DamonHD 9y ago
Interesting perspective. I've largely kept out of that fight for many reasons, but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story.
- nachtigall 9y ago
  > but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story I think looking at Quantum (https://wiki.mozilla.org/Quantum https://wiki.mozilla.org/Quantum) and Phonton (https://www.ghacks.net/2017/03/31/firefox-photon-new-design-mockups-show-interface-and-more/ https://www.ghacks.net/2017/03/31/firefox-photon-new-design-...) this becomes even more clear.
  - mrec 9y ago
    I agree that Quantum is exciting, but if there's anything interesting about Photon the article you linked really didn't bring it out. What aspects were you thinking of?
    - H4CK3RM4N 9y ago
      I think it's just used here as an example of Moz://a not aping Chrome, by moving their UI even further away.
tete 9y ago
I think this is a good thing. It probably prevented a new DirectX style dark age of the web. Probably! I don't pretend to be able predict what path companies would have went in the next few years. It's really good to see that there is a will to agree and that there is more than one player. Could always be more, also for keeping standards sane. (WebSQL officially failed because there isn't more variety)
- chrisseaton 9y ago
  > It probably prevented a new DirectX style dark age of the web. Do you mean ActiveX rather than DirectX? As in the OLE and COM technology for embedding user interface components on Windows?
  - tete 9y ago
    Sorry. That was before my coffee. It's indeed what I meant. Thanks!
- douche 9y ago
  DirectX fostered multiple generations of gaming on PCs. I dunno what you're talking about with referencing it in a web development context, but it was, and still is, miles ahead of dicking around with broken OpenGL.
  - ealhad 9y ago
    Well, DirectX fostered multiple generations of gaming on Windows.
  - tete 9y ago
    Oops. Meant to write ActiveX.
- rubber_duck 9y ago
  >It probably prevented a new DirectX style dark age of the web. DirectX was hardly a dark age, DX8 and onwards was a step ahead of GL.
  - rocky1138 9y ago
    But tied only to one OS. I believe this is what the OP meant and something I agree with.
  - tete 9y ago
    As already was pointed out. I meant to write ActiveX, not DirectX. I don't actually know too much about graphics programming. Stupid mistake from my side. Sorry!
fpoling 9y ago
This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAssembly application call-stacks are maintained by the JS VM, outside the memory addressable by the application, which reduces the exploitability of application bugs. (Though, again like asm.js and unlike PNaCl, the compiler is trusted.) ---
- dullgiulio 9y ago
  I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.
  - satysin 9y ago
    I think they are talking about something like the Ken Thompson hack? http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
  - roca 9y ago
    It means that a bug in the compiler/optimizer could allow WebAssembly code to escape its sandbox. This is a real issue, but o some extent this extra attack surface is mitigated because vendors are reusing JS compiler backends that are already part of the TCB.
  - foxylad 9y ago
    Add extraneous code?
  - fpoling 9y ago
    Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.
scriptproof 9y ago
Asm.js was a brillant idea, but wasm is more like a bytecode. This is where is the part from NaCl the author missed. Wasm is derived from asm.js but also an improvement on LLVM to make a portable bytecode, that LLVM is not. One more step in the LLVM toolchain to get portability...
- ZenoArrow 9y ago
  WASM isn't based on LLVM. WASM is a compiler target, but compilers other than LLVM can target WASM.
  - sitkack 9y ago
    And WASM is now the defacto portable Bitcode. Just as JS took over the world, so will WASM. In six months, WASM will have had more program launches than the totality of .Net and the JVM. We have yet to fathom how far reaching WASM will be. Did I say WASM enough times? I end with only this. WASM.
    - ZenoArrow 9y ago
      > "In six months, WASM will have had more program launches than the totality of .Net and the JVM." I don't think so. The only languages that can currently target WASM are languages that don't need GC. It'll take a while before the tooling and functionality is mature enough to support the most commonly used languages (aside from C/C++).
    - xaduha 9y ago
      JS didn't take over the world, web did. And if we don't talk plugins, then there wasn't much choice in the matter if you wanted to do things clientside.
therealmarv 9y ago
Is there anywhere a "hello world" or simple DOM modification program which I can implement with WebAssembly?
- remcob 9y ago
  I made this factorial compile-and-run example in NodeJS: https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537c2 https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537... To run it you need at least Node 8.0.0 and the `--expose-wasm` flag. Sorry for using modern JS, you will need to use babel-node to run it. Or you can port it to old fashioned JS.
  - Houshalter 9y ago
    I didn't know you could run wasm from node, awesome.
- readittwice 9y ago
  AFAIK you cannot access the DOM from WebAssembly right now, although it probably will come in future versions. But you can use the WebAssemblyExplorer https://mbebenita.github.io/WasmExplorer/ https://mbebenita.github.io/WasmExplorer/: There is also a nice video about using WebAssemblyExplorer and even uses a simple WebAssembly-Module: https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s
Vinnl 9y ago
I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does deserve a lot of credit here.
- nthcolumn 9y ago
  It is joke - we had 'Chrome won' the other day. There is a hidden point being made which you would probably agree with.
  - chii 9y ago
    i hate how HN now has titles that require knowing previous posts to understand. That's the domain of reddit.
    - xiaoma 9y ago
      I've seen this on HN, going back to at least 2007 or 2008.
      - _delirium 9y ago
        I especially remember that in the first few years of HN there was an expectation that everyone had read Paul Graham's essays and would recognize references to them.
      - smhost 9y ago
        It's almost as if communities have inside jokes or something.
    - vertex-four 9y ago
      I mean, titles referencing previous articles has been a thing for a very long time - see X Considered Harmful as an example.
midnitewarrior 9y ago
Congrats for winning! This does not change Firefox being on its final death throes though. Chrome won where it counts.
- matt4077 9y ago
  Nobody lost. We all "won", because, for the time being, Chrome is important for Google: They need to keep the open web as a platform competitive with Apple's iOS ecosystem, as well as Facebook's walled garden, because Google rules advertising in the first, but not in the latter two. Thus, Google's interests align with the users', and also Mozilla's. It's perfectly possible for this to change when, for example, it becomes lucrative for Google to move people from the open web to android apps. At that point, we should all hope to have Mozilla and others like it still around. It shouldn't be surprising that Google can outcompete any other organisation when it sees something as relevant to the absolute core of its business.
- tommica 9y ago
  And that is a sad thing :( I really hope Firefox comes back with a new push towards better web, and keeps pushing it!
  - ZenoArrow 9y ago
    In terms of usability it's already on a par, it's just a question of waiting for average users to have a strong enough reason to switch. Potential speed improvements from Project Quantum seem like the best hope in the short term.
- baby 9y ago
  tree style tabs
  - ucho 9y ago
    Yeas, what about it? Oh right, it might stop working after Firefox 57: https://github.com/piroor/treestyletab/issues/1224 https://github.com/piroor/treestyletab/issues/1224 . There are people working on it but that isn't true for many other extensions that are no longer under active development.
k__ 9y ago
Is WASM platform independent?
- TazeTSchnitzel 9y ago
  To the extent that asm.js and JavaScript are, yes. Everything is well-defined, so in theory any Turing machine should be able to run it, but it's certainly going to be easier to implement efficiently on a typical modern 32-bit or 64-bit CPU in a computer or phone than on something more unusual.
  - k__ 9y ago
    So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?
    - jonloldrup 9y ago
      yes, but the API you'll code against is limited
      - roca 9y ago
        That's not really true. With JS glue code (including many libraries already written) Wasm modules can access anything JS can do. E.g. there are Wasm demos showing access to WebGL2, audio generation, camera/microphone, HTTP, storage, gamepads, ...
        TazeTSchnitzel 9y ago
        You have the full Web API, yes, but it's limited compared to native, although sure, it's nonetheless very capable.
        camus2 9y ago
        > E.g. there are Wasm demos showing access to WebGL2, audio generation, camera/microphone, HTTP, storage, gamepads, ... All web API. nothing a Javascript app in the browser can't do.
deleted 9y ago
[deleted]
SimonPStevens 9y ago
It's worth pointing out that Mozilla can only continue to put pressure on Google and fight for the open web if people continue to use Firefox and support them. Consider switching to Firefox even if you prefer Chrome. Report websites that don't support FF. We are all better off for the existence of Mozilla, and strong viable competition to Chrome and IE.
- SquareWheel 9y ago
  You make it sound like Mozilla is somehow fighting against Google for the open web. But virtually all browser vendors are aligned on this issue, and have been working towards improving the web through standardization, improved performance, and functionality for years now.
  - sanxiyn 9y ago
    The point of the article is that while Google is mostly aligned on the issue, Google also does things like creating PNaCl, which is not an aligned behavior.
    - SquareWheel 9y ago
      (P)NaCl was introduced to replace NPAPI, at a time when the majority of rich web interaction still happened through plugins. I'm glad to see it killed off, and have been expecting it for a few years now. JS/asm and (hopefully soon) WebAssembly have supplanted many of its features and benefits. Still, this doesn't strike me as anti-open web. Google offered a solution when one was needed - it didn't gain traction, so they eventually retired it.
      - roca 9y ago
        Google introduced PNaCl and made it available as a feature any Web page could use, knowing that there was effectively zero chance it would ever become a cross-browser Web standard. That was anti-open-Web.
  - falcolas 9y ago
TekMol 9y ago
What are the main benefits of WebAssembly over asm.js? I understand that asm.js was a subset of JavaScript that allowed the compiler to create faster code. For example because it could be sure that variable types do not change during runtime. But what do we gain with WebAssembly? Faster download+compilation times? How much faster?
- paulddraper 9y ago
  Yes, faster load times. Also, a more sensible target language.
  - TekMol 9y ago
    How much faster? I would think gzip should even out most of the difference between a text based and a byte based code.
    - sanxiyn 9y ago
      > I would think gzip should even out most of the difference between a text based and a byte based code. You would be wrong then. Quoting Unity https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/ https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-f... "Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x." So WebAssembly is 1.4x smaller, after gzip.
- vanderZwan 9y ago
  A lot. There's a talk by Alex Danilo from Google IO 17 explaining it in detail. Here, I'll link you directly to the part where he starts explaining the differences on a technical level: https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.
deleted 9y ago
[deleted]
ericfrederich 9y ago
WebAssembly and PNaCL always seemed like a hack. A very elegant thought-out hack, but still a hack. It required a 64 bit OS but could only ever operate in 32 bit space. Should have been dead on arrival because of that fact alone. For something that was trying to bring C/C++ and video games into a browser setting a 4GB max on memory should have been a non-starter.
- Vinnl 9y ago
  I'm afraid pretty much every part in the pipeline of getting websites to your computer and shown on screen is a big giant hack of which it's a wonder that it even works at all, most of the time.
  - kibwen 9y ago
    s/getting websites to //
  - ericfrederich 9y ago
    HAHA, you're correct
- Rusky 9y ago
  WebAssembly is unrelated to PNaCl and has no limitations on the bit width of the host OS or the running program. PNaCl has those limitations because of how its sandbox works, but WebAssembly does not use a sandbox at all- it uses Javascript's security model instead. (The WebAssembly MVP only supports the wasm32 target, but wasm64 is also planned.)
ericfrederich 9y ago
It seems there is this effort to get C/C++ code performing fast inside of a browser... then at the same time there seems to be an effort to get people to stop coding in C/C++ altogether and switch to something more memory safe. Go or Rust for example. Also, I watched a talk from DConf and saw that D is adding memory safety as well. You need to mark any part of code doing pointer arithmetic as "system code" or something like that. I think it's a shame one couldn't have happened before the other. I wish something like D or Go or Nim or something else would have won. Then there would be this effort to get that language fast on the browser. Is anything I'm saying making sense? I don't know enough about WebAsm, is it really tied tightly to C or could Go or Rust or some future version of statically typed Python become a first-class citizen?
- sanxiyn 9y ago
  Rust already can compile to WebAssembly. WebAssembly is in no way tied to C, not at all.
- alexanderstocko 9y ago
  Rust and many other languages have WebAssembly targets in the pipeline already. Rust has had a target to play with since last year.
- rwj 9y ago
  It is not about running C/C++, it is about running native code (or something approximating it). With the right backend, most languages should be able to target WebAssembly. The other complication with supporting Go or Rust is that, even if the language is memory safe, the code still needs to be sandboxed.
  - empath75 9y ago
    Gc'd languages will take a while.
    - fasquoika 9y ago
      What does Go's GC need that WebAssembly doesn't have? I understand it might be hard for a language like Java that expects a GC in the VM
johnhattan 9y ago
One of the best things about Flash was that you could pack up all your bytecode and bitmaps and vectors and sounds and fonts into a single compressed SWF file that contained your entire application/game/demo. That made it really easy to do stuff like double-click-able client demos and deliverables for websites. Ditto for Java and JAR files. Looks like the "compressed bytecode that runs really fast" part is now a reality. I'm hoping they'll work on making deliverable packages that are convenient for programmers and users. Anyone know if there is there anything like this in the works?
- chrisweekly 9y ago
  Related tangent: sounds like Zeit.co's `pkg` for Node: https://twitter.com/zeithq/status/858393067241357312 https://twitter.com/zeithq/status/858393067241357312
- rwxsh 9y ago
  https://www.w3.org/TR/web-packaging/ https://www.w3.org/TR/web-packaging/
- roca 9y ago
  You can already do this with existing Web platform APIs; JS libraries for asset streaming and management already exist.
hacker_9 9y ago
WebAssembly will finally put an end to the constant battle between browser vendors as to who has the fastest Javascript Engine. The endless benchmarks about how V8 is faster, or Chakra is faster, or SpiderMonkey is faster, and so on and so on. Hundreds of thousands of millions of man hours have been poured into building the fastest JS parsers imaginable, and now WebAssembly is going to come along and side step the whole thing in one go by moving the parsing stage off of the client. Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in, all because no one stood up and questioned if this language was even a good fit in the first place. In a few years the WebAssembly creators may even win the Noble Peace Prize for finally ending the biggest battle in the never ending "browser war".
- stdbrouw 9y ago
  > Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in If there is absolutely nothing else in this world that you can think of that might be a bigger waste of time than performance optimizations that have benefited billions of users for many years, you're not trying very hard.
- Matthias247 9y ago
  Maybe in a very distant future. In short term most webcontent will still be delivered as Javascript (maybe transpiled from TS & co). WASM will cover some niches, e.g. for running some native applications and games directly in the browser. Or for making some high-performance low-level libraries (which might have a JS API on top). Besides that WASM is also executed by a Javascript Engine, so it's speed still matters.
- flavio81 9y ago
  > Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in, all because no one stood up and questioned if this language was even a good fit in the first place. Javascript, in its current ES2016 version, is a pretty good and powerful language. ES2015 is also fine. The problem is that most JS code out there has been done in the older versions of Javascript (pre-ES2015), which is really a terrible language (doesn't even have clean and clear variable scoping!).
moonfern 9y ago
In 2016 the global games market had $99.6Bn revenue and a 8.5% YoY. PC had a 27% +4.2% market share, TV 29% +4.5% , mobile 27% +23.7% tablets 10% +4.5% and casual webgames 5% -7.5%. (source:Newzoo) Google with it's presence in mobile, tablets and web seems to be the winner, edge will support webassembly in the future and mozilla which is much smaller than opera on mobile reminds me of Xerox.
Touche 9y ago
WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web. Safari and Edge have leapfrogged Firefox in providing the important things to web developers.
- dagw 9y ago
  I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. What follow is speculation: At guess they feel burnt after they lost the whole closed source DRM in the w3c spec battle. They realize that something like WebAssembly will become a thing in the next few years and that if they don't push super hard for a completely open solution from day 1 then they're afraid that Google, Microsoft and Apple will get together in a room and make a deal without them. At the end of the day Mozilla don't only care about delivering a browser, they care about delivering a completely open browser, and they don't want their ability to deliver that to become more threatened in the future.
- jahnu 9y ago
  > useable by 0.01% of applications. I think you will be surprised how many apps will use WASM in the future. I'm a C++ dev and working with WASM (and asm.js as a fallback) full time. It's going to be absolutely huge.
  - Touche 9y ago
    Even if it causes Photoshop and CAD software and such to be ported to the web (which would be a huge business model change, so don't hold your breath) we're still talking about a tiny percentage of apps. There's no reason why Slack would rewrite in C++.
    - jahnu 9y ago
      Not talking about re-writing. But there is an enormous amount of code out there in c, c++ and other langs that people would love to use in web apps. In our case we use the same library code on iOS, Android, Windows and in the browser to do computationally expensive operations. Also, to dismiss productivity apps such as PS and CAD as unimportant is kind of crazy. Huge business model change? They are still an enormous part of the software industry and the browser a great platform for distribution for many cases. Performance and code secrecy being two barriers that WASM solves for them.
alex_duf 9y ago
I wonder if we can do scala native -> llvm -> webassembly. Anyone tried?
frik 9y ago
I can't wait to see ad networks abuse WebAssembly. /s
z3t4 9y ago
Seems like a lot of complexity for very little gain in performance. Optimizing JavaScript often gain 100x performance, and after that rewriting it to Web-assembly would only gain up to 4x performance.
- fixermark 9y ago
  The larger goal is to provide alternatives to compiling to JavaScript. JS is a relatively large, mobile, and ugly target for a compiler relative to tightly-defined bytecode alternatives like LLVM.
- sqeaky 9y ago
  There is a performance upper bound. You can only run instructions as fast as the machine can. Native code can get very close to this limit, in a way that in practice no interpreted or JITed code can. This is just emulating the techniques native code uses to get close to that upper bound in the same way. It is not impossible to make pure JS run this fast, but its not going to happen without herculean effort put into JS runtimes. It is just easier to do it this way, and we get to leave JS, which is a benefit to everyone except people who actually like JS.
- roca 9y ago
  4x performance is worth having for many applications. The other thing is it's not just about performance, but also about running existing and future C/C++/Rust etc code on the Web.
  - z3t4 9y ago
    those C/C++/Rust apps will perform worse on the web and a lot of glue code will be needed.
markdog12 9y ago
Keep in mind nacl/pnacl, as a more mature technology, is ahead of WebAssembly wrt features, such as threads, simd, etc. I know these are coming to WebAssembly, but who knows how long it'll take.
- xemoka 9y ago
  More mature, and soon only available in chrome extensions and apps: https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass... Chromium is refocusing on WebAssembly
  - markdog12 9y ago
    Yep, I'm aware, my point is it's still behind.
Andrex 9y ago
This is just my personal viewpoint with nothing to back it up, but I doubt Google ever seriously wanted other browsers to implement PNaCl. As this post says, it was never specced and Google's big push for it was in Chrome apps on the Chrome Web Store. Also, wasn't asm.js just a subset of JS? This line confuses me: > asm.js and PNaCl represented quite different visions for how C/C++ code should be supported on the Web Yes you could compile C to asm.js, but it would still be compiling it to JS at the end of the day. WebAssembly is completely different in that regard.
- AgentME 9y ago
  >Yes you could compile C to asm.js, but it would still be compiling it to JS at the end of the day. WebAssembly is completely different in that regard. WebAssembly (at least to start with) is mostly intended as a more compact binary encoding of asm.js. It still mostly executes the same way and offers the same APIs as asm.js.
desireco42 9y ago
Which I believe was Brendan Eich initiative. Mozilla without him is just not the same project.
jhpriestley 9y ago
People seem way too optimistic about web assembly. The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that. Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to ship Qt, the python interpreter, low-level graphics rendering code, shims for system calls in the standard library ... overall you'll end up way, way heavier than the javascript + DOM version. Probably 100MB or something. wasm as it's implemented is going to have a very narrow band of usefulness. Basically, isolated computational modules (e.g. a physics simulation), and games. The games won't be, like, "Call of Duty on the web", they'll be little flash-type games with not too many assets. Creators will have to put a lot of effort into asset loading and compression to get around browser limitations.
- dleslie 9y ago
  I don't see the problem. Given an enormous WASM binary one could write a small bootstrap binary that fetches the binary and stores it in local cache. Future updates to the mega-binary can be done with some kind of delta-diff mechanism. Now, let's say you rely on Qt in some manner. Well, likely the WASM package resides at some known URI and is subject to standard browser caching.
  - debacle 9y ago
    Great, you just built Second Life.
- Certhas 9y ago
  We already are getting desktop apps with HTML based UI [1]. A wasm photoshop would cache the download, use a HTML front end, and be written in a compiled language. Sure you'll be able to use the tech to do stupid things like running a python interpreter inside a WebAssembler virtual machine. But then your argument is just that if you use the tech to do stupid things you'll get stupid results. Total straw man. [1] https://electron.atom.io/apps/ https://electron.atom.io/apps/
- 9y ago
diafygi 9y ago
Will there ever be a way to have constant-time functions in WebAssembly? Relying on WebCrypto primitives is fairly limiting.
__name__ 9y ago
Mozilla wins a battle but loses the war

626 points by nachtigall 9y ago

Interesting perspective. I've largely kept out of that fight for many reasons, but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story.

nachtigall 9y ago
> but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story I think looking at Quantum (https://wiki.mozilla.org/Quantum https://wiki.mozilla.org/Quantum) and Phonton (https://www.ghacks.net/2017/03/31/firefox-photon-new-design-mockups-show-interface-and-more/ https://www.ghacks.net/2017/03/31/firefox-photon-new-design-...) this becomes even more clear.
- mrec 9y ago
  I agree that Quantum is exciting, but if there's anything interesting about Photon the article you linked really didn't bring it out. What aspects were you thinking of?
  - H4CK3RM4N 9y ago
    I think it's just used here as an example of Moz://a not aping Chrome, by moving their UI even further away.

tete 9y ago

I think this is a good thing. It probably prevented a new DirectX style dark age of the web. Probably! I don't pretend to be able predict what path companies would have went in the next few years. It's really good to see that there is a will to agree and that there is more than one player. Could always be more, also for keeping standards sane. (WebSQL officially failed because there isn't more variety)

chrisseaton 9y ago
> It probably prevented a new DirectX style dark age of the web. Do you mean ActiveX rather than DirectX? As in the OLE and COM technology for embedding user interface components on Windows?
- tete 9y ago
  Sorry. That was before my coffee. It's indeed what I meant. Thanks!
douche 9y ago
DirectX fostered multiple generations of gaming on PCs. I dunno what you're talking about with referencing it in a web development context, but it was, and still is, miles ahead of dicking around with broken OpenGL.
- ealhad 9y ago
  Well, DirectX fostered multiple generations of gaming on Windows.
- tete 9y ago
  Oops. Meant to write ActiveX.
rubber_duck 9y ago
>It probably prevented a new DirectX style dark age of the web. DirectX was hardly a dark age, DX8 and onwards was a step ahead of GL.
- rocky1138 9y ago
  But tied only to one OS. I believe this is what the OP meant and something I agree with.
- tete 9y ago
  As already was pointed out. I meant to write ActiveX, not DirectX. I don't actually know too much about graphics programming. Stupid mistake from my side. Sorry!

fpoling 9y ago

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAssembly application call-stacks are maintained by the JS VM, outside the memory addressable by the application, which reduces the exploitability of application bugs. (Though, again like asm.js and unlike PNaCl, the compiler is trusted.) ---

dullgiulio 9y ago
I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.
- satysin 9y ago
  I think they are talking about something like the Ken Thompson hack? http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
- roca 9y ago
  It means that a bug in the compiler/optimizer could allow WebAssembly code to escape its sandbox. This is a real issue, but o some extent this extra attack surface is mitigated because vendors are reusing JS compiler backends that are already part of the TCB.
- foxylad 9y ago
  Add extraneous code?
- fpoling 9y ago
  Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.

scriptproof 9y ago

Asm.js was a brillant idea, but wasm is more like a bytecode. This is where is the part from NaCl the author missed. Wasm is derived from asm.js but also an improvement on LLVM to make a portable bytecode, that LLVM is not. One more step in the LLVM toolchain to get portability...

ZenoArrow 9y ago
WASM isn't based on LLVM. WASM is a compiler target, but compilers other than LLVM can target WASM.
- sitkack 9y ago
  And WASM is now the defacto portable Bitcode. Just as JS took over the world, so will WASM. In six months, WASM will have had more program launches than the totality of .Net and the JVM. We have yet to fathom how far reaching WASM will be. Did I say WASM enough times? I end with only this. WASM.
  - ZenoArrow 9y ago
    > "In six months, WASM will have had more program launches than the totality of .Net and the JVM." I don't think so. The only languages that can currently target WASM are languages that don't need GC. It'll take a while before the tooling and functionality is mature enough to support the most commonly used languages (aside from C/C++).
  - xaduha 9y ago
    JS didn't take over the world, web did. And if we don't talk plugins, then there wasn't much choice in the matter if you wanted to do things clientside.

therealmarv 9y ago

Is there anywhere a "hello world" or simple DOM modification program which I can implement with WebAssembly?

remcob 9y ago
I made this factorial compile-and-run example in NodeJS: https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537c2 https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537... To run it you need at least Node 8.0.0 and the `--expose-wasm` flag. Sorry for using modern JS, you will need to use babel-node to run it. Or you can port it to old fashioned JS.
- Houshalter 9y ago
  I didn't know you could run wasm from node, awesome.
readittwice 9y ago
AFAIK you cannot access the DOM from WebAssembly right now, although it probably will come in future versions. But you can use the WebAssemblyExplorer https://mbebenita.github.io/WasmExplorer/ https://mbebenita.github.io/WasmExplorer/: There is also a nice video about using WebAssemblyExplorer and even uses a simple WebAssembly-Module: https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s

Vinnl 9y ago

I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does deserve a lot of credit here.

nthcolumn 9y ago
It is joke - we had 'Chrome won' the other day. There is a hidden point being made which you would probably agree with.
- chii 9y ago
  i hate how HN now has titles that require knowing previous posts to understand. That's the domain of reddit.
  - xiaoma 9y ago
    I've seen this on HN, going back to at least 2007 or 2008.
    - _delirium 9y ago
      I especially remember that in the first few years of HN there was an expectation that everyone had read Paul Graham's essays and would recognize references to them.
    - smhost 9y ago
      It's almost as if communities have inside jokes or something.
  - vertex-four 9y ago
    I mean, titles referencing previous articles has been a thing for a very long time - see X Considered Harmful as an example.

midnitewarrior 9y ago

Congrats for winning! This does not change Firefox being on its final death throes though. Chrome won where it counts.

matt4077 9y ago
Nobody lost. We all "won", because, for the time being, Chrome is important for Google: They need to keep the open web as a platform competitive with Apple's iOS ecosystem, as well as Facebook's walled garden, because Google rules advertising in the first, but not in the latter two. Thus, Google's interests align with the users', and also Mozilla's. It's perfectly possible for this to change when, for example, it becomes lucrative for Google to move people from the open web to android apps. At that point, we should all hope to have Mozilla and others like it still around. It shouldn't be surprising that Google can outcompete any other organisation when it sees something as relevant to the absolute core of its business.
tommica 9y ago
And that is a sad thing :( I really hope Firefox comes back with a new push towards better web, and keeps pushing it!
- ZenoArrow 9y ago
  In terms of usability it's already on a par, it's just a question of waiting for average users to have a strong enough reason to switch. Potential speed improvements from Project Quantum seem like the best hope in the short term.
baby 9y ago
tree style tabs
- ucho 9y ago
  Yeas, what about it? Oh right, it might stop working after Firefox 57: https://github.com/piroor/treestyletab/issues/1224 https://github.com/piroor/treestyletab/issues/1224 . There are people working on it but that isn't true for many other extensions that are no longer under active development.

k__ 9y ago

Is WASM platform independent?

TazeTSchnitzel 9y ago
To the extent that asm.js and JavaScript are, yes. Everything is well-defined, so in theory any Turing machine should be able to run it, but it's certainly going to be easier to implement efficiently on a typical modern 32-bit or 64-bit CPU in a computer or phone than on something more unusual.
- k__ 9y ago
  So I could write an application in, lets say Rust, compile it to WASM and run it on Linux, macOS and Windows browsers without anything extra?
  - jonloldrup 9y ago
    yes, but the API you'll code against is limited
    - roca 9y ago
      That's not really true. With JS glue code (including many libraries already written) Wasm modules can access anything JS can do. E.g. there are Wasm demos showing access to WebGL2, audio generation, camera/microphone, HTTP, storage, gamepads, ...
      - TazeTSchnitzel 9y ago
        You have the full Web API, yes, but it's limited compared to native, although sure, it's nonetheless very capable.
      - camus2 9y ago
        > E.g. there are Wasm demos showing access to WebGL2, audio generation, camera/microphone, HTTP, storage, gamepads, ... All web API. nothing a Javascript app in the browser can't do.

deleted 9y ago

[deleted]

SimonPStevens 9y ago

It's worth pointing out that Mozilla can only continue to put pressure on Google and fight for the open web if people continue to use Firefox and support them. Consider switching to Firefox even if you prefer Chrome. Report websites that don't support FF. We are all better off for the existence of Mozilla, and strong viable competition to Chrome and IE.

SquareWheel 9y ago
You make it sound like Mozilla is somehow fighting against Google for the open web. But virtually all browser vendors are aligned on this issue, and have been working towards improving the web through standardization, improved performance, and functionality for years now.
- sanxiyn 9y ago
  The point of the article is that while Google is mostly aligned on the issue, Google also does things like creating PNaCl, which is not an aligned behavior.
  - SquareWheel 9y ago
    (P)NaCl was introduced to replace NPAPI, at a time when the majority of rich web interaction still happened through plugins. I'm glad to see it killed off, and have been expecting it for a few years now. JS/asm and (hopefully soon) WebAssembly have supplanted many of its features and benefits. Still, this doesn't strike me as anti-open web. Google offered a solution when one was needed - it didn't gain traction, so they eventually retired it.
    - roca 9y ago
      Google introduced PNaCl and made it available as a feature any Web page could use, knowing that there was effectively zero chance it would ever become a cross-browser Web standard. That was anti-open-Web.
- falcolas 9y ago

TekMol 9y ago

What are the main benefits of WebAssembly over asm.js? I understand that asm.js was a subset of JavaScript that allowed the compiler to create faster code. For example because it could be sure that variable types do not change during runtime. But what do we gain with WebAssembly? Faster download+compilation times? How much faster?

paulddraper 9y ago
Yes, faster load times. Also, a more sensible target language.
- TekMol 9y ago
  How much faster? I would think gzip should even out most of the difference between a text based and a byte based code.
  - sanxiyn 9y ago
    > I would think gzip should even out most of the difference between a text based and a byte based code. You would be wrong then. Quoting Unity https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/ https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-f... "Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x." So WebAssembly is 1.4x smaller, after gzip.
vanderZwan 9y ago
A lot. There's a talk by Alex Danilo from Google IO 17 explaining it in detail. Here, I'll link you directly to the part where he starts explaining the differences on a technical level: https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.

deleted 9y ago

[deleted]

ericfrederich 9y ago

WebAssembly and PNaCL always seemed like a hack. A very elegant thought-out hack, but still a hack. It required a 64 bit OS but could only ever operate in 32 bit space. Should have been dead on arrival because of that fact alone. For something that was trying to bring C/C++ and video games into a browser setting a 4GB max on memory should have been a non-starter.

Vinnl 9y ago
I'm afraid pretty much every part in the pipeline of getting websites to your computer and shown on screen is a big giant hack of which it's a wonder that it even works at all, most of the time.
- kibwen 9y ago
  s/getting websites to //
- ericfrederich 9y ago
  HAHA, you're correct
Rusky 9y ago
WebAssembly is unrelated to PNaCl and has no limitations on the bit width of the host OS or the running program. PNaCl has those limitations because of how its sandbox works, but WebAssembly does not use a sandbox at all- it uses Javascript's security model instead. (The WebAssembly MVP only supports the wasm32 target, but wasm64 is also planned.)

ericfrederich 9y ago

It seems there is this effort to get C/C++ code performing fast inside of a browser... then at the same time there seems to be an effort to get people to stop coding in C/C++ altogether and switch to something more memory safe. Go or Rust for example. Also, I watched a talk from DConf and saw that D is adding memory safety as well. You need to mark any part of code doing pointer arithmetic as "system code" or something like that. I think it's a shame one couldn't have happened before the other. I wish something like D or Go or Nim or something else would have won. Then there would be this effort to get that language fast on the browser. Is anything I'm saying making sense? I don't know enough about WebAsm, is it really tied tightly to C or could Go or Rust or some future version of statically typed Python become a first-class citizen?

sanxiyn 9y ago
Rust already can compile to WebAssembly. WebAssembly is in no way tied to C, not at all.
alexanderstocko 9y ago
Rust and many other languages have WebAssembly targets in the pipeline already. Rust has had a target to play with since last year.
rwj 9y ago
It is not about running C/C++, it is about running native code (or something approximating it). With the right backend, most languages should be able to target WebAssembly. The other complication with supporting Go or Rust is that, even if the language is memory safe, the code still needs to be sandboxed.
- empath75 9y ago
  Gc'd languages will take a while.
  - fasquoika 9y ago
    What does Go's GC need that WebAssembly doesn't have? I understand it might be hard for a language like Java that expects a GC in the VM

johnhattan 9y ago

One of the best things about Flash was that you could pack up all your bytecode and bitmaps and vectors and sounds and fonts into a single compressed SWF file that contained your entire application/game/demo. That made it really easy to do stuff like double-click-able client demos and deliverables for websites. Ditto for Java and JAR files. Looks like the "compressed bytecode that runs really fast" part is now a reality. I'm hoping they'll work on making deliverable packages that are convenient for programmers and users. Anyone know if there is there anything like this in the works?

chrisweekly 9y ago
Related tangent: sounds like Zeit.co's `pkg` for Node: https://twitter.com/zeithq/status/858393067241357312 https://twitter.com/zeithq/status/858393067241357312
rwxsh 9y ago
https://www.w3.org/TR/web-packaging/ https://www.w3.org/TR/web-packaging/
roca 9y ago
You can already do this with existing Web platform APIs; JS libraries for asset streaming and management already exist.

hacker_9 9y ago

WebAssembly will finally put an end to the constant battle between browser vendors as to who has the fastest Javascript Engine. The endless benchmarks about how V8 is faster, or Chakra is faster, or SpiderMonkey is faster, and so on and so on. Hundreds of thousands of millions of man hours have been poured into building the fastest JS parsers imaginable, and now WebAssembly is going to come along and side step the whole thing in one go by moving the parsing stage off of the client. Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in, all because no one stood up and questioned if this language was even a good fit in the first place. In a few years the WebAssembly creators may even win the Noble Peace Prize for finally ending the biggest battle in the never ending "browser war".

stdbrouw 9y ago
> Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in If there is absolutely nothing else in this world that you can think of that might be a bigger waste of time than performance optimizations that have benefited billions of users for many years, you're not trying very hard.
Matthias247 9y ago
Maybe in a very distant future. In short term most webcontent will still be delivered as Javascript (maybe transpiled from TS & co). WASM will cover some niches, e.g. for running some native applications and games directly in the browser. Or for making some high-performance low-level libraries (which might have a JS API on top). Besides that WASM is also executed by a Javascript Engine, so it's speed still matters.
flavio81 9y ago
> Javascript parsing technology will go down in history as ultimately the biggest waste of time that mankind ever indulged in, all because no one stood up and questioned if this language was even a good fit in the first place. Javascript, in its current ES2016 version, is a pretty good and powerful language. ES2015 is also fine. The problem is that most JS code out there has been done in the older versions of Javascript (pre-ES2015), which is really a terrible language (doesn't even have clean and clear variable scoping!).

moonfern 9y ago

In 2016 the global games market had $99.6Bn revenue and a 8.5% YoY. PC had a 27% +4.2% market share, TV 29% +4.5% , mobile 27% +23.7% tablets 10% +4.5% and casual webgames 5% -7.5%. (source:Newzoo) Google with it's presence in mobile, tablets and web seems to be the winner, edge will support webassembly in the future and mozilla which is much smaller than opera on mobile reminds me of Xerox.

Touche 9y ago

WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web. Safari and Edge have leapfrogged Firefox in providing the important things to web developers.

dagw 9y ago
I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. What follow is speculation: At guess they feel burnt after they lost the whole closed source DRM in the w3c spec battle. They realize that something like WebAssembly will become a thing in the next few years and that if they don't push super hard for a completely open solution from day 1 then they're afraid that Google, Microsoft and Apple will get together in a room and make a deal without them. At the end of the day Mozilla don't only care about delivering a browser, they care about delivering a completely open browser, and they don't want their ability to deliver that to become more threatened in the future.
jahnu 9y ago
> useable by 0.01% of applications. I think you will be surprised how many apps will use WASM in the future. I'm a C++ dev and working with WASM (and asm.js as a fallback) full time. It's going to be absolutely huge.
- Touche 9y ago
  Even if it causes Photoshop and CAD software and such to be ported to the web (which would be a huge business model change, so don't hold your breath) we're still talking about a tiny percentage of apps. There's no reason why Slack would rewrite in C++.
  - jahnu 9y ago
    Not talking about re-writing. But there is an enormous amount of code out there in c, c++ and other langs that people would love to use in web apps. In our case we use the same library code on iOS, Android, Windows and in the browser to do computationally expensive operations. Also, to dismiss productivity apps such as PS and CAD as unimportant is kind of crazy. Huge business model change? They are still an enormous part of the software industry and the browser a great platform for distribution for many cases. Performance and code secrecy being two barriers that WASM solves for them.

alex_duf 9y ago

I wonder if we can do scala native -> llvm -> webassembly. Anyone tried?

frik 9y ago

I can't wait to see ad networks abuse WebAssembly. /s

z3t4 9y ago

Seems like a lot of complexity for very little gain in performance. Optimizing JavaScript often gain 100x performance, and after that rewriting it to Web-assembly would only gain up to 4x performance.

fixermark 9y ago
The larger goal is to provide alternatives to compiling to JavaScript. JS is a relatively large, mobile, and ugly target for a compiler relative to tightly-defined bytecode alternatives like LLVM.
sqeaky 9y ago
There is a performance upper bound. You can only run instructions as fast as the machine can. Native code can get very close to this limit, in a way that in practice no interpreted or JITed code can. This is just emulating the techniques native code uses to get close to that upper bound in the same way. It is not impossible to make pure JS run this fast, but its not going to happen without herculean effort put into JS runtimes. It is just easier to do it this way, and we get to leave JS, which is a benefit to everyone except people who actually like JS.
roca 9y ago
4x performance is worth having for many applications. The other thing is it's not just about performance, but also about running existing and future C/C++/Rust etc code on the Web.
- z3t4 9y ago
  those C/C++/Rust apps will perform worse on the web and a lot of glue code will be needed.

markdog12 9y ago

Keep in mind nacl/pnacl, as a more mature technology, is ahead of WebAssembly wrt features, such as threads, simd, etc. I know these are coming to WebAssembly, but who knows how long it'll take.

xemoka 9y ago
More mature, and soon only available in chrome extensions and apps: https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass... Chromium is refocusing on WebAssembly
- markdog12 9y ago
  Yep, I'm aware, my point is it's still behind.

Andrex 9y ago

This is just my personal viewpoint with nothing to back it up, but I doubt Google ever seriously wanted other browsers to implement PNaCl. As this post says, it was never specced and Google's big push for it was in Chrome apps on the Chrome Web Store. Also, wasn't asm.js just a subset of JS? This line confuses me: > asm.js and PNaCl represented quite different visions for how C/C++ code should be supported on the Web Yes you could compile C to asm.js, but it would still be compiling it to JS at the end of the day. WebAssembly is completely different in that regard.

AgentME 9y ago
>Yes you could compile C to asm.js, but it would still be compiling it to JS at the end of the day. WebAssembly is completely different in that regard. WebAssembly (at least to start with) is mostly intended as a more compact binary encoding of asm.js. It still mostly executes the same way and offers the same APIs as asm.js.

desireco42 9y ago

Which I believe was Brendan Eich initiative. Mozilla without him is just not the same project.

jhpriestley 9y ago

People seem way too optimistic about web assembly. The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that. Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to ship Qt, the python interpreter, low-level graphics rendering code, shims for system calls in the standard library ... overall you'll end up way, way heavier than the javascript + DOM version. Probably 100MB or something. wasm as it's implemented is going to have a very narrow band of usefulness. Basically, isolated computational modules (e.g. a physics simulation), and games. The games won't be, like, "Call of Duty on the web", they'll be little flash-type games with not too many assets. Creators will have to put a lot of effort into asset loading and compression to get around browser limitations.

dleslie 9y ago
I don't see the problem. Given an enormous WASM binary one could write a small bootstrap binary that fetches the binary and stores it in local cache. Future updates to the mega-binary can be done with some kind of delta-diff mechanism. Now, let's say you rely on Qt in some manner. Well, likely the WASM package resides at some known URI and is subject to standard browser caching.
- debacle 9y ago
  Great, you just built Second Life.
Certhas 9y ago
We already are getting desktop apps with HTML based UI [1]. A wasm photoshop would cache the download, use a HTML front end, and be written in a compiled language. Sure you'll be able to use the tech to do stupid things like running a python interpreter inside a WebAssembler virtual machine. But then your argument is just that if you use the tech to do stupid things you'll get stupid results. Total straw man. [1] https://electron.atom.io/apps/ https://electron.atom.io/apps/
9y ago

diafygi 9y ago

Will there ever be a way to have constant-time functions in WebAssembly? Relying on WebCrypto primitives is fairly limiting.

__name__ 9y ago

Mozilla wins a battle but loses the war