[HN Gopher] Wasmer JavaScript SDK
___________________________________________________________________
Wasmer JavaScript SDK
Author : the_duke
Score : 96 points
Date : 2023-12-21 18:38 UTC (4 hours ago)
(HTM) web link (wasmer.io)
(TXT) w3m dump (wasmer.io)
| mgomez wrote:
| I've yet to dip my toes into Wasm. This might push me to finally
| get going. Based on a quick search, Wasmer and Wasmtime appear to
| be the two most popular runtimes with the latter being backed by
| some big names (via the Bytecode Alliance). Wasmer seems to push
| new features first. Can someone share what their experience was
| like with either or why they chose one over the other?
| JoshTriplett wrote:
| wasmtime is closely aligned with where active development is
| happening in WebAssembly, WASI, and similar standards. You can
| expect that as the folks working on WebAssembly itself
| establish support for (for instance) async, or GC, or
| components and linking, or other new APIs, wasmtime is where
| those are going to show up first and be aligned with the rest
| of the industry. It's easy to embed and reasonably easy to
| expose your own APIs through, so that you can use it for
| plugins.
|
| The community is also friendly and inviting for folks trying to
| get started.
| Conlectus wrote:
| In my experience Wasmer is generally disliked by the rest of
| the WASM community. There's a long list of reasons for this,
| including attempting to copyright the term WASM and pushing
| their own proprietary specs and calling them "standards" while
| not implementing existing standards.
|
| Their main benefit, from what I can tell, is their
| "retargetable" compiler architecture, but Wasmtime is improving
| here as well. Wasmtime is also generally faster at implementing
| standards.
| syrusakbary wrote:
| I wish to live the day where we can incentivize one ecosystem
| without having to trash another.
|
| This is not a zero-sum game.
|
| If you find Wasmer useful, use it! If you don't and you
| prefer others, feel free to use them. There are plenty of
| choices.
|
| Happy holidays!
| theplatman wrote:
| I would say that this landing page on your company's
| website is unnecessarily trashing wasmtime in the headline
|
| https://wasmer.io/wasmer-vs-wasmtime
| k__ wrote:
| Preaching water, drinking wine.
|
| Classic.
| syrusakbary wrote:
| No intend of trashing (in marketing pages titles tend to
| be more flashy).
|
| In any case I just updated it. Happy holidays!
| aleksiy123 wrote:
| Is it just me or is it weird to show a faster startup
| speed as a bigger bar?
|
| I thought it was slower until I saw the 1000x. Even 1000x
| seems kinda meaningless.
| noduerme wrote:
| >> _we were able to allow UNIX-like threading to run via JS
| Workers by reusing the shared memory from the main WebAssembly
| process and notifying the memory upon changes (using Wasm notify
| /wait syntax)._
|
| This left me scratching my head. How are JS workers sharing
| memory with the WASM process?
| kevingadd wrote:
| JS has an API called "SharedArrayBuffer" that allows sharing
| memory between processes or threads (with the aid of the host)
| temp123789246 wrote:
| I wonder how much of a perf hit a normal multithreaded Unix
| application would take because of this model. Are there any
| data points around the multi-threading perf here?
| chatmasta wrote:
| I believe JS workers are actually implemented as threads, so
| the performance overhead might not be as bad as you'd expect.
| syrusakbary wrote:
| Usually it adds an extra 10-25% of overhead when the WASIX
| program uses systemcalls that require unwind/rewind
| functionality (this is for fork and subprocesses mainly, the
| multithreaded ones doesn't require asyncify and as such
| should not experience a performance hit)
| unsupp0rted wrote:
| Similar to ffmpeg, I wonder if I can have the user's browser run
| a puppeteer instance in Wasmer?
|
| E.g get it to generate a PDF for the user to "download"
| syrusakbary wrote:
| That would be awesome! Although there are still a few edges to
| resolve to be able to run a full headless browser with Wasmer.
|
| It should be possible though, see:
| http://trevorlinton.github.io/
| grose wrote:
| I use @wasmer/wasi for my npm package `trealla` (wasm port of a
| Prolog interpreter). For the most part I'm pretty happy with it,
| but the file size is quite large[1] (taking up around half my
| bundle size), and it looks like @wasmer/sdk is even larger
| (wasmer.sh downloads a 1.7MB gzipped wasm binary that I assume is
| the runtime). It's a tough sell to the frontend folks when my
| package is this big... currently I have my eye on jco[2] which I
| hope will be much lighter.
|
| No shade intended towards the Wasmer folks, I appreciate the work
| they've done.
|
| [1]: https://bundlephobia.com/package/@wasmer/wasi@1.2.2
|
| [2]: https://github.com/bytecodealliance/jco
| syrusakbary wrote:
| Thanks, I'm a big fan of your work in Trealla. Is true that
| there's still room to improve sizes, as right now the bundle
| size is not ideal.
|
| Hopefully it will not take long for Wasmer to serve packages
| with a minimum bundle size, stay tuned for updates!
| grose wrote:
| Thank you as well! I am looking forward to it, will keep an
| eye out & would be happy to test. I know it's difficult to
| keep the packages small, I struggle with it for sure (e.g.
| currently I use Wizer to optimize my startup times, but that
| also takes a significant chunk of the bundle).
| solarkraft wrote:
| One interesting thing their examples seem to offer is a pre-
| configured Vite/Rust toolchain. This is something still lacking
| in official Rust/WASM examples and something I had to put quite
| some trial and error into to get working (with auto-reloading and
| such).
| mattlondon wrote:
| Can anyone confirm if this can do proper TCP sockets? Not
| Websockets, but bonafide actual sockets?
|
| That will open up a lot of use cases (at least for me)
|
| It seems to say it can run _any_ wasix, so yes? But GitHub page
| says no networking, so no?
| syrusakbary wrote:
| In the browser not yet, but support for TCP is on the roadmap!
| Feel free to email me at syrus@wasmer.io so I can keep you in
| the loop for the first trials :)
| jeffparsons wrote:
| One way to approach this would be to interpose all calls to the
| TCP interfaces (pretty straightforward with Wasm Components),
| and tunnel it using Websockets (or whatever) to a server that
| can make the actual TCP connections on your behalf. So the
| application running in Wasm doesn't know any different, at
| least.
|
| I guess that's not quite what you wanted, but browsers don't
| allow making arbitrary direct TCP connections, so in general I
| don't think there _is_ a way to do what you wanted.
___________________________________________________________________
(page generated 2023-12-21 23:00 UTC)