9 ms·

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

thrown_22 5y ago
It's already in all browsers.
deleted 5y ago
[deleted]
anonporridge 5y ago
Not owned by shit for brains Oracle.
- ducharmdev 5y ago
  This is the best response I've seen to this question
  - anonporridge 5y ago
    Fuck Oracle.
- hankman86 5y ago
  Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages. Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported. For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.
  - striking 5y ago
    > Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. They're working on this. It's a tough problem, because someone has to own the resources. I don't think browser fragmentation is an issue for the same reason that CPU instruction set fragmentation isn't an issue: you can always compile to the lowest common denominator or ensure you are only running code segments that the target platform supports using runtime checks, just the same way we do it in native applications today.
  - trhway 5y ago
    >Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. we did it more than 20 years ago :) A Java Applet could call directly (Java Applet -> Java DOM API and implementing it JNI of our plugin -> native XPCOM API of Mozilla including DOM API) native DOM API of the owning browser window as well as a Java application could embed Mozilla Gecko browser engine and call the native DOM API of that embedded browser: https://www-archive.mozilla.org/projects/blackwood/dom/ https://www-archive.mozilla.org/projects/blackwood/dom/
  - RantyDave 5y ago
    Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.
    - pjmlp 5y ago
      Just like JavaApplets could.
- pjmlp 5y ago
  Sure, because being driven by the likes of Google is so much better.
dragonwriter 5y ago
* Already in all the browsers natively, without plugins or similar third-party optional components, and * Already widely supported as a compilation target, and not just for special languages targeting the platform
- russtrotter 5y ago
  To continue the Java bytecode prior comment, at one point, java was in all browsers of the time (i.e. Applets). However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. Java also enjoys multiple HLLs that target its bytecode (Scala, Kotlin, Groovy, Jython, etc) and there's nothing in the runtime capabilities that tie it to any kind of constrained platform (threading, IO, async) Don't get me wrong, I'm really hoping that WASM succeeds but I'm concerned that the same set of slam dunks we thought back in 1996 don't result getting posterized (again) by DOM/JS.
  - dragonwriter 5y ago
    > To continue the Java bytecode prior comment, at one point, java was in all browsers of the time No, it wasn't. > (i.e. Applets). Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser. > However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. It progressively lost to (1) other plug-in based tech (Flash), and (2) expansion and optimizayiom of the web platform to make plug-in based tech less needed while security problems of the model became more visible, and finally (3) the rising importance of web browsers that didn't support plugins (which are now dominant even on desktop.) > Java also enjoys multiple HLLs that target its bytecode But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written. WASM was specifically designed with being a target for C/C++, and those and languages like Rust and Go already target it.
    - orangecat 5y ago
      The capacity to run them was not built in natively to any major browser. It was at first. In the early days of Java, Netscape and Internet Explorer had their own embedded JVMs.
user249 5y ago
Why not .NET? Surely Microsoft is better than Oracle
- Ygg2 5y ago
  Surely being eaten by a shark is better than torn apart by a hyena.
  - emptyparadise 5y ago
    Instead we picked getting mauled by a panther.
AnIdiotOnTheNet 5y ago
> WebAssembly is full of potential. Eh... from what I can tell from a mostly casual glance at it (enough for a half-hearted half-complete attempt at writing my own VM for it), I'd say that it is almost a good idea. A lot of the base concepts show a lot of potential, but I feel like the implementation is full design-by-committee derp. Why are there only 32 and 64 bit types? Why are there parametric instructions at all? Why is there no instruction for shrinking or freeing a memory? Why does binary format layer 0 use LEB128 instead of a fixed-width number? Just a bunch of weird stuff like that. But I'm hardly an expert on JIT or VM implementations, so I could be way off base here.
- enos_feedler 5y ago
  Even if it's weird and designed by committee, at least we have agreement with all browsers. IMO, WebAssembly has got over the biggest hurdle: agreement in a format to feed an abstract processor to program it to do math. Nothing more, nothing less. In the web ecosystem, the most powerful thing right now is agreement. The design might be ugly or weird, but it works and it's done. Lets build on top of it.
  - AnIdiotOnTheNet 5y ago
    Frankly, fuck the web. It's a warzone where Google throws its weight around to enhance the ability of advertisers to make our lives terrible. I was more interested in WASM as a universal VM for all platforms, but it doesn't fit nearly as well for that as it could because of some of the strange decisions this web-focused committee made. At least Java was also designed to run on not-the-web.
    - enos_feedler 5y ago
      Yes, I am as well. But anything built on top of wasm to run everywhere should probably at least operate well inside a browser environment. Almost as an incubation environment for something bigger. The browser platform is too big to ignore. We rise up from Chrome, Firefox, Safari etc!!! Here and now!!! We Rise!
enos_feedler 5y ago
SPIR is special purpose and can't be compared. JVM in the browser might be a similar comparison, but back then we didn't have the threats we have today. We now have closed hardware, closed operating system, and even closed browsers. The browsers are just extensions of these closed companies. We now more than ever need an open computing stack untethered from the underlying chips, devices, operating systems, etc.
mdasen 5y ago
I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it. Java applets were things that were slow to load and didn't interface well with the rest of the web. People can talk about how you could technically connect things until they're blue in the face, but Java didn't provide a good experience with HTML. It was its own thing just like Adobe Flash. I think that comparison is important: Java applets and Adobe Flash were these separate non-HTML entities that felt proprietary and didn't play nicely with others. Maybe something might be open-source, but Java applets felt like they were trying to usurp the web. JavaScript augments the web rather than usurping it - and WASM similarly fills that role. I think that WASM will succeed where others haven't because it has been designed by the parties you need to get on board to make it succeed. Java wanted to create its own little world against the wishes of the vast majority of developers and users. Flash created its own little world against the wishes of most developers (though most users didn't mind). WASM feels like a neutral target that most of the community can get behind. While WASM might not be perfect or anything, it does seem to unite a lot of different communities. It doesn't feel like Sun is coming along and imposing Java applets on everyone so that they can better sell Java to enterprises. It doesn't feel like Adobe trying to lock developers into expensive Flash tools. It doesn't feel like Microsoft saying, "Silverlight is our Flash! You should use that!" It's something that engineers from lots of different communities are supportive of and that works with the web rather than trying to usurp it.
- RantyDave 5y ago
  Java applets downloaded over 56k and were run (not jit'ed) on pentium 2's. In other words if we took Java, replaced the standard library with an interface onto the browser, would we not end up with exactly the same thing? They're even both stack machines. Happy to support an argument that removing Oracle's influence is worth reinventing an entire runtime for.
- kaba0 5y ago
  I don’t think that Flash and Java “created their own little world”, but rather that they were entities not “accepted” by browsers, so they remained in a “third-party” status, but that was not their decision to make.

thrown_22 5y ago

It's already in all browsers.

deleted 5y ago

[deleted]

anonporridge 5y ago

Not owned by shit for brains Oracle.

ducharmdev 5y ago
This is the best response I've seen to this question
- anonporridge 5y ago
  Fuck Oracle.
hankman86 5y ago
Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages. Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported. For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.
- striking 5y ago
  > Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. They're working on this. It's a tough problem, because someone has to own the resources. I don't think browser fragmentation is an issue for the same reason that CPU instruction set fragmentation isn't an issue: you can always compile to the lowest common denominator or ensure you are only running code segments that the target platform supports using runtime checks, just the same way we do it in native applications today.
- trhway 5y ago
  >Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. we did it more than 20 years ago :) A Java Applet could call directly (Java Applet -> Java DOM API and implementing it JNI of our plugin -> native XPCOM API of Mozilla including DOM API) native DOM API of the owning browser window as well as a Java application could embed Mozilla Gecko browser engine and call the native DOM API of that embedded browser: https://www-archive.mozilla.org/projects/blackwood/dom/ https://www-archive.mozilla.org/projects/blackwood/dom/
- RantyDave 5y ago
  Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.
  - pjmlp 5y ago
    Just like JavaApplets could.
pjmlp 5y ago
Sure, because being driven by the likes of Google is so much better.

dragonwriter 5y ago

* Already in all the browsers natively, without plugins or similar third-party optional components, and * Already widely supported as a compilation target, and not just for special languages targeting the platform

russtrotter 5y ago
To continue the Java bytecode prior comment, at one point, java was in all browsers of the time (i.e. Applets). However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. Java also enjoys multiple HLLs that target its bytecode (Scala, Kotlin, Groovy, Jython, etc) and there's nothing in the runtime capabilities that tie it to any kind of constrained platform (threading, IO, async) Don't get me wrong, I'm really hoping that WASM succeeds but I'm concerned that the same set of slam dunks we thought back in 1996 don't result getting posterized (again) by DOM/JS.
- dragonwriter 5y ago
  > To continue the Java bytecode prior comment, at one point, java was in all browsers of the time No, it wasn't. > (i.e. Applets). Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser. > However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. It progressively lost to (1) other plug-in based tech (Flash), and (2) expansion and optimizayiom of the web platform to make plug-in based tech less needed while security problems of the model became more visible, and finally (3) the rising importance of web browsers that didn't support plugins (which are now dominant even on desktop.) > Java also enjoys multiple HLLs that target its bytecode But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written. WASM was specifically designed with being a target for C/C++, and those and languages like Rust and Go already target it.
  - orangecat 5y ago
    The capacity to run them was not built in natively to any major browser. It was at first. In the early days of Java, Netscape and Internet Explorer had their own embedded JVMs.

user249 5y ago

Why not .NET? Surely Microsoft is better than Oracle

Ygg2 5y ago
Surely being eaten by a shark is better than torn apart by a hyena.
- emptyparadise 5y ago
  Instead we picked getting mauled by a panther.

AnIdiotOnTheNet 5y ago

> WebAssembly is full of potential. Eh... from what I can tell from a mostly casual glance at it (enough for a half-hearted half-complete attempt at writing my own VM for it), I'd say that it is almost a good idea. A lot of the base concepts show a lot of potential, but I feel like the implementation is full design-by-committee derp. Why are there only 32 and 64 bit types? Why are there parametric instructions at all? Why is there no instruction for shrinking or freeing a memory? Why does binary format layer 0 use LEB128 instead of a fixed-width number? Just a bunch of weird stuff like that. But I'm hardly an expert on JIT or VM implementations, so I could be way off base here.

enos_feedler 5y ago
Even if it's weird and designed by committee, at least we have agreement with all browsers. IMO, WebAssembly has got over the biggest hurdle: agreement in a format to feed an abstract processor to program it to do math. Nothing more, nothing less. In the web ecosystem, the most powerful thing right now is agreement. The design might be ugly or weird, but it works and it's done. Lets build on top of it.
- AnIdiotOnTheNet 5y ago
  Frankly, fuck the web. It's a warzone where Google throws its weight around to enhance the ability of advertisers to make our lives terrible. I was more interested in WASM as a universal VM for all platforms, but it doesn't fit nearly as well for that as it could because of some of the strange decisions this web-focused committee made. At least Java was also designed to run on not-the-web.
  - enos_feedler 5y ago
    Yes, I am as well. But anything built on top of wasm to run everywhere should probably at least operate well inside a browser environment. Almost as an incubation environment for something bigger. The browser platform is too big to ignore. We rise up from Chrome, Firefox, Safari etc!!! Here and now!!! We Rise!

enos_feedler 5y ago

SPIR is special purpose and can't be compared. JVM in the browser might be a similar comparison, but back then we didn't have the threats we have today. We now have closed hardware, closed operating system, and even closed browsers. The browsers are just extensions of these closed companies. We now more than ever need an open computing stack untethered from the underlying chips, devices, operating systems, etc.

mdasen 5y ago

I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it. Java applets were things that were slow to load and didn't interface well with the rest of the web. People can talk about how you could technically connect things until they're blue in the face, but Java didn't provide a good experience with HTML. It was its own thing just like Adobe Flash. I think that comparison is important: Java applets and Adobe Flash were these separate non-HTML entities that felt proprietary and didn't play nicely with others. Maybe something might be open-source, but Java applets felt like they were trying to usurp the web. JavaScript augments the web rather than usurping it - and WASM similarly fills that role. I think that WASM will succeed where others haven't because it has been designed by the parties you need to get on board to make it succeed. Java wanted to create its own little world against the wishes of the vast majority of developers and users. Flash created its own little world against the wishes of most developers (though most users didn't mind). WASM feels like a neutral target that most of the community can get behind. While WASM might not be perfect or anything, it does seem to unite a lot of different communities. It doesn't feel like Sun is coming along and imposing Java applets on everyone so that they can better sell Java to enterprises. It doesn't feel like Adobe trying to lock developers into expensive Flash tools. It doesn't feel like Microsoft saying, "Silverlight is our Flash! You should use that!" It's something that engineers from lots of different communities are supportive of and that works with the web rather than trying to usurp it.

RantyDave 5y ago
Java applets downloaded over 56k and were run (not jit'ed) on pentium 2's. In other words if we took Java, replaced the standard library with an interface onto the browser, would we not end up with exactly the same thing? They're even both stack machines. Happy to support an argument that removing Oracle's influence is worth reinventing an entire runtime for.
kaba0 5y ago
I don’t think that Flash and Java “created their own little world”, but rather that they were entities not “accepted” by browsers, so they remained in a “third-party” status, but that was not their decision to make.