Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing WCGI: WebAssembly and CGI

wasmer.io

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#61

Post by throwaway50609 »

eyberg wrote: post #55
throwaway50609 wrote: post #52

Earlier quoted context omitted.

Funny that you forgot about all the security issues of JVM applets that Wasm finally solved

Like this one? #include #include int main() { char *s = "world"; s[0] = 'o'; s[1] = 'w'; s[2] = 'n'; s[3] = 'e'; s[4] = 'd'; printf("Hello, %s\n", s); }

Just compiled and ran it on my system within Wasm, my computer is still fine. Your point?

The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.

Re: Announcing WCGI: WebAssembly and CGI

#62

Post by KRAKRISMOTT »

pitaj wrote: post #23
syrusakbary wrote: post #10

Earlier quoted context omitted.

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.

Not just in the past, arbitrary program sandboxing is not possible even today.

Re: Announcing WCGI: WebAssembly and CGI

#63

Post by [deleted] »

syrusakbary wrote: post #10
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

[deleted]

Re: Announcing WCGI: WebAssembly and CGI

#64

Post by laurencerowe »

__MatrixMan__ wrote: post #13

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

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.

Re: Announcing WCGI: WebAssembly and CGI

#65

Post by tubs »

syrusakbary wrote: post #10
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

You can't run c in wasm.

You can compile c to wasm and run that.

In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.

Re: Announcing WCGI: WebAssembly and CGI

#66

Post by 0xbadcafebee »

syrusakbary wrote: post #10
joncfoo wrote: post #7

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless.

I can't even come up with a metaphor for it. We're choosing to be stuck with shitty antiquated technology because it's easier than making something better. It's depressing. Like a world that never got past the horse and buggy. Large engines powered by steam would require additional investment in refining of steel and making giant cast or forged parts... easier to just stick with the horse.

Re: Announcing WCGI: WebAssembly and CGI

#67

Post by Y_Y »

frou_dh wrote: post #47
dianeb wrote: post #41

Earlier quoted context omitted.

Sure, this fits the way software evolves on the circle of dumb. It goes something like this: What a great idea!... (a little later) Hmmm. That's a problem... (later) We need something to run apps in the browser. I wonder if WASM would work... (now) What a great idea!... Software development always goes in cycles. "Apps" were great now maybe not so much so... In the late 80s/early 90s, the CEO of ETA Systems (a superc…

As long as it's refining and making at least some progress then it's more of a helix than a circle

I see it as more of a conical spiral, like water going down a drain.

Re: Announcing WCGI: WebAssembly and CGI

#69

Post by jeremyjh »

chrismorgan wrote: post #46

> Consider the challenge of running PHP programs on servers. We have two primary options: > 1. Wrap the PHP interpreter with a layer that instruments each HTTP call > 2. Use the existing php-cgi program and simply compile it to Wasm > Option 2 is not only faster, but it also enables any web application on Wasmer more efficiently. I’m confused. This seems to be suggesting that php-cgi, which has to initialise the PHP…

To me this seems a little closer to the architecture of AWS Lambda than OG CGI, though that is not a perfect analogy either since this is in a WASM runtime within their server process, rather than a separate process. But the programming interface is a handler function you provide with an interface that looks like this in Rust:

`fn handler(request: Request) -> Response `

My understanding is the main function is called only once, and registers that handler. So `main` is where you'd initialize the majority of the environment, and no that is not truly CGI; definitely no process is being created for each request, but it may be the case that this is more like FastCGI where you have a pool of single-threaded runtimes all setup that way that can handle requests.

This still seems inefficient compared to a threaded or event polling process that can handle multiple requests concurrently without having to marshall data back and forth, but I'd think it can get closer to that than FastCGI or Lambda do.

Re: Announcing WCGI: WebAssembly and CGI

#70

Post by cassepipe »

paulgb wrote: post #4

I've always loved the simplicity and flexibility of CGI. To check my understanding: since CGI just takes a raw request over stdin and returns a response over stdout, would a WCGI wasm module be compatible with WAGI[1] and vice-versa? [1] https://github.com/deislabs/wagi

To me it has always felt like a underspecified hack but maybe I am talking out of ignorance. (I did read the RFC though( I think it's strange idea to run to get a bunch of arguments that you have to get from the environment and/or the stdin and parse the whole of it and then try to programmatically output it all by printing to stdout. No wonder people have come up with template languages that are html supersets and that work with a preprocessor.

I don't use CGI but when I do I like the simplicity of Haserl (Basic template language + any interpreter, lua by default) : https://haserl.sourceforge.net/

Post reply on HN