Hacker News new | past | comments | ask | show | jobs | submit login

I don't understand. Why not just compile to machine code and use plain old CGI?



Others have some good reasons to also consider. Also, launching new sandboxes in wasm is supposed to be extremely extremely extremely cheap.

Where-as launching a cgi-bin executable- even a very small libcgi based one-has a significant cost, requires a lot of kernel work & context switching.

With WCGI making new "processes" is nearly free & you don't have to context switch.

A lot of the excitement around wasm in general is that it could potentially enable a communicating-processes model of computing that would be inefficient today. Even current "function as a service" paradigms tend to retain processes, have warm/cold start distinctions. With wasm there is a potential to have requests spawn not just their sandbox, but to create whole graphs of lightweight sandbox/processes. Sometimes you might hear this described as a "Nano-functions" architecture.


I think the closest thing to "nanofunctions" today are V8 isolates.


As well as sandboxing there’s the potential for better startup performance. Wasmtime have described how they can achieve microsecond startup times using virtual memory tricks to reset and reuse a module isolated between requests. https://bytecodealliance.org/articles/wasmtime-10-performanc...

This is faster than forking a process because there are fewer operating system resources to manage.

CGI starts a new process rather than forking an existing one which makes it unsuitable for use with languages such as Python or JS which have slow initialisation times (milliseconds.) Wizer is able to snapshot a WebAssembly module to avoid that work. So in combination with the fast startup that brings initialisation down to microseconds.

Now runtimes are still somewhat slower on WebAssembly than native, and much slower for JITed languages since the JIT cannot run in WebAssembly. But there are many cases where startup time dominates and this will be faster overall for cases where you need per request isolation.


I believe the main selling point is portability and flexibility. Anything written in a language that can be compiled to wasm can now be turned into a web service.


Platform independence: WebAssembly allows you to compile code once and run it on any platform supporting it, saving time and effort when deploying applications across various servers compared to dealing with platform-specific binaries.


Who is deploying the same backend to multiple architectures?


Though many developers may not prioritize deploying the same backend across multiple architectures, the platform independence offered by WebAssembly and WCGI can still be advantageous for migration, development efficiency, and keeping up with changing tech trends(serverless, edge computing)


Sandboxing, I believe is the answer. Portability, too, I suppose. Maybe a long-lasting archive format for older binaries...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: