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

131–140 of 160 posts

Re: Hello wasm-pack

#131

Post by fulafel »

themihai wrote: post #84
fulafel wrote: post #57

Earlier quoted context omitted.

Also, JS is a more suitable target for most managed languages like clojure, typescript, elm, etc.

Well... two of 3 of the languages you provided as example were designed to be transpiled to javascript. I doubt JS is a more suitable target for other languages than an IR like wasm which is being designed to be a compiler target.

I would be interested in hearing a more detailed argument on why ClojureScript & Elm would be better if they targeted WebAssembly.

Even the WebAssembly authors seem to agree that it's not foremost a managed language compile target - The Overview text from http://webassembly.org/ says "Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications."

Re: Hello wasm-pack

#132

Post by colordrops »

titzer wrote: post #78
axefrog wrote: post #69

Does anyone have a good sense of the current performance impact of crossing the boundary between JS and WASM? I've often thought it'd be great to be able to expose high-performance data structures (and other infrastructure-level stuff) via WASM and then make use of them from JavaScript, but I seem to recall that the interop performance cost is currently too high to make it worth doing, which leaves WASM mainly only u…

The cost is more than a JS->JS call, but not drastically so. Every argument must be converted from a number to an int32/float32/float64, which for SMI values is a single branch, for heap numbers a branch and a load. For other JS values, a ValueOf() operation on the JS value. V8 generates little wrappers for these, with inline conversions. It does not currently inline the little wrapper functions, nor use ICs for the…

If it's nearly impossible to defeat inlining, wouldn't the appropriate comparison be against inlined JS?

Re: Hello wasm-pack

#133

Post by Klathmon »

wvenable wrote: post #109
yougane wrote: post #80

Earlier quoted context omitted.

> Not only will most frameworks and standard JS libs dwarf this The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size. > the average web page size has upped to ~ 3MB these days... This is not an excuse to make web pages' sizes even larger :). Btw, I'm not against the idea of…

There is an idea that the runtime could be hosted from a common CDN and then cached by the browser across applications so you only have to download the runtime once. Combined with browsers caching the compiled versions of the wasm modules, the cost of the large runtime might be pretty minimal in practice.

That was tried and failed already with JavaScript libraries.

Look at something like jQuery. Let's assume for the sake of discussion there are 50 versions of jQuery (that's a low estimate), and 6 majorly used CDNs. That's 300 distinct cachable items. Now add in that most people now use multiple devices, and that caches are generally completely full and evicting things constantly. The chances of having a specific version from a specific CDN on the specific device is actually pretty low.

Now multiply that whole thing by another 100 libraries that all want to be the next jQuery. It's just not going to happen.

And cross-domain or content based caching isn't a solution either as it's opens an extremely large security hole (basically being able to probe your cache checking if a specific hash or content exists in it).

I'd much rather spend our collective time improving dead code removal tools and optimizing tightly linked bundles of libraries to give each web application it's own customized, small, optimized, and easily cachable "bundle". It avoids the reliance on 3rd party CDNs, it gives control over caching behavior back to the original website, it improves security, and can be faster (both in download speed and runtime speed).

Re: Hello wasm-pack

#134

Post by pjmlp »

steveklabnik wrote: post #107
themihai wrote: post #104

Earlier quoted context omitted.

>> One good reason is binary size; JS is going to have the advantage here since its runtime is already installed. Yeah, that's true now though I don't think there is something that stops browsers to host a runtime(i.e. a pre-loaded std wasm library + wasm-gc) to help the languages compiled to wasm to reduce their compilation size. The question is really whether the browsers want to make WASM a first class citizen or…

There’s some complexity, but yeah they could do that. I really doubt it will happen; if we couldn’t get browsers to include jQuery, why would they do this? It’s even harder than that would be. > reach not on merit Node’s popularity and success is counter to this notion, IMHO. Seriously, lots of people love JavaScript.

I doubt many would pick JavaScript if given the option on the browser side.

Regarding node it has two things going for it, the frontend devs that only know JavaScript and try to do server side as well.

The fact that thanks to its world class JITs (V8 and ChakraCore) it easily beats Python and Ruby interpreters in performance, which are the most common deployed variant.

Re: Hello wasm-pack

#135

Post by pjmlp »

austincheney wrote: post #79
IshKebab wrote: post #73

Earlier quoted context omitted.

Let's be real, the goal of WebAssembly is to replace JavaScript, but providing alternatives to it. The whole "WASM doesn't replace JS!" thing is pretty much just to placate the "But what's wrong with Javascript?!" crowd.

I disagree from a technical perspective. WASM is a box much like an iframe or a Java applet or Flash media. Therefore the things contained within that box are isolated from the things outside that box. JavaScript, on the other hand, operates outside that box and, with appropriate bindings, can interface with APIs inside that box. The WASM will replace JavaScript argument exists not for any valid technology reasoning,…

Now imagine web sites written 100% in WASM, just like they were 100% in Flash.

What did you won with Flash being replaced?

Re: Hello wasm-pack

#136

Post by amelius »

themihai wrote: post #11

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

> I would rather like to see better interop between different languages using wasm

Yes, and garbage collection that crosses language boundaries.

Re: Hello wasm-pack

#137

Post by jlebrech »

"WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript."

NO, Replace Javascript, replace HTML, replace CSS.

Re: Hello wasm-pack

#138

Post by jlebrech »

austincheney wrote: post #23
themihai wrote: post #11

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.

you only need js to bootstrap wasm onto a canvas. then write the rest of your "site" in QT or GTK ;)

Re: Hello wasm-pack

#139

Post by alex_duf »

steveklabnik wrote: post #17
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?

That’s the “host bindings” proposal. All of this tooling has been written to be forward-compatible with it, so whenever that lands, you can upgrade the tool and get a speed boost for free.

Great!

Re: Hello wasm-pack

#140

Post by alex_duf »

grayrest wrote: post #16
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?

I believe that'd be a follow-up to the host bindings proposal [1]. [1] https://github.com/WebAssembly/host-bindings/blob/master/pro...

Thanks for the link!
Post reply on HN