Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

21–30 of 313 posts

Re: WebAssembly: Docker Without Containers

#21
post #5
post #4

Earlier quoted context omitted.

Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

What's wrong with a "JVM but for everyone who isn't a Java developer"?

If the model works, why shouldn't there be competitors and wide spread adoption?

Re: WebAssembly: Docker Without Containers

#23
post #5
post #4

Earlier quoted context omitted.

Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

Re: WebAssembly: Docker Without Containers

#24
post #9

Earlier quoted context omitted.

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

> JVM+JAR existed JVM can only run apps written for it: Docker & WASM don't have that limitation. > it can run non-WASM and non-JVM apps like PostgreSQL, etc... but WASM can run Postgres

With GraalVM you can run any LLVM binary on JVM...

Re: WebAssembly: Docker Without Containers

#25

Earlier quoted context omitted.

> JVM+JAR existed JVM can only run apps written for it: Docker & WASM don't have that limitation. > it can run non-WASM and non-JVM apps like PostgreSQL, etc... but WASM can run Postgres

Source?

Here you have the different links:

- Article: https://supabase.com/blog/postgres-wasm

- Repository: https://github.com/snaplet/postgres-wasm

- HN Thread: https://news.ycombinator.com/item?id=33067962

Re: WebAssembly: Docker Without Containers

#26

Earlier quoted context omitted.

> JVM+JAR existed JVM can only run apps written for it: Docker & WASM don't have that limitation. > it can run non-WASM and non-JVM apps like PostgreSQL, etc... but WASM can run Postgres

Source?

https://lmddgtfy.net/?q=postgres%20wasm

Re: WebAssembly: Docker Without Containers

#27
post #22

So, 'write once, run everywhere'... I think we've been here before.

Yes! Wasm builds on top of 20 years of experience and improvements of JVM, CLR. There are a few key differences, but one important one is the universal adoption by the industry (no ActiveX vs Applets war, .NET vs Java) with companies as varied as Google, Apple, Amazon, Microsoft actively cooperating on moving the standard forward. I have never seen anything like that and I hope it continues for as long as possible!

Re: WebAssembly: Docker Without Containers

#28
post #22

So, 'write once, run everywhere'... I think we've been here before.

The VM part of WASM is not per se the interesting part. The really interesting part is having a VM that is not able to access the system besides what it's being explicitly allowed to by the host. This is an extremely useful security tool.

Re: WebAssembly: Docker Without Containers

#29
post #13

Earlier quoted context omitted.

JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?

Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way. In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.

That doesn't work. Java web apps have failed. Nobody uses Java in the browser anymore. So even if we use JVM bytecode as the intermediary language you would need to translate that into ASM.js and then you basically introduced arbitrary complexity for literally no reason and you won't have the performance benefit of webassembly.

The browser engine developers effectively paid a huge up front fixed cost and now anyone can use Webassembly in nodejs which then spills over to more and more use cases like cryptocurrencies using a modified WASM VM for their zk sync layer two solution.

The JVM simply wasn't built for these use cases.

Re: WebAssembly: Docker Without Containers

#30
post #9

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm. The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not like the jvm which is designed primarily for Java in the front end.
Post reply on HN