10 ms·

WASM itself isn't Java, Flash, or Silverlight, but isnt it another step in the ongoing multiyear process of replicating the features of those technologies in a

WASM itself isn't Java, Flash, or Silverlight, but isnt it another step in the ongoing multiyear process of replicating the features of those technologies in a way that they tried to accomplish: compile to one format and run it on multiple platforms? I think so, and the managers at Adobe and Sun must be kicking themselves for not somehow getting their runtime more open, modular, and standardized now that we see write once run anywhere with a few system hooks is all we need. Then again... It was a different world in the mid 2000s. The web standardization process? Ha, what was that? On a side note, I'm seeing more articles pointing out that WASM runs in the JS VM. Doesn't negate the whole advantage of speed for WASM?

rusk 8y ago
I think it's a step forward in that it's more integrated into the platform. Remember when TCP/IP used to be an add-on for an operating system? > managers at Adobe and Sun must be kicking themselves Both tried. As I recall Sun were blocked by Microsoft, and Flash was bundled as standard with Netscape from about 2001 onwards. Steve Jobs killed that stone-dead when he point-blank refused to support it on iDevices.
- zaarn 8y ago
  Flash on Mobiles was two sides, Adobe had a lot of difficulty to implement multi-touch correctly.
- wlesieutre 8y ago
  If the Mac version hadn’t been a crashy dumpster fire, Steve Jobs might not have done that. Flash on Macs was always mediocre.
  - rusk 8y ago
    By blocking flash apps he increased the motivation for migration to native apps, so there was a sound commercial basis for this as well.
  - Dolanator11 8y ago
    Macs have always been throttled frying pans. They sacrifice much performance for the sake of thinness and design. No wonder Flash always performed badly on mac devices.
    - rusk 8y ago
      Not always. They were great little machines 10 or so years ago.
    - SmellyGeekBoy 8y ago
      Nope. The current "form over function" mentality is definitely a post-Jobs and post-Flash thing.
    - wlesieutre 8y ago
      You did see that the recent MBP throttling issue was a software bug and has been fixed, yes? Admittedly they could be clocked slightly higher if they were larger with better cooling, but they're by no means slow computers.
- Ari_Ugwu 8y ago
  Some companies have all the right ideas and for whatever reason still can't execute. Adobe AIR beat things like Electron and PhoneGap to market by years. IMHO the issue with Adobe is this insistence on 'open' still having various vary opinionated elements. Adobe Air for example had a lot of good ideas but still attempted to evangelize Flash and ActionScript. I _think_ MS is trying to pivot of that grave now with .NET Core. Time will tell if the Mono-to-Wasm or .NET Core Native projects have legs. I was so very excited about Adobe Air and wrote a production application with it in 2009. I _think_ a sweet spot for WASM data processing. The data visualization space should explode once I can with data in the browser at near native speed. https://en.wikipedia.org/wiki/Adobe_AIR https://en.wikipedia.org/wiki/Adobe_AIR
  - rusk 8y ago
    I remember trying to do stuff with Adobe AIR and it just felt like a collosal waste of time. As soon as you tried to do anything that interacted outside of their sandbox you were severely limited. I remember some guys did a hack called cairngorm that I looked at but it seemed quite cumbersome. Then there was support, I think it was only after a few years they just gave up and spun it off to Apache ... you need to stick at it longer than that to establish yourself ...
  - Yoric 8y ago
    To be fair, AIR was not the first in the domain. Mozilla had XUL/XULRunner ~15 years ago, which could be used to quickly develop kick-ass cross-platform applications in JS (and is still, by and large, the base of Thunderbird and Firefox). Sun thought that they had something like that with Java Apps ~20 years ago, except they forgot to make installation and UX compelling, and the memory requirements were unacceptable for the time.
  - vturner 8y ago
    Remember when Adobe AIR was going to come to Android? That would have been an amazing write once run anywhere experience.
    - pjmlp 8y ago
wffurr 8y ago
No, wasm, like asmjs, is designed to be compiled into native code once validated. Unlike asmjs, it doesn't also require a long parsing step. It uses the same code paths used to emit native code from the JS VM JIT.
deleted 8y ago
[deleted]
Yoric 8y ago
> On a side note, I'm seeing more articles pointing out that WASM runs in the JS VM. Doesn't negate the whole advantage of speed for WASM? It basically means that WASM has the same safety/security model as the JS VM. Just like JS, it is compiled to native code (I'm simplifying a bit, of course) before being executed. However, where JS is one of the languages with the most complicated semantics around, which makes it really, really hard to compile efficiently, WASM has extremely simple semantics and is designed to be really, really easy to compile efficiently.
- vturner 8y ago
  Thanks for the differentiation. I guess when I've read "WASM" will be native code I expect it to be as in "C" or "C++" native. Not native to a VM
  - Sean1708 8y ago
    WASM and JS are both JIT compiled in all major browsers which means that they compile to the same kind of native code that C and C++ do, they just do so as the program is running rather than in advance.
    - Andrex 8y ago
      What's even better about WASM than JS in this case is that it can be compiled as it is being loaded. With JS, the entire file needs to be downloaded before being executed, but that's not the case for WASM, resulting in even more performance improvements. https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
clouddrover 8y ago
> Doesn't negate the whole advantage of speed for WASM? Well, here's a benchmark of asm.js JavaScript versus WebAssembly in a real world application: https://pspdfkit.com/blog/2018/a-real-world-webassembly-benchmark/ https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc... The WebAssembly version outperforms the asm.js version.
- vturner 8y ago
  If I'm not mistaken, in those plots lower is better. Only WASM on FF has a clear lead?
hinkley 8y ago
It’s bootstrapping. You’re building a new thing (example: C++) that works a lot like the old thing (C). So you build a wrapper (Charm) that works on top of the old thing so you can get the conversation going, expand your capabilities and recruit. Over time you do more of your own thing and you or someone else splits these two pieces of code into three smaller ones. Like the LLVM backend that can be fed by a C or C++ frontend. As webasm becomes a competitive advantage you should expect to see people split up their javascript VM into three pieces, and Javascript and Webassembly running as peers instead of guest and host. In a very small way, we kind of saw a similar thing with JSON. JSON was just a strict subset of Javascript and you could emulate it on old browsers with a linter in front of an eval(). Now it’s its own thing.
marcosdumay 8y ago
> I'm seeing more articles pointing out that WASM runs in the JS VM. It runs on the JS sandbox, but it can not be efficiently emulated by the JS CPU. VM is an ambiguous term. Browser developers are talking about running JS in the Wasm VM. That will probably be reasonable very soon.

rusk 8y ago

I think it's a step forward in that it's more integrated into the platform. Remember when TCP/IP used to be an add-on for an operating system? > managers at Adobe and Sun must be kicking themselves Both tried. As I recall Sun were blocked by Microsoft, and Flash was bundled as standard with Netscape from about 2001 onwards. Steve Jobs killed that stone-dead when he point-blank refused to support it on iDevices.

zaarn 8y ago
Flash on Mobiles was two sides, Adobe had a lot of difficulty to implement multi-touch correctly.
wlesieutre 8y ago
If the Mac version hadn’t been a crashy dumpster fire, Steve Jobs might not have done that. Flash on Macs was always mediocre.
- rusk 8y ago
  By blocking flash apps he increased the motivation for migration to native apps, so there was a sound commercial basis for this as well.
- Dolanator11 8y ago
  Macs have always been throttled frying pans. They sacrifice much performance for the sake of thinness and design. No wonder Flash always performed badly on mac devices.
  - rusk 8y ago
    Not always. They were great little machines 10 or so years ago.
  - SmellyGeekBoy 8y ago
    Nope. The current "form over function" mentality is definitely a post-Jobs and post-Flash thing.
  - wlesieutre 8y ago
    You did see that the recent MBP throttling issue was a software bug and has been fixed, yes? Admittedly they could be clocked slightly higher if they were larger with better cooling, but they're by no means slow computers.
Ari_Ugwu 8y ago
Some companies have all the right ideas and for whatever reason still can't execute. Adobe AIR beat things like Electron and PhoneGap to market by years. IMHO the issue with Adobe is this insistence on 'open' still having various vary opinionated elements. Adobe Air for example had a lot of good ideas but still attempted to evangelize Flash and ActionScript. I _think_ MS is trying to pivot of that grave now with .NET Core. Time will tell if the Mono-to-Wasm or .NET Core Native projects have legs. I was so very excited about Adobe Air and wrote a production application with it in 2009. I _think_ a sweet spot for WASM data processing. The data visualization space should explode once I can with data in the browser at near native speed. https://en.wikipedia.org/wiki/Adobe_AIR https://en.wikipedia.org/wiki/Adobe_AIR
- rusk 8y ago
  I remember trying to do stuff with Adobe AIR and it just felt like a collosal waste of time. As soon as you tried to do anything that interacted outside of their sandbox you were severely limited. I remember some guys did a hack called cairngorm that I looked at but it seemed quite cumbersome. Then there was support, I think it was only after a few years they just gave up and spun it off to Apache ... you need to stick at it longer than that to establish yourself ...
- Yoric 8y ago
  To be fair, AIR was not the first in the domain. Mozilla had XUL/XULRunner ~15 years ago, which could be used to quickly develop kick-ass cross-platform applications in JS (and is still, by and large, the base of Thunderbird and Firefox). Sun thought that they had something like that with Java Apps ~20 years ago, except they forgot to make installation and UX compelling, and the memory requirements were unacceptable for the time.
- vturner 8y ago
  Remember when Adobe AIR was going to come to Android? That would have been an amazing write once run anywhere experience.
  - pjmlp 8y ago

wffurr 8y ago

No, wasm, like asmjs, is designed to be compiled into native code once validated. Unlike asmjs, it doesn't also require a long parsing step. It uses the same code paths used to emit native code from the JS VM JIT.

deleted 8y ago

[deleted]

Yoric 8y ago

> On a side note, I'm seeing more articles pointing out that WASM runs in the JS VM. Doesn't negate the whole advantage of speed for WASM? It basically means that WASM has the same safety/security model as the JS VM. Just like JS, it is compiled to native code (I'm simplifying a bit, of course) before being executed. However, where JS is one of the languages with the most complicated semantics around, which makes it really, really hard to compile efficiently, WASM has extremely simple semantics and is designed to be really, really easy to compile efficiently.

vturner 8y ago
Thanks for the differentiation. I guess when I've read "WASM" will be native code I expect it to be as in "C" or "C++" native. Not native to a VM
- Sean1708 8y ago
  WASM and JS are both JIT compiled in all major browsers which means that they compile to the same kind of native code that C and C++ do, they just do so as the program is running rather than in advance.
  - Andrex 8y ago
    What's even better about WASM than JS in this case is that it can be compiled as it is being loaded. With JS, the entire file needs to be downloaded before being executed, but that's not the case for WASM, resulting in even more performance improvements. https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

clouddrover 8y ago

> Doesn't negate the whole advantage of speed for WASM? Well, here's a benchmark of asm.js JavaScript versus WebAssembly in a real world application: https://pspdfkit.com/blog/2018/a-real-world-webassembly-benchmark/ https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc... The WebAssembly version outperforms the asm.js version.

vturner 8y ago
If I'm not mistaken, in those plots lower is better. Only WASM on FF has a clear lead?

hinkley 8y ago

It’s bootstrapping. You’re building a new thing (example: C++) that works a lot like the old thing (C). So you build a wrapper (Charm) that works on top of the old thing so you can get the conversation going, expand your capabilities and recruit. Over time you do more of your own thing and you or someone else splits these two pieces of code into three smaller ones. Like the LLVM backend that can be fed by a C or C++ frontend. As webasm becomes a competitive advantage you should expect to see people split up their javascript VM into three pieces, and Javascript and Webassembly running as peers instead of guest and host. In a very small way, we kind of saw a similar thing with JSON. JSON was just a strict subset of Javascript and you could emulate it on old browsers with a linter in front of an eval(). Now it’s its own thing.

marcosdumay 8y ago

> I'm seeing more articles pointing out that WASM runs in the JS VM. It runs on the JS sandbox, but it can not be efficiently emulated by the JS CPU. VM is an ambiguous term. Browser developers are talking about running JS in the Wasm VM. That will probably be reasonable very soon.