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

71–80 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#71

Post by reginaldo »

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…

The browser "won" on seamless distribution. The browser is all the things you said and worse. It conflates the developer API (which could be as complex as the collective human comprehension will allow) with the execution environment (which must be as simple as possible and understandable to mostly anyone). I have a dream that the browser will turn inside out and start losing APIs that will be reimplemented on WebAssembly. But WebAssembly is moving too slowly e.g. with regards to tail calls and parallelism. So it's probably just a dream from now[1].

[1] https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.

Re: Announcing WCGI: WebAssembly and CGI

#72

Post by MR4D »

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…

Unfortunately, the world is scheduled to end (or reboot if you prefer) at 03:14:07 UTC on January 19th, 2038. [0]

So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes.

Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance!

[0] - https://en.wikipedia.org/wiki/Year_2038_problem

Re: Announcing WCGI: WebAssembly and CGI

#73

Post by mch82 »

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…

> Like a world that never got past the horse and buggy

At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-)

One of my favorite lunch breaks of all time.

Re: Announcing WCGI: WebAssembly and CGI

#74

Post by [deleted] »

throwaway50609 wrote: post #61
eyberg wrote: post #55

Earlier quoted context omitted.

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.

[deleted]

Re: Announcing WCGI: WebAssembly and CGI

#75

Post by mdellavo »

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

It's not an open standard but the JVM spec is publically available and intended for multiple implementations

https://docs.oracle.com/javase/specs/jvms/se8/html/

Re: Announcing WCGI: WebAssembly and CGI

#76

Post by qup »

mch82 wrote: post #73
0xbadcafebee wrote: post #66

Earlier quoted context omitted.

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…

> Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.

Give us the recap

Re: Announcing WCGI: WebAssembly and CGI

#77

Post by icedchai »

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.

2005? Maybe 1996. That's when I ran (and wrote) my first applet.

Re: Announcing WCGI: WebAssembly and CGI

#78

Post by mrec »

qup wrote: post #76
mch82 wrote: post #73

Earlier quoted context omitted.

> Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.

Give us the recap

http://www.astrodigital.org/space/stshorse.html

I'd be very leery of trusting the specifics too much. E.g. the reference to "Roman war chariots", which are not a thing the Romans ever used.

Snopes entry: https://www.snopes.com/fact-check/railroad-gauge-chariots/

Re: Announcing WCGI: WebAssembly and CGI

#79

Post by miohtama »

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.

We are not replicating Oracle’s lawyers, sales agreements and non-disclosure policies.

Re: Announcing WCGI: WebAssembly and CGI

#80

Post by tiffanyh »

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…

Don't forget, a mail server will be included at some point since that always seems inevitable.
Post reply on HN