[HN Gopher] WASI 0.2.0 and Why It Matters
___________________________________________________________________
WASI 0.2.0 and Why It Matters
Author : brooksmtownsend
Score : 115 points
Date : 2024-01-26 14:35 UTC (8 hours ago)
(HTM) web link (wasmcloud.com)
(TXT) w3m dump (wasmcloud.com)
| niutech wrote:
| Sadly, still no Framebuffer API for WASI GUI apps
| (https://github.com/WebAssembly/WASI/issues/174).
| ilaksh wrote:
| I have always suspected that sort of thing is somehow blocked
| by Google because it would make mean web assembly runtimes
| don't need web browsers.
|
| Although now that there is actually a significant update to
| WASI, perhaps it's possible that they are just actually that
| slow? Or maybe both are true.
|
| Probably I am just a "conspiracy nut". I mean I definitely am,
| but in this case it might just be paranoia.
| baq wrote:
| I hope safari implements these things so I could reasonably
| run a wasm build of firefox on ios
| phickey wrote:
| WASI Co-chair here. Nothing in WASI is "somehow blocked by
| Google", or indeed blocked by anyone at all. Graphics support
| in WASI hasn't been developed simply because nobody has put
| energy into developing graphics support in WASI.
|
| At the end of 2023 we counted around 40 contributors who have
| been working on WASI specifications and implementations: http
| s://github.com/WebAssembly/meetings/blob/main/wasi/2023/... .
| That is a great growth for our project from a few years ago
| when that issue was filed, but as you can see from what
| people are working on, its all much more foundational pieces
| than a graphics interface. Also, if you look at who is
| employing those contributors, its largely vendors who are
| interested in WASI in the context of serverless. That doesn't
| mean WASI is limited to only serverless, but that has been
| the focus from contributors so far.
|
| By rolling out WASI on top of the WASM Component Model we
| have built a sound foundation for creating WASI proposals
| that support more problem domains, such as embedded systems
| (@mc_woods and his colleagues are helping with this), or
| graphics if someone is interested in putting in the work. Our
| guide to how to create proposals is found here: https://githu
| b.com/WebAssembly/WASI/blob/main/Contributing.m... .
| nynx wrote:
| Framebuffers aren't really a useful abstraction anymore. They
| can be implemented on top of webgpu anyway.
| ilaksh wrote:
| That's amazing to see those things in WASI finally.
|
| But they also mention components. Does that mean components are
| part of the web assembly standard now?
|
| And am I correct in assuming that components are an option for
| projects where the functionality of WASI still isn't adequate?
| mc_woods wrote:
| 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 existing
| wasi binaries to run preview2, and of course, preview2 binaries
| won't work on non-preview 2 runtimes...
| flohofwoe wrote:
| 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
| practice.
| zilti wrote:
| There is WASIX as a "POSIX for WASM"
| callahad wrote:
| For folks looking to learn more, the Component Model
| documentation is pretty good! I like this excerpt for
| explaining the core vs component split:
|
| > _components interact only through the Canonical ABI.
| Specifically, unlike core modules, components may not export
| Wasm memory. This not only reinforces sandboxing, but enables
| interoperation between languages that make different
| assumptions about memory - for example, allowing a component
| that relies on Wasm GC (garbage collected) memory to
| collaborate with one that uses conventional linear memory._
|
| Link: https://component-
| model.bytecodealliance.org/design/why-comp...
| flohofwoe wrote:
| Hopefully it's trivial to push C structs around by value if
| poking around in other instances memory isn't allowed.
| Otherwise it sounds like a lot of hassle just to appease
| "fringe languages" ( ;P ) that don't have a linear memory
| model. This sort of "directly reading and writing the WASM
| heap" is quite essential for JS code that sits between a
| WASM instance and a web API for instance (in the "WASM in
| browsers" scenario).
|
| ...for instance how do you share large amounts of data
| between components then, there _must_ be some sort of cheap
| way to safely share portions of memory between components
| right? Because there are situations where multiple copy
| steps are simply out of question.
| boomskats wrote:
| If you watch the video I linked to in the sibling
| comment, Luke addresses that exact question around 21
| minutes in. The WIT spec I also linked to talks about
| resources and handles in some depth.
| boomskats wrote:
| I thought this keynote presentation[0] by Luke Wagner at
| Wasmcon was great and covered it very well. I also found
| the WIT Format design doc[1] in the component model repo to
| be the most complete explanation of how it's all going to
| hang together.
|
| [0]: https://www.youtube.com/watch?v=tAACYA1Mwv4 [1]:
| https://github.com/WebAssembly/component-
| model/blob/main/des...
| mnemonik wrote:
| Yes, you can use the component model (and other tooling like
| WIT) without using WASI.
|
| Yes, the component model is a standard developed under the
| umbrella of the W3C's WebAssembly Community Group.
|
| That said, while it is relatively stable and hasn't changed
| much in the last year or so, the component model has not
| graduated through all the phases of the standardization process
| yet. It doesn't, for example, have a formal specification yet,
| although its canonical ABI does have a reference implementation
| in Python.
|
| https://github.com/WebAssembly/component-model/
| PedroBatista wrote:
| 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
| perspective.
|
| For SO MUCH effort over a decade I feel it's more and more a nerd
| kingdom where it's full "of cool things" and much more work on
| creating and resolving problems that were solved years and
| decades ago and I still miss the point of all of this, I get the
| "big promise" but 10 years have passed and still nothing.
|
| Also, I see a lot of Rust ( and I mean a lot ) attached to Wasm.
| Sorry but it's not going to happen, it just isn't. Rust is a
| systems programming language and Wasm has been pretty much
| another eternal tech demo. Real "mid" - as the gen-z says - use
| cases and products are needed and Rust is not going to cut it for
| a general product audience. This whole thing seems more like a
| "Run Rust in the browser" than a common runtime to run every
| language in the browser.
|
| And since "running stuff on the browser" is kinda of old news,
| these new "wasm runtimes" ( which I get it and support ) in
| reality are basically a basic shitty proto-JVM.. again what's the
| point of all of this having spend 10 years?
|
| The "devx" ( always a sucker for a new marketing term :) ) is
| HORRIBLE! Ever tried to compile a moderately complex ( and useful
| ) C program to wasm?
|
| On a positive note, I wish success to Wasm/WASI because it's a
| cool idea and can open a lot of doors. If not for the actual
| reality and implementation of things, I'm optimistic about the
| general idea.
|
| Sorry for my "ignorance" and if I hurt anyone's feelings.
| fwsgonzo wrote:
| I have had the same experience compiling for WASM. It's always
| a bunch of commenting out code that doesn't compile. Thankfully
| we have other things backend side. I'm guessing people writing
| Rust are having a better time with WASM.
|
| As far as WASM going away: Sadly, I think browsers are just
| going to make up a larger and larger share of what computers
| do.
| cornstalks wrote:
| One realistic use case I'm currently exploring is game
| scripting with Wasm. I don't want to write Lua. And I don't
| want modders to be compelled to use some specific scripting
| language.
|
| If I use Wasm in my native game then it's easy for modders and
| others to create their own scripts and mods that can then be
| compiled to machine code by the game and safely executed on
| others' computers. They don't have to trust the modder because
| Wasm's sandboxed design protects against a lot of bad
| behaviors.
|
| It's not so much that Wasm is totally unique here. Rather, to
| me it has many of the features and attributes I'm looking for
| in one single package/technology.
| make3 wrote:
| We've seen a lot of ppl write electron apps because they're
| portable. I see this as electron/jvm for code that already
| exists in non vm languages, so that in theory you don't need to
| do nearly as much rewriting, or any at all. that's pretty cool.
| PedroBatista wrote:
| Yes, that's the idea. In theory.. :)
| flohofwoe wrote:
| I recently made a command line assembler tool written in C
| in the early 90's run in a VSCode extension via WASI just
| by compiling with the WASI SDK, IMHO that's pretty cool:
|
| https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html
|
| (same with my home computer emulators, but those were
| written right from the start with the web as "just another
| platform" in mind: https://floooh.github.io/tiny8bit/)
| rockwotj wrote:
| I have compiled JQ to wasi (in terms of moderately complex (
| and useful )).
|
| Took me a couple of hours, mostly because of some pthread stuff
| I had to noop. And that's being fixed with wasi-threads
|
| https://github.com/rockwotj/jq-wasi
| mc_woods wrote:
| unfortunately wasi-threads is deprecated. You'll need to wait
| for threading support from "core-wasm" and that's a while
| off, there is no date on the horizon for this, as far as I
| know.
|
| WASI-threads is not compatible with WASI-Preview2
| rockwotj wrote:
| Thanks for the correction! It's hard to track all of this
| :)
| flohofwoe wrote:
| Might be part of the nerd kingdom for you, but I recently made
| pretty cool use of WASM+WASI in a VSCode extension:
|
| https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html
|
| Also quite a few 'CPU nerds' found my 'visual6502 remixes'
| useful so far:
|
| https://floooh.github.io/visual6502remix/
|
| https://floooh.github.io/visualz80remix/
|
| Development experience with Emscripten and WASI SDK is fine
| really (in the sense that these are "just another gcc-style
| cross-compilation toolchain"), and with those it's not much
| different than bringing a C code base to any other platform. It
| depends a lot on how portable the code is in the first place of
| course.
| boomskats wrote:
| I read your post on WASM debugging with Emscripten and
| VSCode[0] just last week, thought it was amazing!
|
| Not quite the same, but tangentially related since we're
| talking WASM+WASI and VSCode extensions - I have high hopes
| for the vscode-wasm[1] project. The VSCode extension host is
| a massive hog, and this seems like a big step in the right
| direction.
|
| [0]: https://floooh.github.io/2023/11/11/emscripten-ide.html
| [0]: https://github.com/microsoft/vscode-wasm
| flohofwoe wrote:
| Yeah, this vscode-wasm thingie is exactly what I'm using to
| run a command line assembler tool in VSCode. Pretty neat,
| only downside currently is that it is only available as
| pre-release, which makes installing extension which depend
| on vscode-wasm awkward for the user.
| callahad wrote:
| You almost certainly use WebAssembly today in widely deployed /
| commercial products without realizing it.
|
| Figma, Microsoft Flight Simulator, Disney+, Amazon Prime Video,
| Photoshop for Web, 1Password, and uBlock Origin all implement
| significant portions of their applications as WebAssembly
| modules.
|
| Many of those examples are building their Wasm modules from
| Rust codebases.
|
| From what I can see, Rust and Wasm have undeniably crossed the
| chasm into pragmatic, mainstream applications. The serverside
| Wasm ecosystem is still nascent, but that's what initiatives
| like WASI and the Component Model are designed to address.
| Yesterday's vote to launch WASI Preview 2 is a huge step
| towards building a stable, interoperable foundation for
| WebAssembly outside of web runtimes.
| galangalalgol wrote:
| Ruffle is a good example too. It brought most of the old
| flash content back to the web in a safe sandboxed way. To the
| point I could see people using the old adobe tools to make
| new content, if they haven't already.
| mc_woods wrote:
| There are compelling applications for WASM in the embedded
| space, here we run C / C++ applications and WASM supports this
| well. We can also run other languages compiled to WASM too.
|
| On the server side this is less clear. Typically we don't write
| system level languages server side - we use other languages,
| like Ruby, Python, JavaScipt etc. These interpreted languages
| can run in WASM, but only as language interpreter inside the
| WASM interpreter - so they work, but they are not efficient.
| The benefit to the cloud / infrastructure provider is often
| not-clear, not when it's possible to run these very same
| applications in existing infrastructure. On the server side the
| benefit to the application developer is also not clear. There
| are few providers who have infrastructure to support WASM
| applications directly. You'd really need to see the big 3 cloud
| providers look at supporting WASM directly, without hypervisors
| / vm / container technology under it, to realize any
| performance improvements and hence pass on some cost benefit to
| the developer ecosystem.
|
| "running stuff in the browser"; isn't old news. There are a
| growing number of applications that are migrating toward web-
| based UI and for these WASM is really useful. WASI-Preview2's
| benefits are not going to be realized in a browser, it's more
| for the non-web world....
|
| Rust-Focus; yes, you are correct the existing technology, with
| the exception of perhaps WAMR and CloudEdge runtimes are rust
| based. As WasmTime is the only standalone technology which
| currently supports preview2, and it's written in rust, then the
| associated examples and tooling are naturally rust focused.
| phickey wrote:
| > WASI-Preview2's benefits are not going to be realized in a
| browser, it's more for the non-web world
|
| The jco project (https://github.com/BytecodeAlliance/jco)
| provides an implementation of the Component Model and WASI
| Preview 2 for JavaScript systems. Right now, node.js support
| is complete, but support for Web embeddings is in progress
| and coming soon.
|
| > These interpreted languages can run in WASM, but only as
| language interpreter inside the WASM interpreter - so they
| work, but they are not efficient.
|
| The Bytecode Alliance has made big improvements to
| SpiderMonkey performance on WASM/WASI systems, and has work
| in progress to take advantage of SpiderMonkey's "native"
| codegen targeting WASM:
| https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We
| targeted JS first for this work because it is the most
| popular language with our customers and users, but we expect
| that this will show the path to adding similar improvements
| to Ruby, Python, and other languages commonly thought of as
| "interpreted".
| meheleventyone wrote:
| 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 platforms which is a bit of a
| holy grail for multiplayer games programming. Beyond that it
| promises to get faster and more efficient over time which is a
| good thing for performance heavy web apps.
|
| Outside the browser MS Flight Sim uses WASM for the UI in part.
| WASI I know less about but doesn't seem totally crazy and in
| comparison to things like the JVM has a broader set of
| languages that can use it.
| ramses0 wrote:
| So..... think of it this way:
|
| HTML was built for the "internet", but works just as well for
| plain local files (eg: file:///one.html => file:///two.html).
|
| JS was added to HTML, and much gnashing of teeth ensued.
|
| JS (minified), HTML (generated), CSS (compiled), Flash, Java
| Applets, etc... move away from the "original" internet (Hyper-
| Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens".
|
| What if instead of shipping `my_application.html`, we could
| ship `my_application.exe`, and "break free" of needing the UI's
| being written in HTML, JS, CSS, etc.
|
| What some of this WASM/WASI/etc... seems to be trending towards
| is building up enough of a foundation amongst interoperable
| _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and
| instead you get much closer to: curl
| 'https://example.com/one.html' => curl
| 'wasm://example.com/one.app'
|
| ...to the extent that "the internet" has hit a complexity wall
| of what's possible (manageable, maintainable) with HTML+JS+CSS,
| the people tackling WASM seem to be saying:
|
| Forget trying to coerce a buggy browser into running my `for
| ...` loops (and rendering my graphics) correctly, and you can't
| realistically decompile or hand-edit the HTML+JS+CSS for 99.9%
| of the stuff your browser is rendering... how can we _skip_ the
| HTML,JS,CSS and get directly at "the VM" and run what we
| actually want.
|
| Secondarily (but importantly, and interestingly): How can we
| make 'webapp.wasm.exe' support everything that a "native" app
| would need (eg: GL, GPU, Bluetooth, Local Files, USB devices,
| Camera, Sensors, etc...)
|
| There's likely mega-trillions (no exaggeration!) of effort
| that's been poured into tooling for "the internet", what is the
| unifying effort/effect that would unlock that for local app
| development? How can I get `msword.exe` to run "on the
| internet" for free? How can I get `make clean ; make install ;
| make wasm` working for any internet connected client?
|
| As a thought experiment, we're almost there! We could
| technically have `win95.img + bochs86vm.wasm + autorun.inf +
| msword.exe` wrapped in a "browser evaluator" that could
| conceivably run `msword.exe` transparently to the user, but
| still allow you to use `msword.exe` indistinguishably from the
| "original" native app (bridging the local filesystem, exposing
| virtual devices, etc).
|
| See also https://www.destroyallsoftware.com/talks/the-birth-
| and-death... ... circa a decade(!) ago!
| dns_snek wrote:
| > As a thought experiment, we're almost there! We could
| technically have `win95.img + bochs86vm.wasm + autorun.inf +
| msword.exe` wrapped in a "browser evaluator"
|
| I looked into this and... holy crap! We _are_ there. Not for
| modern programs quite yet, sure, but this is amazing. You can
| use Windows 2000 from your browser, running inside an x86
| emulator for WASM.
|
| https://copy.sh/v86/?profile=windows2000
| crq-yml wrote:
| As it is, I already run a Debian VM locally to seal off the
| "development" stuff from my primary desktop.
|
| Is is kinda heavy? Yeah. The hard disk footprint is
| substantial. But it works fine for writing some Python,
| compiling a few dependencies and bringing up a browser to
| test stuff. Even on a six-year-old laptop, it runs OK.
|
| If the client application needs 1990's capabilities, "chuck
| it in a VM" will work today, and it will only be limited by
| protocol support, I/O access, and OS integration. There are
| substantial accessibility problems presented by VMs -
| seemingly basic things like clipboard support are
| disagreeable and require a "smart emulator" inserting
| itself to provide that feature.
|
| Perhaps the right direction to take is to develop MAME to
| contain every accessibility feature. It already emulates
| all the old hardware.
| ramses0 wrote:
| Yup! ...and noodling around with their `wordpad.exe`, you
| could pretty easily imagine `My Network => My Workgroup =>
| ...etc...` to samba-share in your local filesystem
| (provided by the bochs86vm "container") ....... or since
| it's turtles all the way down, just map your local computer
| drive as `D:\\...` and let the VM "think" it has access to
| all your files on the vm-local disk.
| elviejo wrote:
| 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 languages to write webapps. - Although Rust is
| the favorite (As is C# in the .net) + It has a clear mechanism
| to communicate with Javascript and therefore the web. + timing
| bandwidth is now big enough to make this apps seem practical. +
| it is done by a coallition of vedors (as opposed to java that
| was only Sun's baby).
|
| Very minor advantages in my opinion... but well I also think
| that lip's s-expressions are better than json, xml and yaml.
| and the world has thought differently every single time.
| marwis wrote:
| 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.
| G4Vi wrote:
| On the devx, there's definitely some rough edges around
| building and using Wasm. My company has been working on a
| framework to ease integrating Wasm into existing applications.
| One area it focuses on is providing easy data passing between
| the host program and the Wasm and vice versa.
| https://github.com/extism/extism We do not have WASI preview 2
| support yet, but are interested in integrating it.
| shadowgovt wrote:
| At a glance (at this blog post, and at the WASI project on
| GitHub) I still can't quite wrap my head around what WASI _is_
| and why it matters.
|
| What problem is it solving?
| arccy wrote:
| your holy pure functions are a bit useless if they can't
| interact with the world (system)
| 0x457 wrote:
| WASM is a language. By itself, it's not very useful because
| you're limited to what language constructs provide - not much.
|
| There are extensions to the core spec for embedding wasm. For
| example, there is "WebAssembly JavaScript Interface" for
| working with wasm inside JavaScript, which is what used by
| browsers today.
|
| Spec we use in browser today is really just about how to
| interact with JS, so JS must provide everything that isn't in
| core: want to make an http request, then you need to call
| JavaScript (i.e. Fetch API) and so on.
|
| People wanted to run WASM outside the browser because it's a
| neat abstraction - compile one of the many languages to WASM
| and run it "anywhere" (yay java).
|
| Since outside the browser, we can't lean on JS for providing
| access to the outside world, plus that bridge has an overhead,
| so no bueno. WASI extends core spec with interface to outside
| system:
|
| - files i/o
|
| - network i/o
|
| - etc
|
| In addition, WASI has a built-in capability framework (a la
| Capsicum in FreeBSD which it drew inspiration from).
|
| So WASI is a interface to a host system with security and
| isolation in mind.
| shadowgovt wrote:
| Ah, okay. That _is_ cool. It doesn 't solve a problem I have
| (if I'm compiling to a target outside the browser, I'm going
| to compile to LLVM --> native, not wasm) but I respect why
| that's exciting.
| v7n wrote:
| You can write a program that has the capability to run
| isolated WASM modules written by others, without caring
| about the source language. Export some functions from your
| host program and you have a neat system for, say, user-
| written extensions.
| andoband wrote:
| Another good write-up which gives more context to this release,
| and it touches on POSIX in relation to the component model.
|
| https://blog.sunfishcode.online/wasi-preview2/
| dom96 wrote:
| Thanks for sharing. I often wondered why we didn't just create
| a subset of POSIX for the web and wasm, this seems to answer my
| questions.
| elviejo wrote:
| Other team ask themselves that question and created WASIX.
| I'm looking into it.
|
| Because to me it seems only logical, to have POSIX that can
| work on the web.
| 0x457 wrote:
| This is about WASI and WASI is outside the web browser.
| phickey wrote:
| WASI Co-chair here: WASI is for the Web as well as
| beyond. The jco project
| (https://github.com/BytecodeAlliance/jco) provides an
| implementation of the Component Model and WASI Preview 2
| for JavaScript systems. Right now, node.js support is
| complete, but support for Web embeddings is in progress
| and coming soon.
| jauntywundrkind wrote:
| 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
| 6gvONxR4sf7o wrote:
| I really want polyglot programming to become easier. What are the
| barriers remaining for wasm/wasi to provide a foundation for a
| truly polyglot FFI? It seems like it was the promise from the
| beginning, but I lost track a long time ago.
| noworriesnate wrote:
| Extism is a polyglot plugin framework that has support for a
| lot of languages. It supports passing strings back and forth
| but that's it for now IIUC. I've started incorporating it into
| a project of mine and really like it.
| jauntywundrkind wrote:
| Now that there's a canonical ABI as specified by component-
| model, it seems like the good work can start.
|
| As recommended elsewhere in the comments, there's a pretty
| damned fine talk my Luke Wagner that covers wasm components &
| the promise. He talks about cross-platform was 18m35s in:
| https://youtu.be/tAACYA1Mwv4#t=18m35s
| n42 wrote:
| I'm by no means an expert here, but it seems with WASI preview
| 2, component model, and GC all converging around the same time,
| things are looking more optimistic than ever
| childintime wrote:
| Fermyon is practicing it. Initial stages, awaiting finalization
| of the standards, but it works.
| spankalee wrote:
| I'll be very happy when Preview 3 with async support is out.
|
| GC + async makes WASM a suitable runtime for languages like
| JavaScript and Dart so that we don't have to have JS + WASM
| runtimes where the JS doesn't integrate with WASI well, or WASI
| runtimes that don't support JS that well (compiling SpiderMonkey
| to WASM isn't great).
| phickey wrote:
| We have already made big improvements in using SpiderMonkey on
| WASM, and have more work in progress that will enable
| SpiderMonkey to have "native"-like codegen for WASM:
| https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/
|
| An additional benefit of using a fast JS runtime inside of
| WASM, even on a WASM engine that natively supports JS, is to
| use a Wasm Component as a security boundary around JS code.
| This could be used as an means of isolating supply-chain
| security issues, or allowing users to provide (untrusted) JS
| code that extends an existing system while having a clear and
| strong boundary on how untrusted JS code can affect the host JS
| code.
| zilti wrote:
| I wish we'd get what JavaFX promised: Programs running in the
| browser that can be installed by simply dragging them out of the
| browser.
| ImHereToVote wrote:
| Does anyone know if there are discussions on integrating
| WebAssembly into actual OS's? Would be great to have something
| that Java promised to be, but wasn't.
| MR4D wrote:
| > "The simplest "hello world" example looks like..."
|
| And then gives code that reminds me of Enterprise JavaBeans from
| the early 2000's.
|
| Thankfully, later on we get:
|
| > "Let me show you an example of the ideal Wasm hello world
| application..."
|
| And then have code that's clean, logical, and simple to read.
|
| TBH, I almost gave up after seeing that first bit of code, but
| thankfully I kept reading. Having a standard interface will go a
| long way to creating a very nice future.
| andybug wrote:
| Props to the team, this is great work.
|
| I've been trialing Preview 2 for the last couple of months to
| good results.
|
| I do have one problem though and can't seem to find a good way
| forward. My use case is to use WASM for the data processing
| modules in a tile-based simulation game/engine. This involves
| passing around large (many MB) buffers. For any semblance of
| performance the data cannot be copied between modules and needs
| to be passed by reference.
|
| To that end, I've implemented Resources. However, getting data
| out of a resource still requires copying (wasm-bindgen makes the
| return types from accessors owned Vec<>). I've resorted to just
| passing u32 memory offsets since all of the modules are sharing
| one Memory.
|
| Would love some guidance on this as I've scoured the Internet and
| simply can't find the right solution, if there even is one.
| phickey wrote:
| The bytecode alliance zulip is the best place to discuss that:
| https://bytecodealliance.zulipchat.com/
___________________________________________________________________
(page generated 2024-01-26 23:02 UTC)