Another nail in the Java coffin?
I hope if doensn't refuse to die (again)
for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
advantages: sandbox, portability
disadvantages: performance, platform integration
nobody's saying that server-side wasm will be universally the right choice.
e.g. https://www.cloudflare.com/products/cloudflare-workers/
Until such a creation comes to be, the OpenJDK JVM will continue to thrive.
"GraalVM Community Editions are based on OpenJDK version 1.8.0_232 and on OpenJDK version 11.0.5. GraalVM Enterprise Editions are based on Oracle Java version 1.8.0_231 and on Oracle Java version 11.0.5." Source: https://www.graalvm.org/docs/getting-started/
So, it's still the OpenJDK JVM underneath.
Though V8 is more likely to be what WASM first targets.
https://www.chromium.org/nativeclient/pnacl/introduction-to-...
That part is called WASI.
Probably Electron can be one of such new runtimes
Can you explain a bit more in what way you see it as legacy?
Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive.
You can argue Java as a language has some legacy hanging around, though they've made great progress there with the latest versions. But the JVM has support for other languages as well, such as Ruby, Python, Scala, Kotlin, Clojure, Common Lisp, JavaScript, Fantom, etc.
Now WASM isn't a runtime. WASM is more akin to Java Bytecode or LLVM bitcode.
Each browser vendor will implement their own WASM VM. Currently, there is no standard for Garbage Collection, which means GCed languages won't be good candidates for WASM. If you want to use Python, Java, C#, Kotlin, TypeScript, Haskell, etc. your resulting program will need to bundle a full runtime for your language compiled to WASM as well. In all cases, this will end up having slower performance, and on the web will cause bigger download sizes.
Hopefully, this gets addressed in the future.
The flip side is portability. For example, Go compiled to WASM could run on all WASM non-web compliant VMs. But it'll run slower than GO compiled for the target machine directly.
That's why a good use case for WASM right now is to allow JavaScript to make use of C/C++ libraries in the browser. As well as Node.js to do the same in non-browser contexts.
This will often mean an HTML/CSS/JS UX with certain section of it in C/C++/Rust.
It does mean that Electron apps will be able to make use of portable C/C++ libraries more easily, as they get compiled to WASM and the V8 runtime will be able to run that WASM and eventually offer interop with the DOM and JS. Though that's not yet supported, as the boundary between GCed JS/DOM and WASM hasn't been fully figured out yet.
Also, WASI is the standard library for WASM, and that'll need to grow as well. Progress is being made there too, but its goal is to remain minimal, and delend more on libraries.
Conclusion, let's say you have WASM, Java Bytecode and LLVM bitcode, and maybe even .net IR. All of them are a form of virtual assembly which need a VM to run them. Any language could build a compiler to any of these. But they have different trade offs.
Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages.
.net IR is pretty similar, though the bytecode can be a bit more difficult in its handling of reified generics. That can make it a bit harder to target for higher level languages. Its JIT isn't as sophisticated, same as its GC, but it comes real close, and has good tooling around it and an excellent standard library.
LLVM will remain king for high performance, as it is designed to handle all kind of optimizations, and support multiple's language feature set efficiently. That said, it isn't as portable and isn't optimized for small binaries and fast parse times. It too, is best for low level languages as it doesn't enforce a memory model.
WASM also doesn't enforce a memory model, making it a great target for low level languages. It is optimized for safety and portability. Which means it'll most likely always be slower than LLVM. But it also tries to be as fast as it can, and theoritically could beat out Java Bytecode or .net IR given it can avoid GC overhead. It also is optimized to be streamed over the wire, that means small binaries that can be quickly parsed. So ideal for code that you can't predict where it is going to run, like the web.
The VM landscape overall is looking pretty healthy. But I think there's misconceptions out there, especially around the JVM and .net Core, and also about people's hype for WASM. Specifically, the JVM and .net Core are almost impossible to beat for what they do. So don't expect better from WASM. Similarly, JS is almost impossible to beat for what it does, and WASM doesn't plan to replace it, but enhance it.
Not necessarily. The problem is that JVM is too high-level, and imposes not just a memory model, but also an object model, with many constraints to impose memory safety. That can be difficult to work around without performance penalties. So languages that are designed to target JVM from the get go, tend to be designed with those limitations in mind, constraining them.
.NET bytecode is somewhere in the middle between that and wasm. It has things such as raw pointers and pointer arithmetic, dynamic allocation of stack, unions, and other things that aren't memory-safe. This allows languages that don't want to have memory safety imposed on them (like C++), or that have their own ideas about how to impose it properly (like Rust), do whatever they want, and run efficiently on top of CLR. But it still has that high-level object model, much like JVM, which can be used for interop that's higher-level than just a C ABI.
wasm, for the time being at least, is a VM that is limited to a C ABI. Their future plans, such as interface types, can potentially approach the complexity of the JVM and CLR object models, but with more isolation boundaries (because memory isn't shared between modules).
Unless screen readers can now dive down into the canvas layer?
If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough for most applications to matter. Especially if those applications are written in anything other than C/C++, they'll have similar performance characteristics.
Obviously, for such a wide prediction I can only speak theoretically...
Text recognition is getting pretty good nowadays afterall.
As a web-development near illiterate, this equals to me as pages that aren't auditable before they're shown, which would pretty much translate into unblockable ads. Please someone tell me I am wrong.
If you switch off javascript then the WASM files won't be able to be loaded.
Then on top of that I guess you could just filter for all `canvas` elements. That will cripple some [biased edit: worthwhile] uses at the same time, though.
The modern web already burned that bridge and loudly declared that it doesn't give two shits about accessibility. There are plenty of companies that gladly sacrifice accessibility to have "beautiful" interfaces designed by some self-important jackass.
There will also be performance problems. The web is already slow using the heavily optimized DOM. It's going to be so much slower when things try to use a fullscreen Canvas instead. That breaks all sorts of optimization opportunities browsers currently leverage.
But sadly it'll probably happen. We'll all end up downloading forks of browsers in various states on each site we go to as each site decides to re-invent the DOM & all the rendering optimizations that go along with it.
I know nothing about webm beyond the idea that it's supposed to help developers write code in non-Javescript languages which can then be run in a web page via a canvas element. If my scant understanding is correct, then I assume it will be up to those developers to include code (or relevant libraries in each language) that will make the canvas element act responsively, and handle issues like accessibility, user interaction, tracking etc to give the best user experience?
My view is that current Javascript libraries that target the canvas element have largely failed to address canvas-related issues such as accessibility in a decent way - which doesn't give me much hope that future webm libraries which could be used to build user interfaces will do any better ... unless there's strong pressure to make accessibility a core goal for such libraries.
There's no good reason not to include accessibility (and user interaction, tracking etc) into any library - including JS libraries - that target the canvas element. Part of the reason for me recoding my own JS canvas library was to address exactly these issues (results of my work here[1]), and if I can manage to solve a lot of the issues then there's no reason why others library maintainers couldn't do a much better job of it than I did!
Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.