101–110 of 110 posts
Earlier quoted context omitted.
What’s old is new again. Edge devices running bytecode has its uses. Being an old idea doesn’t discredit it (neural networks were first described in the 70s) At least WASI is a standard unlike flash or Java applets.
De facto standard is still a standard.
Maybe “open spec” or “open standard” is better.
Earlier quoted context omitted.
I'm answering a comment of yours that exclusively mentions CLI. You can't blame anyone for not reusing the un-reusable. You are not contradicting me on this so let's forget about CLI, it doesn't matter it was done before since it's not a viable option or wasn't at the time WASI was being created. Or actually refute this if you think this is wrong. Now, you are extending the scope to "all bytecode formats ever created…
I don't have time to waste teaching history of bytecodes to those that think WebAssembly is the be all, end all of bytecode formats. Whatever you consider me to be, it is your opinion, keep it for yourself, share it with the world, whatever.
I have no particular opinion about you, in particular nothing against you.
Sadly, still no Framebuffer API for WASI GUI apps ( https://github.com/WebAssembly/WASI/issues/174 ).
Sadly, still no Framebuffer API for WASI GUI apps ( https://github.com/WebAssembly/WASI/issues/174 ).
There's something related WASI GUI apps that I've been working on for the last few months. Hope to provide details soon.
Earlier quoted context omitted.
I'm in the same boat. I've been looking at this space since (P)NaCL With a nagging question in my mind: What does this do that we couldn't do with Java Applets? So far the response is very few things and a lot less. On the few things that it does differently is: + it focus on multi language support. as opposed to the JVM which was focused in getting all of us in writing Java. Here they want to actually use different…
Security. Applets exposed massive API surface while wasm exposes almost nothing. Also applets were too slow to start with Sun's implementation of the day while wasm works reasonably well in all browsers from day one. That matters a lot for adoption. JVM improved but applets missed their chance. You only get one.
WASI starts with nothing and then exposes a bit more. WASI2 exposes more than WASI1. Preview 3 will also add more. Eventually there will be sandbox escapes in WASM runtimes as well. There's nothing about WASM that makes sandbox escapes harder.
Bear in mind, applets exposed a large surface area, because you need that to write useful apps. Currently WASI looks useful for, maybe, some subset of CLI tools. Everything else is kicked to Chrome. It's not as ambitious.
Earlier quoted context omitted.
This does such a good job laying out the real fundamentals of what's happening. Capabilities model, component-model; it's well covered and nicely tied together. The WasmCom keynote What is a component? (and why?) by Luke Wagner is also a great intro. https://youtu.be/tAACYA1Mwv4
If you are looking for one video in this thread to watch this is it. ^ Luke crushed it.
Earlier quoted context omitted.
The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get exist…
Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use). When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practic…
About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…
For WASM in the browser I'd gesture at Figma for a economically viable product. From my own perspective, which is browser based games, WASM opens up a lot of options. From using battle tested physics engines that are written in systems languages to the ability to access SIMD primitives. One of the underrated capabilities from that perspective to me is that floating point math is deterministic across browsers and plat…
This is interesting and relevant to me. Do you have any suggested links where I can read more about this aspect of wasm?
Earlier quoted context omitted.
This is called PWAs. They are easily installable and can contain WASM.
No. PWAs are not a thing on desktops, they still need the entire browser, and they are still just a browser page. That's a far cry from what JavaFX enabled.
Or is my understanding of JavaFX incorrect, and it somehow turned applets into native binaries when you dragged them out of the browser?
Earlier quoted context omitted.
No. PWAs are not a thing on desktops, they still need the entire browser, and they are still just a browser page. That's a far cry from what JavaFX enabled.
JavaFX programs needed the Java runtime too, and they were still just Java apps. How is the JRE different from Safari or Edge? Or is my understanding of JavaFX incorrect, and it somehow turned applets into native binaries when you dragged them out of the browser?