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

91–100 of 111 posts

Re: The Road to the WASM Component Model 1.0

#91

Post by ptx »

dtj1123 wrote: post #90
ptx wrote: post #83

Earlier quoted context omitted.

From the introduction section of the Java specification [1]: "The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs." [1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...

From the same link, opening sentence: "The Java® programming language is a general-purpose, concurrent, object-oriented language." Edit: Having thought a little, I appreciate that it's possible to compile for the JVM from source code which is not Java, which makes the JVM a compilation target. As far as I'm aware the JVM doesn't have first class support for this though, It's been tacked on as an afterthought. Compili…

There are (or have been) lots of languages using the JVM as a compilation target, whether it is well-suited for this or not. Wikipedia has a partial list: https://en.wikipedia.org/wiki/List_of_JVM_languages

Re: The Road to the WASM Component Model 1.0

#92

Post by eviks »

pjmlp wrote: post #89
eviks wrote: post #87

Earlier quoted context omitted.

So? Will they not have imports of external functions?

The point being that WASM doesn't improve anything over sandoxing native applications, on the OSes that actually are serious about it. It should confine itself as the evolution from browser plugins.

So it does improve since the OSes are not actually serious about it otherwise they would've fixed these basic usability concerns years ago.

Re: The Road to the WASM Component Model 1.0

#93

Post by jauntywundrkind »

tschneidereit wrote: post #74
jauntywundrkind wrote: post #10

Earlier quoted context omitted.

It works in the browser already, by bundling another browser runtime engine into wasm. You need a whole fork of Mozilla's SpiderMonkey engine, compiled to wasm, running in whatever browser you have, to run wasm components today. I confess I was quite frustrated at first when browsers all said no to wasi / wasm components. But honestly, it was the right call. It's taken so long to make wasm components happen, to get t…

[Creator of the StarlingMonkey JS runtime here] > It works in the browser already, by bundling another browser runtime engine into wasm. Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/brow…

Apologies for consuming your time unnecsesarily & for misinformation! Mea culpa! Sorry again, & thank you so much for writing in! Oh my gosh. I don't have a good excuse, don't know how I mis-recalled so badly; it has been a year since I looked. My interest has usually been in getting component runtimes going, less so in downcompiling components into a single blob to run (perhaps on the web), but that is still a grevious mis-statement I made, and I thank you again for showing up. Yikes. My very bad. :(

Re: The Road to the WASM Component Model 1.0

#94

Post by pjmlp »

eviks wrote: post #92
pjmlp wrote: post #89

Earlier quoted context omitted.

The point being that WASM doesn't improve anything over sandoxing native applications, on the OSes that actually are serious about it. It should confine itself as the evolution from browser plugins.

So it does improve since the OSes are not actually serious about it otherwise they would've fixed these basic usability concerns years ago.

I haven't said such thing.

Re: The Road to the WASM Component Model 1.0

#95

Post by dtj1123 »

ptx wrote: post #91
dtj1123 wrote: post #90

Earlier quoted context omitted.

From the same link, opening sentence: "The Java® programming language is a general-purpose, concurrent, object-oriented language." Edit: Having thought a little, I appreciate that it's possible to compile for the JVM from source code which is not Java, which makes the JVM a compilation target. As far as I'm aware the JVM doesn't have first class support for this though, It's been tacked on as an afterthought. Compili…

There are (or have been) lots of languages using the JVM as a compilation target, whether it is well-suited for this or not. Wikipedia has a partial list: https://en.wikipedia.org/wiki/List_of_JVM_languages

My point is that it isn't well suited for it. Hence WASM.

Re: The Road to the WASM Component Model 1.0

#96

Post by GoblinSlayer »

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.

>And even if one has Java runtime installed, a newer version may be necessary for a recently-published application.

WASM doesn't remove version churn, the linked article literally discusses a newer version. Oh and the wonderful web compat story.

Re: The Road to the WASM Component Model 1.0

#97

Post by sideeffffect »

grayrest wrote: post #34
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…

The thing that interests me the most is that execution is deterministic. If the inputs to a WASM module are logged you get durable execution and rr style reverse debugging as part of the package.

If you're interested in this, then you should check out https://github.com/golemcloud/golem

Golem is a durable workflow platform and can run any wasm.

Re: The Road to the WASM Component Model 1.0

#98

Post by GoblinSlayer »

dfabulich wrote: post #85
tpm wrote: post #73

Earlier quoted context omitted.

One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM. The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.

One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API. The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on. The effort to get all the browsers to agree to standardize a new JS-less…

Web API is described in WebIDL, and javascript has its own approach to consume these interfaces.

Re: The Road to the WASM Component Model 1.0

#99

Post by yoshuaw »

flohofwoe wrote: post #25

> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines. I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains. Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine wi…

If you want compilers to be able to natively target browsers and access the browser DOM APIs, then you need to define some kind of contract between browsers and compilers on how to call APIs in one from the other. That is what the Wasm Component Model provides.

Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.

Re: The Road to the WASM Component Model 1.0

#100

Post by yjftsjthsd-h »

fc417fc802 wrote: post #47
yjftsjthsd-h wrote: post #21

Earlier quoted context omitted.

Hey, this is also my interest. I was just looking into whether it was possible to e.g. build an archive extractor that runs like a normal program but does the actual extraction completely in wasm. Unfortunately, AFAICT it's possible but requires custom code; you can't ( yet , I hope) just compile unzip/libarchive/whatever with CC=wasicompiler and get a sandboxed binary. But we're getting close.

You should be able to do exactly that though? Why do you think you can't? You will of course need to include a lot of support code to provide the relevant syscalls and otherwise emulate the environment that the code expects. But there are plenty of examples of that at this point.

Yeah, it's all that support code that I don't want to write. I want to (roughly) just

  tar -xf unzip.tar.gz && cd unzip
  ./configure CC=wasmcc
  make
  wasmruntime unzip.wasm testfile.zip
Post reply on HN