31–40 of 238 posts
Love it. This could be a huge innovation and really push the dream of cross platform development to the next level. I suppose this would have pretty big implications for Electron or a similar successor to aid in the UI portion of this endeavor.
Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).
Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises?
I'm asking honestly - why is WebAssembly outside of the browser needed?
Earlier quoted context omitted.
Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).
Properly sandboxed VM that you can compile practically any language into?
ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises? I'm asking honestly - why is WebAssembly outside of the browser needed?
ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises? I'm asking honestly - why is WebAssembly outside of the browser needed?
The idea of isolation that java espoused is not a bad one - it just wasnt executed well. Its not a java only idea either - see Native Client[0]. As with all things, execution and marketing matter. Java was lacking in both. [0] - https://static.googleusercontent.com/media/research.google.c...
Java still exists and is a valid deployment platform.
Why is WebAssembly outside of the browser needed?
1. Backwards compatibility with existing libc. (Maybe pick musl)
2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD
#1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross platform capabilities without multiple codebases. Specifically, don't repeat what node did: digress from browser js semantics, instead of polyfilling them
Here's a link: https://github.com/gwsystems/silverfish -- although the README is pretty sparse, so you'll have to look at the code.
Excuse me if I come across as naive, I'm kind of a noob on these architectural topics, but how is this different/better than what the JVM is/accomplishes? When WASM first popped up I thought about the similarities with Java Web Applets and Flash.
1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…
Love it. This could be a huge innovation and really push the dream of cross platform development to the next level. I suppose this would have pretty big implications for Electron or a similar successor to aid in the UI portion of this endeavor.