3 ms·

We are not talking about Applets, those came from a time when the rest of the web technologies were way behind, and the best we could do is to put up a canvas t

by kaba0 3y ago

We are not talking about Applets, those came from a time when the rest of the web technologies were way behind, and the best we could do is to put up a canvas to render into. Also, why would we expose the full filesystem api to a theoretical JVM for the Web? The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. Of course WASM is safe without any outside functionality, so is brainfuck in and of itself.

josephg 3y ago
> The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. So you're suggesting we put a subset of the JVM in the browser, with no access to the java standard library? Why? You couldn't run any existing java code or any code in other languages without a compiler. It would just be a weird sub-language that nobody really wants to use, with no existing code or libraries. The pressure would be on to add all the crap from the JRE - putting a tension between security (who knows how secure any of that code is) and usability (who wants a language with no standard library?). This has all played out before and java ended up giving up and deprecating SecurityManager. Even if you succeed, to what end? So we can run java in the browser? So we have 2 average languages instead of 1? Should we add a C# subset next? The beauty of wasm is that any language can target it. Or would we compile our C, Go, C# and Rust to this new java subset? But that wouldn't work well - java is missing many features which would be needed to run C code properly. You could make it work using some horrible hacks on top of ByteBuffers, but then it'd run much slower than native code. Much slower than wasm runs today. Whats the point when we could just do the same thing on top of javascript? (And we did - it was called asmjs).
- kaba0 3y ago
  I have replied to many of these points in another thread where we talk, so I won't repeat those. I suggest putting a subset of the JVM that has access to many parts of the standard library, but certain APIs would need proper browser permissions, the same way it works with JS today. It could run the vast majority of the very high quality of Java ecosystem, and every JVM guest language code out of the box. It is also not a bad compile target -- I would argue that most mainstream languages would actually prefer a managed runtime, and C/C++/Rust are the niche. Aren't there orders of magnitude Java+Python+C#+Haskell+... devs that would prefer to write in their language over JS? Sure, you might say that the reason for WASM's existence is mostly the performance gains for small algorithms, and there certainly is a new niche made available thanks to it, but one way or another people will use it simply due to preferring their stack to JS. The performance aspect is also improved to the JS-only world by possibly allowing proper shared-memory multithreading. > java is missing many features which would be needed to run C code properly Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? It's just an array read mapped to a single instruction, but in context can also be optimized efficiently (e.g. autovectorizing them when they occur in a loop). GraalVM actually has support for any LLVM language (though their way of interpretation is different enough from the standard JVM bytecode mode that I only mention it as an interesting data point) with quite great performance, certainly comparable to WASM. Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I also don't dislike WASM, it is imo a net positive thing. I just believe that a JVM-fueled web failed mostly due to politics, not something inherently technical.
  - josephg 3y ago
    > Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? Mmm maybe it is fine in java. I've spent a lot of time benchmarking javascript which has a similar set of primitives (typed arrays). I'm not sure how they perform now, but at the time they were always significantly slower than native javascript arrays for some reason. > GraalVM actually has support for any LLVM language Cool - I didn't know that! Thats definitely a point in the direction of the jvm being viable. > Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I'm enjoying this too. For what its worth, at a big picture level I think it would definitely be technically possible to do what you're proposing. Its just a question of tradeoffs. Is it easier to tame a subset of java that could usefully fit in the browser, or just start fresh? The downside of starting fresh is that we'd need new compilers and optimizers. And the downside of using java is that the security story is much more complicated, and you'd need to figure out how much of the standard library to bring across and figure out how to secure the FFI. Obviously the wasm team chose the latter. But perhaps if there were more java fans amongst browser vendors, or the choice was made decades ago, I could easily see the JVM being chosen instead of inventing wasm.

by kaba0 3y ago

josephg 3y ago

> The core of the JVM is a simple stack-machine and a GC, there is nothing demanding all these additional hooks to useful, but potentially unsafe APIs. So you're suggesting we put a subset of the JVM in the browser, with no access to the java standard library? Why? You couldn't run any existing java code or any code in other languages without a compiler. It would just be a weird sub-language that nobody really wants to use, with no existing code or libraries. The pressure would be on to add all the crap from the JRE - putting a tension between security (who knows how secure any of that code is) and usability (who wants a language with no standard library?). This has all played out before and java ended up giving up and deprecating SecurityManager. Even if you succeed, to what end? So we can run java in the browser? So we have 2 average languages instead of 1? Should we add a C# subset next? The beauty of wasm is that any language can target it. Or would we compile our C, Go, C# and Rust to this new java subset? But that wouldn't work well - java is missing many features which would be needed to run C code properly. You could make it work using some horrible hacks on top of ByteBuffers, but then it'd run much slower than native code. Much slower than wasm runs today. Whats the point when we could just do the same thing on top of javascript? (And we did - it was called asmjs).

kaba0 3y ago
I have replied to many of these points in another thread where we talk, so I won't repeat those. I suggest putting a subset of the JVM that has access to many parts of the standard library, but certain APIs would need proper browser permissions, the same way it works with JS today. It could run the vast majority of the very high quality of Java ecosystem, and every JVM guest language code out of the box. It is also not a bad compile target -- I would argue that most mainstream languages would actually prefer a managed runtime, and C/C++/Rust are the niche. Aren't there orders of magnitude Java+Python+C#+Haskell+... devs that would prefer to write in their language over JS? Sure, you might say that the reason for WASM's existence is mostly the performance gains for small algorithms, and there certainly is a new niche made available thanks to it, but one way or another people will use it simply due to preferring their stack to JS. The performance aspect is also improved to the JS-only world by possibly allowing proper shared-memory multithreading. > java is missing many features which would be needed to run C code properly Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? It's just an array read mapped to a single instruction, but in context can also be optimized efficiently (e.g. autovectorizing them when they occur in a loop). GraalVM actually has support for any LLVM language (though their way of interpretation is different enough from the standard JVM bytecode mode that I only mention it as an interesting data point) with quite great performance, certainly comparable to WASM. Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I also don't dislike WASM, it is imo a net positive thing. I just believe that a JVM-fueled web failed mostly due to politics, not something inherently technical.
- josephg 3y ago
  > Why would ByteBuffers be a horrible hack? Is it worse of a hack then what C compilers have to do when targeting WASM, like only having structured control flow? Mmm maybe it is fine in java. I've spent a lot of time benchmarking javascript which has a similar set of primitives (typed arrays). I'm not sure how they perform now, but at the time they were always significantly slower than native javascript arrays for some reason. > GraalVM actually has support for any LLVM language Cool - I didn't know that! Thats definitely a point in the direction of the jvm being viable. > Nonetheless, please don't take my possibly argumentative tone as a negative, I enjoy this discussion and you make great points. I'm enjoying this too. For what its worth, at a big picture level I think it would definitely be technically possible to do what you're proposing. Its just a question of tradeoffs. Is it easier to tame a subset of java that could usefully fit in the browser, or just start fresh? The downside of starting fresh is that we'd need new compilers and optimizers. And the downside of using java is that the security story is much more complicated, and you'd need to figure out how much of the standard library to bring across and figure out how to secure the FFI. Obviously the wasm team chose the latter. But perhaps if there were more java fans amongst browser vendors, or the choice was made decades ago, I could easily see the JVM being chosen instead of inventing wasm.