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

Hello wasm-pack

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 160 posts

Re: Hello wasm-pack

#31

Post by kodablah »

jnordwick wrote: post #28

I'm kind of curious how wasm is going to work out. It seems only logical that wasm interpreters will be optimizing JITs. Wasm will essentially be an intermediate language similar to JVM bytecode. At that point why not just use the JVM stripped of the useless stuff as a base and add the remaining small pieces that might be needed. Or Graal. I guess I don't understand what Wasm is doing that is so much different that c…

> It seems only logical that wasm interpreters will be optimizing JITs. Wasm will essentially be an intermediate language similar to JVM bytecode.

Yup

> why not just use the JVM stripped of the useless stuff as a base

This often comes up in WASM discussions. First of all, you cannot divorce a JVM from its useless stuff. Many parts of the stdlib might as well be part of the bytecode (e.g. strings which then carries a done of charset code, classloaders, boxed primitives, method handles, lambda factories, etc). I would love to see an effort to leverage JVMs bytecode without all of it's baggage, but for now the marriage is so tight they are inseparable.

> Or Graal

That's a runtime VM/compiler, not a bytecode spec to target.

> I guess I don't understand what Wasm is doing that is so much different that couldn't be handled with other more advanced code bases.

Keep it simple, (mostly) no undefined behavior, no required GC, works the same on all platforms, large test suite, multiple big-company backers, etc. I can't think of an "assembly set" (or bytecode) that does all of that.

Re: Hello wasm-pack

#32

Post by steveklabnik »

kodablah wrote: post #27
steveklabnik wrote: post #8

Earlier quoted context omitted.

What’s the binary size like? One interesting thing about wasm is the difference between libraries and apps; Rust’s small binary size here can make it useful for this infrastructure work, but for languages that need to bring along the runtime, it’s much more complex. This is one reason why we’re pursuing stuff like wasm-pack. I’m glad to see more and more languages compiling to wasm though! Exciting times.

> What’s the binary size like? I asked this same question[0]. Appears mono.js is 166kb in release mode, but it downloads/uses the DLLs directly as a system would, so those sizes are the same as they are for desktop apps (not sure off the top of my head what that is for ASP.Net stuff or the stdlib). 0 - https://github.com/mono/mono/issues/7820

Ah nice, thank you! The recent work with emscripten to get sizes down will help them too, I’m sure.

Re: Hello wasm-pack

#33

Post by yougane »

wvenable wrote: post #19
steveklabnik wrote: post #8

Earlier quoted context omitted.

What’s the binary size like? One interesting thing about wasm is the difference between libraries and apps; Rust’s small binary size here can make it useful for this infrastructure work, but for languages that need to bring along the runtime, it’s much more complex. This is one reason why we’re pursuing stuff like wasm-pack. I’m glad to see more and more languages compiling to wasm though! Exciting times.

The original Blazer was based on the DotNetAnywhere runtime and the binary size was actually very reasonable. Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.

The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used side-by-side with other languages.

Re: Hello wasm-pack

#34

Post by plurgid »

alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web.

truly the complete dead end of it.

Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

Re: Hello wasm-pack

#35

Post by dvfjsdhgfv »

Mononokay wrote: post #9
dvfjsdhgfv wrote: post #7

Earlier quoted context omitted.

What makes you say so? JavaScript in itself is not a bad language at all, and many programmers genuinely like it.

It's not a bad language in itself, no - it's just a waste of resources for the end-user, and in general it's being marketed to newcomers as the language they should learn by default - leading to a tonne of unoptimized sites and terrible applications using it. Then again, I suppose that's a fault of the type of programmers attracted to it than it is the language itself.

> it's just a waste of resources for the end-user

Frankly, it's not a problem of the language, but the browser. As far as I can tell, none of the popular browsers offer a way to limit resource usage, even though users would clearly benefit from it.

Re: Hello wasm-pack

#36

Post by ag_dubs »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

there's a human readable version, you can read more about it here: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

Re: Hello wasm-pack

#37

Post by steveklabnik »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

The ability to preserve “view source” has been a first-class consideration of wasm since the beginning. It’s effectivly the same as JavaScript in this regard.

Re: Hello wasm-pack

#38

Post by mrec »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

> Is a disassembler for WASM a thing yet?

Yes, it's part of the standard toolkit. See https://github.com/WebAssembly/wabt and specifically the "wasm2wat" tool.

Re: Hello wasm-pack

#39

Post by Dayshine »

yougane wrote: post #33
wvenable wrote: post #19

Earlier quoted context omitted.

The original Blazer was based on the DotNetAnywhere runtime and the binary size was actually very reasonable. Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.

The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used si…

>The original runtime was about 60kb in size, that's still unreasonable to add to a library

What? What kind of bubble are you working in?

Re: Hello wasm-pack

#40

Post by [deleted] »

Dayshine wrote: post #39
yougane wrote: post #33

Earlier quoted context omitted.

The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used si…

>The original runtime was about 60kb in size, that's still unreasonable to add to a library What? What kind of bubble are you working in?

[deleted]
Post reply on HN