20 ms·

WebAssembly becomes a W3C Recommendation

434 points by galaxyLogic 7y ago

penetrarthur 7y ago
B-B-B-B-Blazor.
BoumTAC 7y ago
Why does the testimonial contains only Chinese company? I think it's really great but it would be better to have company from all around the world
- mcs_ 7y ago
  I'm not from China, from my perspective, those companies are from around the world.
  - thaumasiotes 7y ago
    ...really? From my perspective, it's a bunch of companies that are known only for operating within China (360 / Alibaba / Baidu / Tencent), two hardware companies best known for being Chinese (Huawei / Xiaomi), and one I've never heard of (agora.io). Over half of the testimonials are in Chinese. I'm curious too - was there really no non-Chinese company that would endorse this?
    - mcs_ 7y ago
      Well, apparently this was a real question. W3C members are visible here: https://www.w3.org/Consortium/Member/List https://www.w3.org/Consortium/Member/List Those are the members that decided that WebAssembly is now an official web standard, not the testimonials. I'm investigating more about the voting system here, https://www.w3.org/Consortium/Process/ERB.html https://www.w3.org/Consortium/Process/ERB.html.
      - domenicd 7y ago
        The voting system is roughly: any paying member company can submit a "formal objection", which will be considered by W3C management ("on behalf of" Tim Berners-Lee). If upheld by management then the recommendation doesn't go forward. (This is very rare; I don't know of any instances off the top of my head.)
- zmzrr 7y ago
  Would I be reading this if it was only American companies?
  - efdee 7y ago
    America is not China.
    - zmzrr 7y ago
      Are you sure? For instance, they are two countries, whose names end with the letter "A"... dare I continue?
      - dang 7y ago
        Can you please cut out the lower/boring segment of trolling? (like this and https://news.ycombinator.com/item?id=21804133 https://news.ycombinator.com/item?id=21804133)
    - efdee 7y ago
      Shocked by the downvotes, to be honest.
  - dubcanada 7y ago
    No, probably not. I think it's just a little shocking as it kind of makes it seem like nobody outside of China supports WebAssembly. I think having a wide variety of companies from open source "pro web" to Google and Alibaba might be better then having a pile of extremely wealthy firewall supporting companies.
  - jjeaff 7y ago
    No, because several different American companies would represent several differing viewpoints. A bunch of Chinese companies is essentially the viewpoint of the current dictator of China, should he choose to weigh in.
- faitswulff 7y ago
  Maybe they're just the earliest adopters.
- ConcernedCoder 7y ago
  That struck me as wierd too, then it got me thinking about the 'great wall' and China's ability to insert tracking ( or other ) JavaScript into a user's session... and then how that's going to be different now in the age of web assembly... I can imagine it would make obfuscation of intent easier for one thing.
- vdnkh 7y ago
  The Twitch player is written in WASM, but I don't think we're a W3C member.
gdxhyrd 7y ago
Good to hear it is making progress, but last time I looked, the docs were all over the place and many were outdated...
- todd3834 7y ago
  I expect standardization to help with that.
fizixer 7y ago
Is it safe to say, future frameworks/websites can choose to stick to HTML/CSS/WA and completely bypass JS?
- gdxhyrd 7y ago
  Yes, but in the far future. There are many things to be done in the standard, in the implementations, in the frameworks...
- zamalek 7y ago
  It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself). I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.
  - Jasper_ 7y ago
    The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types https://github.com/webassembly/interface-types
    - weberc2 7y ago
      I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it. Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!
eb0la 7y ago
Another nail in the Java coffin? I hope if doensn't refuse to die (again)
- marcosdumay 7y ago
  I don't think Java is a great language, but killing at this time would destroy a lot of value. Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.
- spullara 7y ago
  Don't you mean JavaScript? This will have 0 effect on Java at this point since it isn't used in the browser anymore.
  - lmkg 7y ago
    WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.
    - somurzakov 7y ago
      some of the compute workload still needs to be on a backend because of security concerns. if you offload too much stuff on a client-side, then any hacker can mess with it and break your system. for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
      - sho_hn 7y ago
        Parent meant WASM on the server.
      - woodrowbarlow 7y ago
        the backend could compile to wasm as well.
Boulth 7y ago
Is this the same case as with HTML5 that W3C takes what WHATWG creates, stamps their "approval" and then it's the W3C that "brings new language to the Web"? Could someone in the know shed some light in this matter?
- dmitriid 7y ago
  It looks like w3c is just late with the announcement. From https://webassembly.org https://webassembly.org: --- quote --- Developer reference documentation for Wasm can be found on MDN's WebAssembly pages. The open standards for WebAssembly are developed in a W3C Community Group (that includes representatives from all major browsers) as well as a W3C Working Group. --- end quote ---
  - nerdponx 7y ago
    Off-topic, but I wish Markdown had a proper "multi line" block quote syntax like this. The current standard of ">" is open to too much interpretation around paragraph breaks. Similar to how fenced code blocks with ``` are a major improvement over prefixing the line with 4 spaces.
    - vanderZwan 7y ago
      The difference between code blocks and block quotes is that you can nest the latter. On the one hand that makes multi-line syntax even more useful. On the other it would make reading block quotes hard to follow when reading MD in plain text (then again, who still does that these days?)
    - thaumasiotes 7y ago
      In Markdown you can generally produce a single block quote with paragraph breaks by including quoted empty lines: > Paragraph 1 > > Paragraph 2 Whereas you'd get two sequential quote blocks by using an unquoted empty line: > Quote 1 > Quote 2
      - infogulch 7y ago
LessDmesg 7y ago
Now if only we get a good web-oriented Python with a WASM backend, we'll finally be able to throw Javascript where it belongs: into the dustbin of history.
- janpot 7y ago
  Honest question, in what sense is python a so much better choice for web development? syntax? subjective, and it would also mean all C-likes belong in the dustbin. performance? Why would python, as a language, be significantly more performant? It's just as dynamic. ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better) I mean I can surely imagine there's better alternatives for JS, as a language. But python...?
  - ShakataGaNai 7y ago
    Not Op, but I'd like to do python/WASM because I don't do want to do C-Like languages. Sometimes you want to do some light web interactivity without major mental context switching. For me, personally, it's a lot of effort to switch between languages. So when I'm building a web project and most of it is django/flask/python/etc, but I want something more dynamic than a HTML form post/browser reload... I need to do it in Javascript. Not that I can't javascript, I can, it's just hard to change over and I'm slow to write it. It would be a whole bunch nicer if I could just stay in the python mindset for those small pieces of code. Do I think python is "better" for the web? No. do I think it's faster? Doubt it. Do I think it's "better" for my use cases? Yes - And that's the power of WASM. It allows people to do what works for them.
  - LessDmesg 7y ago
    For one thing, not being broken. Python doesn't have ("1"+1) and similar design flaws, Python doesn't need a new ECMAscript standard every year, Python has figured out modules and classes much earlier, and frankly, Python is what Javascript is only becoming after years of improvement. Really, I don't understand why we and the browser maintainers have to put up with a broken, insane language when there is a similar but much more mature and "done right" one. And as far as ecosystem, Python can kick Javascript's ass if not in quantity (though it's close) then in quality of its userbase for sure. And Python has been used onе the backend much more than JS, so it makes much more sense to unify the language and just use Python for the front-end.
kemonocode 7y ago
It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- chubot 7y ago
  Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs). That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it). If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making. And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that. Also the JVM ran in the browser, etc. [1] https://news.ycombinator.com/item?id=21618323 https://news.ycombinator.com/item?id=21618323
  - vanderZwan 7y ago
    > If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
    - thaumasiotes 7y ago
      "The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
      - jchw 7y ago
duxup 7y ago
I wonder if people think work involving web assembly will coalesce around a few languages over time?
- diegoperini 7y ago
  LLVM kinda proved having a common target back-end doesn't kill language diversity, it actually achieves the opposite.
  - adrianmonk 7y ago
    One could still ask the question, though. The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language. Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?
    - int_19h 7y ago
      Likely the ones that are on the bandwagon early. To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes. So, I'd say that Rust will probably be the biggest beneficiary.
      - snak 7y ago
        C#/.NET will be in that bandwagon. They have been pushing WebAssembly usage with their Blazor framework.
      - adrianmonk 7y ago
        The performance angle is interesting. Right now JS has lots of mindshare and momentum for obvious reasons, so maybe the things that will take off at first are the ones that help web developers in specific areas where JS performance is not good enough, perhaps graphics for example.
somurzakov 7y ago
i wonder what are the security implications. how many new vulnerabilities will be uncovered, machines infected, and viruses implemented in wasm. the concept of wasm doesn't really fly with zero-trust internet
- yzmtf2008 7y ago
  > if any website can load a javascript that loads wasm code that does whatever Any website can already do that with asm.js. WASM does not change the security model of browsers.
- weberc2 7y ago
  Can you elaborate? I would think the sandbox nature of wasm would be a better fit than other models, and presumably no worse than JavaScript?
  - somurzakov 7y ago
    i am not convinced that wasm interpreter will be bug/vulnerability free. as it was the case for every new piece of software there will be ton of vulnerabilties in the VM itself that will be exploited
kllrnohj 7y ago
Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...
- pteredactyl 7y ago
  Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.
  - thefounder 7y ago
    Yeah, we should all write js on the web and cobol on the server. Think about how good cobol could have become.
  - weberc2 7y ago
    WASM isn’t very practical yet because it isn’t fully formed. There isn’t support for DOM access or parallelism, never mind the ecosystem. It’s a really ambitious project, and writing it off as “locus of JS hate” because it hasn’t completely changed the game in such a short time frame is really short sighted. It would be a fairer test to give it 5 years.
    - pteredactyl 7y ago
      I'm not writing it off. I think it's a good idea to bring more options to the web. I tried it last year, but as you state and I agree, it's not ready yet. In my experience in SF I encounter many never-JSers. Being a JS fan, for certain things, I don't get the hate. So maybe I feel threatened in a way, but I'm not going around wishing for the death of python or Haskell. That's all. I am reading random internet commenters and getting slightly upset. That's on me.
      - weberc2 7y ago
pteredactyl 7y ago
Such hate for JavaScript. To say JS needs to lose for you to win says more about you than it does JS. Just a thought. I see a world where there are many winners and one where WASM and JS and whatever you want can fulfill their need where needed.
- weberc2 7y ago
  This seems like a straw man; I’ve seen relatively little JS hate in this thread. Unless you’re considering WASM’s progress (or existence) to be an attack on JS? I personally don’t see what is wrong with having other choices for web development.
  - pteredactyl 7y ago
    Yea maybe I see this because I feel threatened in some way. Not desirable!
Endy 7y ago
Well, I was already pretty much ignoring the W3C already since HTML5. Now I can really let go, which will put me back to HTML 3.0 with no CSS nonsense.
jokoon 7y ago
Not to complain about WASM because it's great, but it certainly needs more compilers and toolchains, and it should be possible to make webgl calls directly. Toolchains like clang and g++ should be able to generate WASM directly, I don't understand why you need so many things like bynaryen to make a WASM file. Having tools is essential if you want a technology to progress towards adoption. EDIT: actually clang can now generate WASM. I'm not curious how feasible it would be to package python with WASM
c-smile 7y ago
Some retrospective ... Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times. WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way. WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist. Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly. To say in CSS: my-component { behavior: my-native-event-handler url(controllers/my-controller.class); flow: my-native-layout-manager; }
- nine_k 7y ago
  JVM is seriously more complex and heavier-weight. It does too much, and is shaped by Java the language too much (no functions, only objects!). It brings in mandatory GC. It's built around shared mutable data. WA is much smaller, assumes way less, is isolated from DOM and JS code way better, communicates with them via message-passing. It has a smaller attack surface, and less room to screw up in the implementation. Yes, I think not having WA married to DOM is a good idea from many angles. One of them is security, of course. Another is wider applicability: a WA VM could be useful outside the browser, and it already is.

434 points by galaxyLogic 7y ago

B-B-B-B-Blazor.

Why does the testimonial contains only Chinese company? I think it's really great but it would be better to have company from all around the world

mcs_ 7y ago
I'm not from China, from my perspective, those companies are from around the world.
- thaumasiotes 7y ago
  ...really? From my perspective, it's a bunch of companies that are known only for operating within China (360 / Alibaba / Baidu / Tencent), two hardware companies best known for being Chinese (Huawei / Xiaomi), and one I've never heard of (agora.io). Over half of the testimonials are in Chinese. I'm curious too - was there really no non-Chinese company that would endorse this?
  - mcs_ 7y ago
    Well, apparently this was a real question. W3C members are visible here: https://www.w3.org/Consortium/Member/List https://www.w3.org/Consortium/Member/List Those are the members that decided that WebAssembly is now an official web standard, not the testimonials. I'm investigating more about the voting system here, https://www.w3.org/Consortium/Process/ERB.html https://www.w3.org/Consortium/Process/ERB.html.
    - domenicd 7y ago
      The voting system is roughly: any paying member company can submit a "formal objection", which will be considered by W3C management ("on behalf of" Tim Berners-Lee). If upheld by management then the recommendation doesn't go forward. (This is very rare; I don't know of any instances off the top of my head.)
zmzrr 7y ago
Would I be reading this if it was only American companies?
- efdee 7y ago
  America is not China.
  - zmzrr 7y ago
    Are you sure? For instance, they are two countries, whose names end with the letter "A"... dare I continue?
    - dang 7y ago
      Can you please cut out the lower/boring segment of trolling? (like this and https://news.ycombinator.com/item?id=21804133 https://news.ycombinator.com/item?id=21804133)
  - efdee 7y ago
    Shocked by the downvotes, to be honest.
- dubcanada 7y ago
  No, probably not. I think it's just a little shocking as it kind of makes it seem like nobody outside of China supports WebAssembly. I think having a wide variety of companies from open source "pro web" to Google and Alibaba might be better then having a pile of extremely wealthy firewall supporting companies.
- jjeaff 7y ago
  No, because several different American companies would represent several differing viewpoints. A bunch of Chinese companies is essentially the viewpoint of the current dictator of China, should he choose to weigh in.
faitswulff 7y ago
Maybe they're just the earliest adopters.
ConcernedCoder 7y ago
That struck me as wierd too, then it got me thinking about the 'great wall' and China's ability to insert tracking ( or other ) JavaScript into a user's session... and then how that's going to be different now in the age of web assembly... I can imagine it would make obfuscation of intent easier for one thing.
vdnkh 7y ago
The Twitch player is written in WASM, but I don't think we're a W3C member.

gdxhyrd 7y ago

Good to hear it is making progress, but last time I looked, the docs were all over the place and many were outdated...

todd3834 7y ago
I expect standardization to help with that.

fizixer 7y ago

Is it safe to say, future frameworks/websites can choose to stick to HTML/CSS/WA and completely bypass JS?

gdxhyrd 7y ago
Yes, but in the far future. There are many things to be done in the standard, in the implementations, in the frameworks...
zamalek 7y ago
It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself). I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.
- Jasper_ 7y ago
  The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types https://github.com/webassembly/interface-types
  - weberc2 7y ago
    I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it. Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!

eb0la 7y ago

Another nail in the Java coffin? I hope if doensn't refuse to die (again)

marcosdumay 7y ago
I don't think Java is a great language, but killing at this time would destroy a lot of value. Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.
spullara 7y ago
Don't you mean JavaScript? This will have 0 effect on Java at this point since it isn't used in the browser anymore.
- lmkg 7y ago
  WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.
  - somurzakov 7y ago
    some of the compute workload still needs to be on a backend because of security concerns. if you offload too much stuff on a client-side, then any hacker can mess with it and break your system. for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
    - sho_hn 7y ago
      Parent meant WASM on the server.
    - woodrowbarlow 7y ago
      the backend could compile to wasm as well.

Boulth 7y ago

Is this the same case as with HTML5 that W3C takes what WHATWG creates, stamps their "approval" and then it's the W3C that "brings new language to the Web"? Could someone in the know shed some light in this matter?

dmitriid 7y ago
It looks like w3c is just late with the announcement. From https://webassembly.org https://webassembly.org: --- quote --- Developer reference documentation for Wasm can be found on MDN's WebAssembly pages. The open standards for WebAssembly are developed in a W3C Community Group (that includes representatives from all major browsers) as well as a W3C Working Group. --- end quote ---
- nerdponx 7y ago
  Off-topic, but I wish Markdown had a proper "multi line" block quote syntax like this. The current standard of ">" is open to too much interpretation around paragraph breaks. Similar to how fenced code blocks with ``` are a major improvement over prefixing the line with 4 spaces.
  - vanderZwan 7y ago
    The difference between code blocks and block quotes is that you can nest the latter. On the one hand that makes multi-line syntax even more useful. On the other it would make reading block quotes hard to follow when reading MD in plain text (then again, who still does that these days?)
  - thaumasiotes 7y ago
    In Markdown you can generally produce a single block quote with paragraph breaks by including quoted empty lines: > Paragraph 1 > > Paragraph 2 Whereas you'd get two sequential quote blocks by using an unquoted empty line: > Quote 1 > Quote 2
    - infogulch 7y ago

LessDmesg 7y ago

Now if only we get a good web-oriented Python with a WASM backend, we'll finally be able to throw Javascript where it belongs: into the dustbin of history.

janpot 7y ago
Honest question, in what sense is python a so much better choice for web development? syntax? subjective, and it would also mean all C-likes belong in the dustbin. performance? Why would python, as a language, be significantly more performant? It's just as dynamic. ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better) I mean I can surely imagine there's better alternatives for JS, as a language. But python...?
- ShakataGaNai 7y ago
  Not Op, but I'd like to do python/WASM because I don't do want to do C-Like languages. Sometimes you want to do some light web interactivity without major mental context switching. For me, personally, it's a lot of effort to switch between languages. So when I'm building a web project and most of it is django/flask/python/etc, but I want something more dynamic than a HTML form post/browser reload... I need to do it in Javascript. Not that I can't javascript, I can, it's just hard to change over and I'm slow to write it. It would be a whole bunch nicer if I could just stay in the python mindset for those small pieces of code. Do I think python is "better" for the web? No. do I think it's faster? Doubt it. Do I think it's "better" for my use cases? Yes - And that's the power of WASM. It allows people to do what works for them.
- LessDmesg 7y ago
  For one thing, not being broken. Python doesn't have ("1"+1) and similar design flaws, Python doesn't need a new ECMAscript standard every year, Python has figured out modules and classes much earlier, and frankly, Python is what Javascript is only becoming after years of improvement. Really, I don't understand why we and the browser maintainers have to put up with a broken, insane language when there is a similar but much more mature and "done right" one. And as far as ecosystem, Python can kick Javascript's ass if not in quantity (though it's close) then in quality of its userbase for sure. And Python has been used onе the backend much more than JS, so it makes much more sense to unify the language and just use Python for the front-end.

kemonocode 7y ago

It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

chubot 7y ago
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs). That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it). If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making. And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that. Also the JVM ran in the browser, etc. [1] https://news.ycombinator.com/item?id=21618323 https://news.ycombinator.com/item?id=21618323
- vanderZwan 7y ago
  > If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
  - thaumasiotes 7y ago
    "The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
    - jchw 7y ago

duxup 7y ago

I wonder if people think work involving web assembly will coalesce around a few languages over time?

diegoperini 7y ago
LLVM kinda proved having a common target back-end doesn't kill language diversity, it actually achieves the opposite.
- adrianmonk 7y ago
  One could still ask the question, though. The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language. Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?
  - int_19h 7y ago
    Likely the ones that are on the bandwagon early. To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes. So, I'd say that Rust will probably be the biggest beneficiary.
    - snak 7y ago
      C#/.NET will be in that bandwagon. They have been pushing WebAssembly usage with their Blazor framework.
    - adrianmonk 7y ago
      The performance angle is interesting. Right now JS has lots of mindshare and momentum for obvious reasons, so maybe the things that will take off at first are the ones that help web developers in specific areas where JS performance is not good enough, perhaps graphics for example.

somurzakov 7y ago

i wonder what are the security implications. how many new vulnerabilities will be uncovered, machines infected, and viruses implemented in wasm. the concept of wasm doesn't really fly with zero-trust internet

yzmtf2008 7y ago
> if any website can load a javascript that loads wasm code that does whatever Any website can already do that with asm.js. WASM does not change the security model of browsers.
weberc2 7y ago
Can you elaborate? I would think the sandbox nature of wasm would be a better fit than other models, and presumably no worse than JavaScript?
- somurzakov 7y ago
  i am not convinced that wasm interpreter will be bug/vulnerability free. as it was the case for every new piece of software there will be ton of vulnerabilties in the VM itself that will be exploited

kllrnohj 7y ago

Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...

pteredactyl 7y ago
Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.
- thefounder 7y ago
  Yeah, we should all write js on the web and cobol on the server. Think about how good cobol could have become.
- weberc2 7y ago
  WASM isn’t very practical yet because it isn’t fully formed. There isn’t support for DOM access or parallelism, never mind the ecosystem. It’s a really ambitious project, and writing it off as “locus of JS hate” because it hasn’t completely changed the game in such a short time frame is really short sighted. It would be a fairer test to give it 5 years.
  - pteredactyl 7y ago
    I'm not writing it off. I think it's a good idea to bring more options to the web. I tried it last year, but as you state and I agree, it's not ready yet. In my experience in SF I encounter many never-JSers. Being a JS fan, for certain things, I don't get the hate. So maybe I feel threatened in a way, but I'm not going around wishing for the death of python or Haskell. That's all. I am reading random internet commenters and getting slightly upset. That's on me.
    - weberc2 7y ago

pteredactyl 7y ago

Such hate for JavaScript. To say JS needs to lose for you to win says more about you than it does JS. Just a thought. I see a world where there are many winners and one where WASM and JS and whatever you want can fulfill their need where needed.

weberc2 7y ago
This seems like a straw man; I’ve seen relatively little JS hate in this thread. Unless you’re considering WASM’s progress (or existence) to be an attack on JS? I personally don’t see what is wrong with having other choices for web development.
- pteredactyl 7y ago
  Yea maybe I see this because I feel threatened in some way. Not desirable!

Endy 7y ago

Well, I was already pretty much ignoring the W3C already since HTML5. Now I can really let go, which will put me back to HTML 3.0 with no CSS nonsense.

jokoon 7y ago

Not to complain about WASM because it's great, but it certainly needs more compilers and toolchains, and it should be possible to make webgl calls directly. Toolchains like clang and g++ should be able to generate WASM directly, I don't understand why you need so many things like bynaryen to make a WASM file. Having tools is essential if you want a technology to progress towards adoption. EDIT: actually clang can now generate WASM. I'm not curious how feasible it would be to package python with WASM

c-smile 7y ago

Some retrospective ... Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times. WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way. WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist. Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly. To say in CSS: my-component { behavior: my-native-event-handler url(controllers/my-controller.class); flow: my-native-layout-manager; }

nine_k 7y ago
JVM is seriously more complex and heavier-weight. It does too much, and is shaped by Java the language too much (no functions, only objects!). It brings in mandatory GC. It's built around shared mutable data. WA is much smaller, assumes way less, is isolated from DOM and JS code way better, communicates with them via message-passing. It has a smaller attack surface, and less room to screw up in the implementation. Yes, I think not having WA married to DOM is a good idea from many angles. One of them is security, of course. Another is wider applicability: a WA VM could be useful outside the browser, and it already is.