7 ms·

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

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), 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.

brundolf 5y ago
I for one hadn't thought about the cost of shipping your own standard library with every bundle, so it was informative for me
- wibagusto 5y ago
  WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.
  - brundolf 5y ago
    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.
    - mst 5y ago
      One of the examples he mentioned was 200Kb. That's still a lot more than "a single file of javascript", certainly, but it's not that bad. Trade-offs all the way down, as ever.
  - merb 5y ago
    I'm not sure but if you need any string manipulation at all it will be really hard to not use the rust std?
    - brundolf 5y ago
      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
      - azakai 5y ago
        Generally true, but just to add to that, in languages like Rust and C++ you often end up including stuff you don't need due to toolchain limitations. For example, indirect calls (from Rust traits or C++ virtual methods) are hard to get rid of in general. This is a pretty significant cause of bloat in practice, sadly, but toolchain improvements may help in the future. So for now, JS's advantage of the standard library being in the VM is pretty significant.
csomar 5y ago
> 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.
- wrkronmiller 5y ago
  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.
  - csomar 5y ago
    If you want to run something in the background whether the user page is still active or not. Once the computation is complete, it pushes a notification to the user or trigger other workers.
- eloff 5y ago
  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-triggers https://developers.cloudflare.com/workers/platform/cron-trig...
  - csomar 5y ago
    Assuming you pull results every 1 second, that's 86.4k requests a day for each potential user you have. Another solution, is it have a single CRON worker that watches for all notifications, kinda a basic implementation for a Push API.
kentonv 5y ago
> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud providers. > for example, they have tight memory limits and don’t have great performance This isn't true. "Performance" is a vague term, you need to clarify the use case and what you're measuring. But, I can't think of what you could mean by "don't have great performance", that seems to imply that they execute code slower or something, which just isn't true at all. In many cases, Workers perform much better than you could achieve with any other platform, due to the ability to spread work and data across the network and move it close to where it's needed. The "memory limit" on a single worker instance is 128MB, but Cloudflare runs many instances of the worker around the world, so across the network you're really getting many gigabytes of memory. By building a distributed system based on Durable Objects, you can harness the memory of many instances to use on a single task. Workers definitely biases towards distributing load across the network rather than running a single fat instance of your server, but that just means Workers makes it easy to build apps that scale to much higher. What this article is highlighting is that Wasm is still an immature technology. That is, unfortunately, just a fact. There's still work to be done, and progress is being made, but it's still early. The code footprint issue (because every app must bring along its own language runtime) is the biggest blocker. We hope to see that solved with dynamic linking. But, Workers isn't primarily based on Wasm. The vast majority of Workers are written in JavaScript, where these issues don't exist. Workers runs JavaScript just as fast as any Node.js server, and runs it closer to the client resulting in better latency.
- azakai 5y ago
  Small note on this: > What this article is highlighting is that Wasm is still an immature technology. I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the Web platform. Otherwise very good points!
  - kentonv 5y ago

brundolf 5y ago

I for one hadn't thought about the cost of shipping your own standard library with every bundle, so it was informative for me

wibagusto 5y ago
WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.
- brundolf 5y ago
  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.
  - mst 5y ago
    One of the examples he mentioned was 200Kb. That's still a lot more than "a single file of javascript", certainly, but it's not that bad. Trade-offs all the way down, as ever.
- merb 5y ago
  I'm not sure but if you need any string manipulation at all it will be really hard to not use the rust std?
  - brundolf 5y ago
    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
    - azakai 5y ago
      Generally true, but just to add to that, in languages like Rust and C++ you often end up including stuff you don't need due to toolchain limitations. For example, indirect calls (from Rust traits or C++ virtual methods) are hard to get rid of in general. This is a pretty significant cause of bloat in practice, sadly, but toolchain improvements may help in the future. So for now, JS's advantage of the standard library being in the VM is pretty significant.

csomar 5y ago

> 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.

wrkronmiller 5y ago
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.
- csomar 5y ago
  If you want to run something in the background whether the user page is still active or not. Once the computation is complete, it pushes a notification to the user or trigger other workers.
eloff 5y ago
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-triggers https://developers.cloudflare.com/workers/platform/cron-trig...
- csomar 5y ago
  Assuming you pull results every 1 second, that's 86.4k requests a day for each potential user you have. Another solution, is it have a single CRON worker that watches for all notifications, kinda a basic implementation for a Push API.

kentonv 5y ago

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud providers. > for example, they have tight memory limits and don’t have great performance This isn't true. "Performance" is a vague term, you need to clarify the use case and what you're measuring. But, I can't think of what you could mean by "don't have great performance", that seems to imply that they execute code slower or something, which just isn't true at all. In many cases, Workers perform much better than you could achieve with any other platform, due to the ability to spread work and data across the network and move it close to where it's needed. The "memory limit" on a single worker instance is 128MB, but Cloudflare runs many instances of the worker around the world, so across the network you're really getting many gigabytes of memory. By building a distributed system based on Durable Objects, you can harness the memory of many instances to use on a single task. Workers definitely biases towards distributing load across the network rather than running a single fat instance of your server, but that just means Workers makes it easy to build apps that scale to much higher. What this article is highlighting is that Wasm is still an immature technology. That is, unfortunately, just a fact. There's still work to be done, and progress is being made, but it's still early. The code footprint issue (because every app must bring along its own language runtime) is the biggest blocker. We hope to see that solved with dynamic linking. But, Workers isn't primarily based on Wasm. The vast majority of Workers are written in JavaScript, where these issues don't exist. Workers runs JavaScript just as fast as any Node.js server, and runs it closer to the client resulting in better latency.

azakai 5y ago
Small note on this: > What this article is highlighting is that Wasm is still an immature technology. I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the Web platform. Otherwise very good points!
- kentonv 5y ago