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

The Road to the WASM Component Model 1.0

bytecodealliance.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: The Road to the WASM Component Model 1.0

#61

Post by tpm »

Panzerschrek wrote: post #20
wyager wrote: post #13

Earlier quoted context omitted.

I'm curious if people have a good story for why WASI will succeed where Java failed

Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application. With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.

> It adds extra friction for end-users

It doesn't have to, the program can bundle its own jre as its often the case, and then you also don't have to worry about jre compatibility. Downside is then you have many jres installed and of course you can't trust their sandboxing.

Re: The Road to the WASM Component Model 1.0

#64

Post by DonHopkins »

simonw wrote: post #16
wyager wrote: post #13

Earlier quoted context omitted.

I'm curious if people have a good story for why WASI will succeed where Java failed

My main one is that WASI has benefitted from an additional 31 years of accumulated industry-wide experience compared to when Java was first released.

Plus, Larry Ellison doesn't own WASM: "Lawnmower Not Included"!

Re: The Road to the WASM Component Model 1.0

#65

Post by eviks »

samiv wrote: post #45
simonw wrote: post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access? Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway. So logically I'd think t…

> The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access?

But it doesn't need network access to be useful, so it doesn't have that permission and can't exfiltrate your data?

Re: The Road to the WASM Component Model 1.0

#67

Post by afiori »

wyager wrote: post #13
simonw wrote: post #2

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cros…

I'm curious if people have a good story for why WASI will succeed where Java failed

Because Java was doing nothing similar, a better comparison would be .NET CLR that actually tried to be a decent compilation target.

Also security, Java has reflection so you cannot reliably sandbox java libraries

Re: The Road to the WASM Component Model 1.0

#68

Post by afiori »

pjmlp wrote: post #33
Panzerschrek wrote: post #20

Earlier quoted context omitted.

Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application. With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.

It is exactly the same for WASM outside of the browser, and Java has Android as counter part to built in runtime.

Java's vm does not start in milliseconds nor has dozen independent implementations in every ecosystem

Re: The Road to the WASM Component Model 1.0

#69

Post by afiori »

tpm wrote: post #62
thefounder wrote: post #4

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

we still need js shim for dom access :(

Asking for 0% js 100% wasm website is like wanting a C-free linux distro

Re: The Road to the WASM Component Model 1.0

#70

Post by hmry »

pjmlp wrote: post #30
tancop wrote: post #14

Earlier quoted context omitted.

sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.

No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.

That's what WASI is for
Post reply on HN