5 ms·

Could someone eligthen me. Why not just use JavaScript? It is being used by Cloudflare on the edge, and AWS lambda. Why need to go to WASM?

enriquto 6y ago
The issue is quite symmetrical, isn't it? Somebody could ask: why not use just WASM? Why need to go to JavaScript? This is a better question, actually, if you already have a codebase in another language that can you can easily compile to wasm, but not to javascript.
- rattray 6y ago
  Because as the article states, JavaScript is widely used by their plugin developers, while AssemblyScript is still nascent (little-used, missing features, has bugs).
- runawaybottle 6y ago
  Like what? This is like me saying I have a mostly html/css/js website, and I just need it converted to a native Android app. Well no right? I have website. I don’t have mobile app that just needs to switch platforms. Do you have a website built in another language already? Then sure, all you need to do compile it via WASM. What I bet most of you have is a program for a totally different platform. In that case, you have to redo it, so why not just do it right.
alquemist 6y ago
* Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.
- rattray 6y ago
  For clarity, do you work at Shopify? These all sound like valid reasons, I'm just curious if they're the ones that motivated the Scripts team at Shopify.
  - deleted 6y ago
    [deleted]
- jariel 6y ago
  ? Those are reasons to use JS not WASM. "A wide ecosystem of mature language toolchains." - yes, for Javascript, not for WASM, which isn't deployed really anywhere in production and there aren't even best practices for it. What language are devs going to even write these scripts in? That's not clear. "Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over. "Portability" - again, nothing more portable than JS. The reasons to use WASM are 'performance' along with 'black box' - but in most cases performance is not necessary and the black box for all intents and purposes exists with v8.
  - MaxBarraclough 6y ago
    > "Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over. Not in terms of implementing the language.
    - discreteevent 6y ago
      Not in terms of using the language either. And the reason it is used the world over is because it was dictated to developers by browser makers. That's the single and only reason.
      - MaxBarraclough 6y ago
        I agree, but I'd still rank JavaScript as one of the more approachable major languages.
  - alquemist 6y ago
    I am not following WASM closely, but it appears to be deployed in all modern browsers: Chrome, Firefox, Safari, Edge. That counts as 'large scale production deployment', even if there aren't that many websites that take advantage of this capability (yet?). https://caniuse.com/wasm https://caniuse.com/wasm
- x86_64Ubuntu 6y ago
  How often does portability ever appear as a tie-breaker between to different languages?
  - alquemist 6y ago
    Rarely. Over a long enough time period though, the probability of a portability event nears 1, and the cost of such event is enormous. Right now there is a credible challenge for the x86 domination in the server, laptop and desktop markets raised by ARM, via AWS A1, Apple M1 and many others. Would be foolish to bootstrap an ecosystem locked-in to the loser, and we don't know the winner / loser over a 5-10 year timeframe.
sradman 6y ago
We are talking about two alternative architectures, Cloudflare Workers and Fastly Compute@Edge, solving the same problem: how to run server-side untrusted code. Cloudflare runs a sandboxed V8 runtime in-process with its Nginx servers while Fastly chose a Function-as-Service platform using Lucet compiled WebAssembly modules with minimal runtime and fast startup. Fastly’s Varnish servers invoke FaaS modules and it sounds like Shopify's Ruby centric platform is better suited to this architecture.
- kentonv 6y ago
  > Cloudflare runs a sandboxed V8 runtime in-process with its Nginx servers Maybe nitpicking, but that's not quite right. The Workers Runtime is a separate process from nginx and is inside a heavy second-layer sandbox separating it from the rest of the system. Multiple Workers Runtime instances exist on each machine to serve different tiers of customers, and each instance may additionally create further subprocesses to provide extra sandboxing adaptively. Here's a diagram: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/#architecturaloverview https://blog.cloudflare.com/mitigating-spectre-and-other-sec... (In that diagram, the "Inbound/Outbound HTTP Proxy" boxes are, at least at present, nginx, but the big middle box is a new server architecture written from scratch.)
  - sradman 6y ago
    That is not nitpicking at all. Definitely not in-process. Thanks for pointing that out.
- robertlagrant 6y ago
  Aah, that's why Fastly's involved. Thanks!

enriquto 6y ago

The issue is quite symmetrical, isn't it? Somebody could ask: why not use just WASM? Why need to go to JavaScript? This is a better question, actually, if you already have a codebase in another language that can you can easily compile to wasm, but not to javascript.

rattray 6y ago
Because as the article states, JavaScript is widely used by their plugin developers, while AssemblyScript is still nascent (little-used, missing features, has bugs).
runawaybottle 6y ago
Like what? This is like me saying I have a mostly html/css/js website, and I just need it converted to a native Android app. Well no right? I have website. I don’t have mobile app that just needs to switch platforms. Do you have a website built in another language already? Then sure, all you need to do compile it via WASM. What I bet most of you have is a program for a totally different platform. In that case, you have to redo it, so why not just do it right.

alquemist 6y ago

* Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.

rattray 6y ago
For clarity, do you work at Shopify? These all sound like valid reasons, I'm just curious if they're the ones that motivated the Scripts team at Shopify.
- deleted 6y ago
  [deleted]
jariel 6y ago
? Those are reasons to use JS not WASM. "A wide ecosystem of mature language toolchains." - yes, for Javascript, not for WASM, which isn't deployed really anywhere in production and there aren't even best practices for it. What language are devs going to even write these scripts in? That's not clear. "Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over. "Portability" - again, nothing more portable than JS. The reasons to use WASM are 'performance' along with 'black box' - but in most cases performance is not necessary and the black box for all intents and purposes exists with v8.
- MaxBarraclough 6y ago
  > "Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over. Not in terms of implementing the language.
  - discreteevent 6y ago
    Not in terms of using the language either. And the reason it is used the world over is because it was dictated to developers by browser makers. That's the single and only reason.
    - MaxBarraclough 6y ago
      I agree, but I'd still rank JavaScript as one of the more approachable major languages.
- alquemist 6y ago
  I am not following WASM closely, but it appears to be deployed in all modern browsers: Chrome, Firefox, Safari, Edge. That counts as 'large scale production deployment', even if there aren't that many websites that take advantage of this capability (yet?). https://caniuse.com/wasm https://caniuse.com/wasm
x86_64Ubuntu 6y ago
How often does portability ever appear as a tie-breaker between to different languages?
- alquemist 6y ago
  Rarely. Over a long enough time period though, the probability of a portability event nears 1, and the cost of such event is enormous. Right now there is a credible challenge for the x86 domination in the server, laptop and desktop markets raised by ARM, via AWS A1, Apple M1 and many others. Would be foolish to bootstrap an ecosystem locked-in to the loser, and we don't know the winner / loser over a 5-10 year timeframe.

sradman 6y ago

We are talking about two alternative architectures, Cloudflare Workers and Fastly Compute@Edge, solving the same problem: how to run server-side untrusted code. Cloudflare runs a sandboxed V8 runtime in-process with its Nginx servers while Fastly chose a Function-as-Service platform using Lucet compiled WebAssembly modules with minimal runtime and fast startup. Fastly’s Varnish servers invoke FaaS modules and it sounds like Shopify's Ruby centric platform is better suited to this architecture.

kentonv 6y ago
> Cloudflare runs a sandboxed V8 runtime in-process with its Nginx servers Maybe nitpicking, but that's not quite right. The Workers Runtime is a separate process from nginx and is inside a heavy second-layer sandbox separating it from the rest of the system. Multiple Workers Runtime instances exist on each machine to serve different tiers of customers, and each instance may additionally create further subprocesses to provide extra sandboxing adaptively. Here's a diagram: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/#architecturaloverview https://blog.cloudflare.com/mitigating-spectre-and-other-sec... (In that diagram, the "Inbound/Outbound HTTP Proxy" boxes are, at least at present, nginx, but the big middle box is a new server architecture written from scratch.)
- sradman 6y ago
  That is not nitpicking at all. Definitely not in-process. Thanks for pointing that out.
robertlagrant 6y ago
Aah, that's why Fastly's involved. Thanks!