3 ms·

The use of wasm makes sense to me in context of the article.

smolder 2y ago
The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.
- svieira 2y ago
  It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote: > One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (As I tell friends, it's like saving your game in an emulator.) > The snapshotted module has no extra startup time ... > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.
  - smolder 2y ago
    This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.
    - svieira 2y ago
      With CGI the developer of the script could pretend that the-only-thing-which-existed was this request and do all kinds of things that would bring down a persistent process (leak memory, mutate globals, etc.) The problem was that spinning up a process per-request was expensive and slow. Now, with WASM's memory model it becomes possible to have a process that both does all the slow work initialization work once and has the ease-of-reasoning properties of CGI's "a single process for a single request" serving model.
      - smolder 2y ago
        Edit to say: thanks for your answer. I'll preserve the rest since I still think wheels are being reinvented here. Bridging state across requests is not new. If "the new CGI" means more efficiently sharing state between requests, that's a really arbitrary qualifier and is not unique to WASM or serverless or anything like that. The article is myopic, it doesn't take into consideration what is established practice done over and over.
    - networked 2y ago
      WASI CGI is the new CGI. :-) https://codeberg.org/valpackett/caddy-wasm-wcgi https://codeberg.org/valpackett/caddy-wasm-wcgi Sorry, I'll use this rare opportunity to bring up WCGI for Caddy. :-) It is a Caddy web server plugin that runs CGI applications compiled to Wasm, which includes scripting language runtimes. The project isn't mine, and I haven't tried it for anything beyond a "Hello, world!". I think it is a neat hack.

The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.

svieira 2y ago
It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote: > One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (As I tell friends, it's like saving your game in an emulator.) > The snapshotted module has no extra startup time ... > If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.
- smolder 2y ago
  This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.
  - svieira 2y ago
    With CGI the developer of the script could pretend that the-only-thing-which-existed was this request and do all kinds of things that would bring down a persistent process (leak memory, mutate globals, etc.) The problem was that spinning up a process per-request was expensive and slow. Now, with WASM's memory model it becomes possible to have a process that both does all the slow work initialization work once and has the ease-of-reasoning properties of CGI's "a single process for a single request" serving model.
    - smolder 2y ago
      Edit to say: thanks for your answer. I'll preserve the rest since I still think wheels are being reinvented here. Bridging state across requests is not new. If "the new CGI" means more efficiently sharing state between requests, that's a really arbitrary qualifier and is not unique to WASM or serverless or anything like that. The article is myopic, it doesn't take into consideration what is established practice done over and over.
  - networked 2y ago
    WASI CGI is the new CGI. :-) https://codeberg.org/valpackett/caddy-wasm-wcgi https://codeberg.org/valpackett/caddy-wasm-wcgi Sorry, I'll use this rare opportunity to bring up WCGI for Caddy. :-) It is a Caddy web server plugin that runs CGI applications compiled to Wasm, which includes scripting language runtimes. The project isn't mine, and I haven't tried it for anything beyond a "Hello, world!". I think it is a neat hack.