Hacker News Reader

Comment by vturner | Hacker News Reader

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?

View on HN

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.

Flash on Mobiles was two sides, Adobe had a lot of difficulty to implement multi-touch correctly.

If the Mac version hadn’t been a crashy dumpster fire, Steve Jobs might not have done that. Flash on Macs was always mediocre.

By blocking flash apps he increased the motivation for migration to native apps, so there was a sound commercial basis for this as well.

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.

Not always. They were great little machines 10 or so years ago.

Nope. The current "form over function" mentality is definitely a post-Jobs and post-Flash thing.

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.

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

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 ...

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.

Remember when Adobe AIR was going to come to Android? That would have been an amazing write once run anywhere experience.

It did come to Android.

For a while before being terminated, Flash got a native code backend.

You can build Android apps (and iOS too!) with Adobe AIR today. In fact, it's been possible since about 2010.

> 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.

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

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.

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-fa...

> 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-benc...

The WebAssembly version outperforms the asm.js version.

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

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.

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.

> 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.

Reply on news.ycombinator.com