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

91–100 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#91

Post by DuckFeathers »

0xbadcafebee wrote: post #66
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'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 a…

Apple's close ecosystem nonsense and blind worship of vendor-lock-in by the tech community is partly to blame for it.

Re: Announcing WCGI: WebAssembly and CGI

#94

Post by benatkin »

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…

The delivery of assets sounds like a job for Bindle which is already integrated to Spin, which looks to be more similar to python's WSGI than this

https://www.fermyon.com/spin

https://www.fermyon.com/blog/bindle-what-is-it

Re: Announcing WCGI: WebAssembly and CGI

#95

Post by benatkin »

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

Matt Butcher who used to work at Deis, which developed WAGI, and Microsoft after it was acquired, now has a new startup, Fermyon, which has something called Spin which I think uses a new protocol that's different from CGI. https://www.fermyon.com/blog/introducing-spin

That would make sense, anyhoo. CGI is plain text which I don't think is optimal for this stuff.

Re: Announcing WCGI: WebAssembly and CGI

#96

Post by nequo »

kllrnohj wrote: post #84
KRAKRISMOTT wrote: post #62

Earlier quoted context omitted.

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

Exactly, yet everyone pretends wasm is the exception for some reason...

I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?

Re: Announcing WCGI: WebAssembly and CGI

#97

Post by adam_arthur »

0xbadcafebee wrote: post #66
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'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 a…

Well, that's partly why WASM exists.

It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be.

The days of building an ecosystem around a closed, proprietary language/protocol/spec are over. The browser was just the first to bridge the gap... now we move on to WASM, and maybe 10 years from now something newer

https://wasmer.io/

https://wasi.dev/

Re: Announcing WCGI: WebAssembly and CGI

#98

Post by chrismorgan »

jeremyjh wrote: post #69
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…

You’re misunderstanding it. This is just recompiling CGI-speaking binaries to WASM, meaning that it’s effectively spawning a new process for each request. Being WASM it’s not a new native process but just a new instance of the WASM module, but in practice process-spawning is not the slow part, but what happens inside main, which is being run for every new request.

Re: Announcing WCGI: WebAssembly and CGI

#99

Post by 0xbkt »

rektide wrote: post #43
__MatrixMan__ wrote: post #13

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 gener…

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

Re: Announcing WCGI: WebAssembly and CGI

#100

Post by mhitza »

icedchai wrote: post #45
yazzku wrote: post #36

Earlier quoted context omitted.

Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.

JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.

Right, the internet caffee computers I used to hang out at in the early 2000's had around the 128-256mb of RAM memory, and Java/Flash used to run just fine. Although Java Applets usually seemed to take longer to download, and used to wait a lot of time to start the JVM after that.
Post reply on HN