Correct me if I’m wrong but the memory copying issue is not an issue if you pass an array buffer into WASM from JavaScript. In that scenario there’s no data copying. E.g. similar to how you’d pass the canvas data to WASM for direct manipulation.
Reality Check for Cloudflare Wasm Workers and Rust
11–20 of 59 posts
Re: Reality Check for Cloudflare Wasm Workers and Rust
#12Earlier quoted context omitted.
I for one hadn't thought about the cost of shipping your own standard library with every bundle, so it was informative for me
WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.
That's fair, but still, you'll be pulling in a lot of really fundamental stuff that JavaScript gets for free. String manipulation, fundamental data structures, iterators, HTTP, JSON (de)serialization, etc.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#13> I guess I’ll stick with my error prone Javascript Workers or, more likely, spend an afternoon migrating to a minimal Typescript setup. If the OP wants a zero-config typescript experience (assuming Deno isn't available on Cloudflare workers), I can't recommend esbuild enough
There's also js_of_ocaml if a good type system is desired.
I think that's out of scope for the OP's needs/wants. They like TypeScript for catching basic API mistakes, the only thing they don't want is configuration headaches. I didn't get the sense they would be interested in learning a new language for this use-case, especially since I'm going to guess Cloudflare doesn't publish OCaml types for their JavaScript API.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#14I believe a zip file could be streamed - most of the file metadata is duplicated between both the 'central directory record' trailer and a header in front of each file. In other words, the first thing in the zip file is a header that you can use to extract the first file, followed by that file, followed by the next file's header...
Re: Reality Check for Cloudflare Wasm Workers and Rust
#15Correct me if I’m wrong but the memory copying issue is not an issue if you pass an array buffer into WASM from JavaScript. In that scenario there’s no data copying. E.g. similar to how you’d pass the canvas data to WASM for direct manipulation.
No, this is an issue currently, both for network data and canvas data.
All wasm instructions can do is read and write from the wasm Memory that the wasm is initialized with. They can't even refer to separate things like a new ArrayBuffer from JS. So you do need to copy.
Newer wasm additions like reference types allow an ArrayBuffer to be referred to inside wasm, but only as an opaque reference to the entire thing (an externref). There is still no ability to actually read and write from it inside wasm.
The solution to this is BYOB ("bring your own buffer") APIs, which JS is adding. They are experimental atm though. Here is the relevant one here:
https://developer.mozilla.org/en-US/docs/Web/API/ReadableStr...
Note how you pass in a view to the JS API. That can be a view into the wasm memory, letting the browser directly write data into there, and then wasm can operate on it immediately.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#16I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…
> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance) That could be most web apps functionalities. Things like registration, authorization/authentication, sending emails, store/retrieve data, etc... > so using them to do “serious number crunching” at the edge, which is the advertised use case, see…
Workers does have a Cron like functionality. My memory is fuzzy but it's been around for a while.
https://developers.cloudflare.com/workers/platform/cron-trig...
Re: Reality Check for Cloudflare Wasm Workers and Rust
#17Earlier quoted context omitted.
I for one hadn't thought about the cost of shipping your own standard library with every bundle, so it was informative for me
WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.
I'm not sure but if you need any string manipulation at all it will be really hard to not use the rust std?
Re: Reality Check for Cloudflare Wasm Workers and Rust
#18Correct me if I’m wrong but the memory copying issue is not an issue if you pass an array buffer into WASM from JavaScript. In that scenario there’s no data copying. E.g. similar to how you’d pass the canvas data to WASM for direct manipulation.
So how do you fill that arraybuffer from Javascript datatypes (e.g. strings which describe the request)? The answer is "by copying the relevant data" - which is exactly what the bridging code between JS and WASM does. You can only avoid that if the source data is already plain byte arrays and not javascript objects.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#19Earlier quoted context omitted.
WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.
I'm not sure but if you need any string manipulation at all it will be really hard to not use the rust std?
I think their point is that what's referred to as "tree-shaking" in the JS world is (I'm pretty sure) normal and standard for most statically-compiled languages like Rust. So you won't bring in anything you don't need, though you will still be bringing in lots of stuff you do need
Re: Reality Check for Cloudflare Wasm Workers and Rust
#20> I guess I’ll stick with my error prone Javascript Workers or, more likely, spend an afternoon migrating to a minimal Typescript setup. If the OP wants a zero-config typescript experience (assuming Deno isn't available on Cloudflare workers), I can't recommend esbuild enough
There's also js_of_ocaml if a good type system is desired.
When we wrote opalang, the size of generated JS was problematic, despite serious efforts at minimizing it. Does js_of_ocaml do better?