Reality Check for Cloudflare Wasm Workers and Rust
1–10 of 59 posts
Re: Reality Check for Cloudflare Wasm Workers and Rust
#2> 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
Re: Reality Check for Cloudflare Wasm Workers and Rust
#3Great overview OP, and it's nice to see a kind of "in-between" scenario tested, i.e. not a super fast web request or transformation, rather something more akin to a lightweight batch job. It may not be quite a "recommended" use case but it is always interesting (for me at least) to see how these sorts of services' capabilitied can be pushed and or (gently) abused. The memory and code size limitations do seem very restrictive right now, which is a shame though.
Seeing WASM evolve as the new sandboxed runtime target dejour is a super interesting and I love that it is bringing more variety of very powerful but traditionally backend or systems languages to the web.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#4I 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” for the uninitiated. It may not be meant to imply that number crunching is the use case.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#5I 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 for one hadn't thought about the cost of shipping your own standard library with every bundle, so it was informative for me
Re: Reality Check for Cloudflare Wasm Workers and Rust
#6> 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.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#7I 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, seems questionable.
Cloudflare workers don't run in the background. They block the HTTP request. For serious computation, Cloudflare should offer background workers that can run for extended periods of time. [1]
1: This could be tricked by triggering an async request, but there is no push API to get notify the "App" of the result.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#8I 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…
Given HTTP pipelining and fetch() promise semantics, I'm not sure there's a practical benefit to pushing results instead of "blocking" the original request.
Re: Reality Check for Cloudflare Wasm Workers and Rust
#9iirc the compilation time of wasm in Cloudflare Workers is very problematic[1] and right now it contradicts their idea of running low latency fast scripts, does anyone know if anything has changed ?
https://community.cloudflare.com/t/fixed-cloudflare-workers-...
Re: Reality Check for Cloudflare Wasm Workers and Rust
#10I 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 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.