5 ms·

For those thinking that this is just Java and Flash all over again: Here's the relevant blog post from Steve Klabnik explaining why this is _very_ different: h

by kostaw 8y ago

For those thinking that this is just Java and Flash all over again: Here's the relevant blog post from Steve Klabnik explaining why this is _very_ different: https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...

acqq 8y ago
The post is not about this implementation (the link of the original post) though. This implementation is not about the browsers.
userbinator 8y ago
There’s another reason Wasm succeeded: it’s tiny. I'll agree with him that Java is very much not tiny, but I disagree about Flash. The last time I remember setting it up, the browser plugin was a single binary of a few MB (and I'm sure that could be made smaller.) SWF files are also a great example of a well-designed space-optimised vector graphics format --- remember that it was designed close to 20 years ago for the computers of the time. Edit: care to explain, downvoters?
- afiori 8y ago
  But flash was not an option for similar purposes because of its terrible security.
- vorpalhex 8y ago
  Flash runtime was several hundreds MBs. Sure the actual applets were a few mb of mostly animations and resources, but the runtime was another thing.
  - deleted 8y ago
    [deleted]
  - aepiepaey 8y ago
    The runtime is ~15MB, far from hundreds of MBs.
    - stcredzero 8y ago
      Back in the early 2000's, IIRC, Squeak Smalltalkers succeeded in getting a Smalltalk runtime down to 385 kB. Haters still complained about it being "too fat." There was an R&D project which got one Smalltalk image for a Unix-style command line utility to 45 kB. Back in those days, the standard class library for a VisualWorks Smalltalk image was about 12MB on disk. In contrast, Perl had a runtime of something like 768 kB. Yet, VisualWorks could load its runtime faster, if you tweaked things, like shutting off the boot-up chime and notifier dialog.
      - derefr 8y ago
        > Yet, VisualWorks could load its runtime faster, if you tweaked things For the same reason that Emacs loads quickly: the "image" is (an abstracted, runtime-dependent equivalent to) a memory dump. Perl has to parse Perl code when it starts up; Smalltalk just "is" Smalltalk when it starts up. Like booting up a DBMS where the DB already has data in it. Honestly, I'm kind of surprised more modern languages/runtimes don't take this approach. The Smalltalk approach would work exactly as well for e.g. Ruby.
        simcop2387 8y ago
        It leads to a lot of issues with the end design of everything. You either have to reconstruct the heap and all the pointers involved, or it has to be loaded at a known address. With things like ASLR, and a bunch of other security features this ends up difficult or impossible to do directly anymore. Along with that, it also means that the runtimes aren't cross-compatible at load time so weird differences might leak out (little or big endianess, etc.). It leads to a lot of headaches because of changing systems underneath it.
- icedchai 8y ago
  20 years ago, indeed, Java wasn't tiny. That was on "high end" desktop computers with roughly 64 to 128 megs of RAM. Today, in the days of browsers taking up gigabytes of memory, it's hardly a concern. That applet JVM would start lightning fast.
- leshow 8y ago
  pepperflash plugin, the flash runtime that chrome includes, is about 20mb.
- hackcasual 8y ago
  It's not tiny in the sense of file size, it's tiny in the sense of scope. It doesn't even have a standard library, let alone offer everything flash and Java did. At it's heart it's just a compact, efficient representation of a subset of JavaScript
  - sitkack 8y ago
    > At it's heart it's just a compact, efficient representation of a subset of JavaScript WASM is a well specified encoding for a stack based machine with the following 4 types, i32, i64, f32 and f64. It is very much not JavaScript. https://github.com/WebAssembly/design/blob/master/Semantics.md https://github.com/WebAssembly/design/blob/master/Semantics....
    - steveklabnik 8y ago
      It's so much not JavaScript that you cannot even compile JavaScript to wasm!
      - int_19h 8y ago
        Wait... why? What's the limiting factor?
        steveklabnik 8y ago
        there’s not a lot of reason to. In the browser, you already have a JS environment. It’s easier to add a wasm environment to it than it is to re-write the world. Additionally, wasm doesn’t have a GC, and is not really optimized for dynamic languages, so there’s just not a lot of reason to do it.
        int_19h 8y ago
        Oh, I thought you mean that there's some fundamental reason why it can't be done. Ofc it's pointless today, but I wouldn't be surprised if JS in browsers eventually becomes a layer on top of wasm.
kitd 8y ago
I'm not wholly convinced. I'm quite happy that Wasm is a great step forward, but I think that is more by accident of history. Javascript was already in the browser so JS/Wasm was low-hanging fruit. Using it to claim "Wasm succeeded" is premature.
repolfx 8y ago
That is a weird, unconvincing post. His first point about why it's different is "Wasm won"? Really? Back in the day Java applets were everywhere. They had "won". They disappeared because browser makers kicked them out along with Flash, which had also "won". He then tries to redefine plugins, which were created by Netscape, had a standard cross platform API and their own HTML tags as somehow "not a part of the web platform". Then he says that's "in some senses the final point", as if being forced into the platform by de-facto execution of all competitors says all you need to know about why WebAssembly is good. But still, he does go on to make other points too. Firstly he picks up on loading screens, presumably claiming WebAssembly doesn't have loading screens. Well, no, the web platform makes you implement your own. But the reason apps like Gmail have loading screens is because it's waiting whilst the browser downloads, parses and initialises megabytes of JavaScript and WASM (maybe, assuming Gmail uses some). To the extent it's faster it's only because hardware is faster, not due to any fundamental difference in technology. Not having a standardised splash doesn't seem like an actual win. He then goes on to argue: These platforms never gained the ability to interact with the rest of the platform provided by your browser. Well, technically they might have, but that’s not how these technologies were used in practice. So he makes a false claim - that applets and flash couldn't interact with the hosting web page - and then immediately admits it's false, but that "this isn't how the tech was used in practice". But I remember quite a few Java and Flash applets that interacted with the host page and changed the HTML, most obviously in things like the original Google Talk. And to the extent Java applets rarely did, that's because HTML sucked in that era. Arguably it still does. The primary reason people were writing Java applets was to escape the woeful inadequacy of the web platform, so no big surprise not many applets rendered their UI using "the benefits of HTML and CSS". And users ended up solidly rejecting it. Outside of games, users hated Flash. Java Applets were heavy and slow. Users didn't reject Flash. Flash went everywhere. It was the de-facto video streaming solution, the de-facto cross platform lightweight games solution, it was in every Gmail page, it was the standard way to make attractive animated websites. Site authors adopted it en-masse and users loved those sites, which were often doing things HTML users couldn't even begin to do. And of course Java applets were "heavy and slow" in an era when the web itself was so heavy and slow, that people didn't even try to do the same things with it. The crime of Java applets was mostly that they raised developer expectations to unreasonable levels and devs ended up blowing their hardware budgets. The web was crippled and limited, so people didn't even try to make sophisticated UIs or modular software, and it ended up staying within the envelope of what slow internet connections could manage more effectively. WebAssembly, on the other hand, is much closer to JavaScript. It doesn’t inherently require taking over a part of your screen. It doesn’t expect to be its own little closed off world. Via JavaScript today, and on its own in the future, it’s able to interact with the surrounding environment. It just… fits. Here he's just repeating an argument he already admitted himself is wrong. Flash applets and Java applets could both be invisible and could both "fit" with the surrounding environment. And he already knows that. I have to admit I stopped reading at this point. WebAssembly is a poor re-implementation of the JVM, 20+ years later, and its primary selling point is that browser makers control it so they are forcing people to use it in the same way they did for JavaScript. The advocates for it know their own comparisons with prior tech are bogus but make them anyway. It's depressing to see.

by kostaw 8y ago

acqq 8y ago

The post is not about this implementation (the link of the original post) though. This implementation is not about the browsers.

userbinator 8y ago

There’s another reason Wasm succeeded: it’s tiny. I'll agree with him that Java is very much not tiny, but I disagree about Flash. The last time I remember setting it up, the browser plugin was a single binary of a few MB (and I'm sure that could be made smaller.) SWF files are also a great example of a well-designed space-optimised vector graphics format --- remember that it was designed close to 20 years ago for the computers of the time. Edit: care to explain, downvoters?

afiori 8y ago
But flash was not an option for similar purposes because of its terrible security.
vorpalhex 8y ago
Flash runtime was several hundreds MBs. Sure the actual applets were a few mb of mostly animations and resources, but the runtime was another thing.
- deleted 8y ago
  [deleted]
- aepiepaey 8y ago
  The runtime is ~15MB, far from hundreds of MBs.
  - stcredzero 8y ago
    Back in the early 2000's, IIRC, Squeak Smalltalkers succeeded in getting a Smalltalk runtime down to 385 kB. Haters still complained about it being "too fat." There was an R&D project which got one Smalltalk image for a Unix-style command line utility to 45 kB. Back in those days, the standard class library for a VisualWorks Smalltalk image was about 12MB on disk. In contrast, Perl had a runtime of something like 768 kB. Yet, VisualWorks could load its runtime faster, if you tweaked things, like shutting off the boot-up chime and notifier dialog.
    - derefr 8y ago
      > Yet, VisualWorks could load its runtime faster, if you tweaked things For the same reason that Emacs loads quickly: the "image" is (an abstracted, runtime-dependent equivalent to) a memory dump. Perl has to parse Perl code when it starts up; Smalltalk just "is" Smalltalk when it starts up. Like booting up a DBMS where the DB already has data in it. Honestly, I'm kind of surprised more modern languages/runtimes don't take this approach. The Smalltalk approach would work exactly as well for e.g. Ruby.
      - simcop2387 8y ago
        It leads to a lot of issues with the end design of everything. You either have to reconstruct the heap and all the pointers involved, or it has to be loaded at a known address. With things like ASLR, and a bunch of other security features this ends up difficult or impossible to do directly anymore. Along with that, it also means that the runtimes aren't cross-compatible at load time so weird differences might leak out (little or big endianess, etc.). It leads to a lot of headaches because of changing systems underneath it.
icedchai 8y ago
20 years ago, indeed, Java wasn't tiny. That was on "high end" desktop computers with roughly 64 to 128 megs of RAM. Today, in the days of browsers taking up gigabytes of memory, it's hardly a concern. That applet JVM would start lightning fast.
leshow 8y ago
pepperflash plugin, the flash runtime that chrome includes, is about 20mb.
hackcasual 8y ago
It's not tiny in the sense of file size, it's tiny in the sense of scope. It doesn't even have a standard library, let alone offer everything flash and Java did. At it's heart it's just a compact, efficient representation of a subset of JavaScript
- sitkack 8y ago
  > At it's heart it's just a compact, efficient representation of a subset of JavaScript WASM is a well specified encoding for a stack based machine with the following 4 types, i32, i64, f32 and f64. It is very much not JavaScript. https://github.com/WebAssembly/design/blob/master/Semantics.md https://github.com/WebAssembly/design/blob/master/Semantics....
  - steveklabnik 8y ago
    It's so much not JavaScript that you cannot even compile JavaScript to wasm!
    - int_19h 8y ago
      Wait... why? What's the limiting factor?
      - steveklabnik 8y ago
        there’s not a lot of reason to. In the browser, you already have a JS environment. It’s easier to add a wasm environment to it than it is to re-write the world. Additionally, wasm doesn’t have a GC, and is not really optimized for dynamic languages, so there’s just not a lot of reason to do it.
        int_19h 8y ago
        Oh, I thought you mean that there's some fundamental reason why it can't be done. Ofc it's pointless today, but I wouldn't be surprised if JS in browsers eventually becomes a layer on top of wasm.

kitd 8y ago

I'm not wholly convinced. I'm quite happy that Wasm is a great step forward, but I think that is more by accident of history. Javascript was already in the browser so JS/Wasm was low-hanging fruit. Using it to claim "Wasm succeeded" is premature.

repolfx 8y ago

That is a weird, unconvincing post. His first point about why it's different is "Wasm won"? Really? Back in the day Java applets were everywhere. They had "won". They disappeared because browser makers kicked them out along with Flash, which had also "won". He then tries to redefine plugins, which were created by Netscape, had a standard cross platform API and their own HTML tags as somehow "not a part of the web platform". Then he says that's "in some senses the final point", as if being forced into the platform by de-facto execution of all competitors says all you need to know about why WebAssembly is good. But still, he does go on to make other points too. Firstly he picks up on loading screens, presumably claiming WebAssembly doesn't have loading screens. Well, no, the web platform makes you implement your own. But the reason apps like Gmail have loading screens is because it's waiting whilst the browser downloads, parses and initialises megabytes of JavaScript and WASM (maybe, assuming Gmail uses some). To the extent it's faster it's only because hardware is faster, not due to any fundamental difference in technology. Not having a standardised splash doesn't seem like an actual win. He then goes on to argue: These platforms never gained the ability to interact with the rest of the platform provided by your browser. Well, technically they might have, but that’s not how these technologies were used in practice. So he makes a false claim - that applets and flash couldn't interact with the hosting web page - and then immediately admits it's false, but that "this isn't how the tech was used in practice". But I remember quite a few Java and Flash applets that interacted with the host page and changed the HTML, most obviously in things like the original Google Talk. And to the extent Java applets rarely did, that's because HTML sucked in that era. Arguably it still does. The primary reason people were writing Java applets was to escape the woeful inadequacy of the web platform, so no big surprise not many applets rendered their UI using "the benefits of HTML and CSS". And users ended up solidly rejecting it. Outside of games, users hated Flash. Java Applets were heavy and slow. Users didn't reject Flash. Flash went everywhere. It was the de-facto video streaming solution, the de-facto cross platform lightweight games solution, it was in every Gmail page, it was the standard way to make attractive animated websites. Site authors adopted it en-masse and users loved those sites, which were often doing things HTML users couldn't even begin to do. And of course Java applets were "heavy and slow" in an era when the web itself was so heavy and slow, that people didn't even try to do the same things with it. The crime of Java applets was mostly that they raised developer expectations to unreasonable levels and devs ended up blowing their hardware budgets. The web was crippled and limited, so people didn't even try to make sophisticated UIs or modular software, and it ended up staying within the envelope of what slow internet connections could manage more effectively. WebAssembly, on the other hand, is much closer to JavaScript. It doesn’t inherently require taking over a part of your screen. It doesn’t expect to be its own little closed off world. Via JavaScript today, and on its own in the future, it’s able to interact with the surrounding environment. It just… fits. Here he's just repeating an argument he already admitted himself is wrong. Flash applets and Java applets could both be invisible and could both "fit" with the surrounding environment. And he already knows that. I have to admit I stopped reading at this point. WebAssembly is a poor re-implementation of the JVM, 20+ years later, and its primary selling point is that browser makers control it so they are forcing people to use it in the same way they did for JavaScript. The advocates for it know their own comparisons with prior tech are bogus but make them anyway. It's depressing to see.