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

31–40 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#31

Post by ThePhysicist »

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

Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with the hope the ecosystem will standardize on it and give them opportunities to monetize that. So not that much unlike Java I'd say.

Re: Announcing WCGI: WebAssembly and CGI

#32

Post by jeremyjh »

kristjansson wrote: post #25
0xbadcafebee wrote: post #16

PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…

edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to pro…

No, CGI is an interface for backend web servers, this is not about client code.

Re: Announcing WCGI: WebAssembly and CGI

#33

Post by syrusakbary »

Kwpolska wrote: post #27
syrusakbary wrote: post #8

Earlier quoted context omitted.

Here are the main differences with the Docker strategy: * If you want it to be usable, you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx), so your container would be bigger than the Wasmer package * Regarding security: Docker containers needs to rely on hardware virtualization to run securely (via KVM or simlar), aside of a virtualization on the systemcall layer (…

> you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx) Is wasmer stable and secure enough to be exposed to abuse of the entire Internet? > your container would be bigger than the Wasmer package The first Google hit for "docker php nginx" is https://hub.docker.com/r/trafex/php-nginx - they claim their Docker image is 40 MB compressed, whereas Wasmer for amd64 (latest…

> whereas Wasmer for amd64 is a 80 MB tar.gz

Wasmer ships everything by default, including 3 compilers (LLVM is the big one!), which adds most of the size. However, the wasmer runtime in headless mode weights only about 2 megabytes.

Even more, even if you include only one compiler instead of 3 (just singlepass) it would be in the order of 5-10Mb.

Stay tuned, because if you are in macOS/iOS you will see even smaller binary sizes!

Re: Announcing WCGI: WebAssembly and CGI

#34

Post by nu11ptr »

pjmlp wrote: post #20
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…

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

Honestly, I just think Java was ahead of its time. I hated sites with applets because they felt slow to startup and run. That problem is long gone with modern computers.

Re: Announcing WCGI: WebAssembly and CGI

#35

Post by jeremyjh »

smiletondi wrote: post #29
__MatrixMan__ wrote: post #13

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

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?

Re: Announcing WCGI: WebAssembly and CGI

#36

Post by yazzku »

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

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.

Re: Announcing WCGI: WebAssembly and CGI

#37

Post by gabereiser »

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…

I was just going to say, this road leads to OSGi...

Re: Announcing WCGI: WebAssembly and CGI

#38

Post by smiletondi »

jeremyjh wrote: post #35
smiletondi wrote: post #29

Earlier quoted context omitted.

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)

Re: Announcing WCGI: WebAssembly and CGI

#39

Post by freeone3000 »

syrusakbary wrote: post #12
pookeh wrote: post #11

Earlier quoted context omitted.

There was a time when JVM ran in the browsers.

Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P

They were better than Flash (which needed a weirder runtime, and couldn’t interact easily with the DOM, and didn’t have variables until version 3). This is hugely improved over JavaScript at the time (pre-XHR) and had less lock-in than ActiveX.

Re: Announcing WCGI: WebAssembly and CGI

#40

Post by michaelmior »

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 could not run C programs in the JVM

Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/

Post reply on HN