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

141–150 of 160 posts

Re: Hello wasm-pack

#141

Post by pygy_ »

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…

You can defeat inlining by using closures:

    function thunk(x){ return function() { x() } }
    const thunkFoo = thunk(foo)
    const thunkBar = thunk(bar)

    for(var i = 0; i
This is why the "Maybe you don't need Rust to speed up your JS" author was creating functions dynamically using `new Function()`.

Maybe you cal get away with

    function call(x){ x() }
    for(var i = 0; i
I didn't test the latter though, whereas the former is empirically slower if you call more than one thunk in your benckmark loop (a single thunk will have the call inlined).

https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

Re: Hello wasm-pack

#142

Post by bigato »

jlebrech wrote: post #138
austincheney wrote: post #23

Earlier quoted context omitted.

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 ;)

Is this possible already? I'd love to build web CRUDs using tcl/ttk for the GUI part

Re: Hello wasm-pack

#143

Post by themihai »

fulafel wrote: post #131
themihai wrote: post #84

Earlier quoted context omitted.

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 clie…

Elm was designed to be transpiled into javascript just like CoffeScript so let's put it aside for a moment. WASM is work in progress so I'm sure that if people care enough they can find solutions for such specific issues(i.e. seems that VM languages have their own set of issues). There is a GC proposal so managed languages will benefit a lot(i.e. smaller runtime).

JS is a high level language. I don't see many people compiling to managed languages outside of the browser. Wonder why is that? Few target JVM...but I don't see many(if any) compiling to Java, C#, Ruby or Lua or PHP. I've never seen anyone compiling JavaScript either unless they had to run it in a browser. This should tell you how good JS is when it has to compete on merit as compiler target.

Re: Hello wasm-pack

#144

Post by tschneidereit »

ridiculous_fish wrote: post #95

In its wasm-rewrite, the source-map module acquired a destructor that must be manually invoked by its clients [1]. This makes the API much worse. Is this typical of JS APIs that use wasm? 1: https://github.com/mozilla/source-map#sourcemapconsumerproto...

This is indeed a problem for Wasm/JS integration. The JS WeakRef proposal[1] will address it for many use cases, and the WebAssembly GC proposal[2], combined with JS Typed Objects[3] will address many others. Even before those features will be available, I'd expect the community to iterate on patterns to make APIs nicer.

[1] https://github.com/tc39/proposal-weakrefs [2] https://github.com/WebAssembly/meetings/blob/master/2018/pre... [3] https://github.com/tschneidereit/typed-objects-explainer

Re: Hello wasm-pack

#145

Post by fulafel »

themihai wrote: post #143
fulafel wrote: post #131

Earlier quoted context omitted.

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 clie…

Elm was designed to be transpiled into javascript just like CoffeScript so let's put it aside for a moment. WASM is work in progress so I'm sure that if people care enough they can find solutions for such specific issues(i.e. seems that VM languages have their own set of issues). There is a GC proposal so managed languages will benefit a lot(i.e. smaller runtime). JS is a high level language. I don't see many people…

Elm semantics is very far from JS - it's a kind of Haskell-lite. The tooling and diagnostics are very much custom and don't rely on JS developer tools or source maps. (Also, "transpile" is just another word for "compile")

Re: Hello wasm-pack

#146

Post by jlebrech »

bigato wrote: post #142
jlebrech wrote: post #138

Earlier quoted context omitted.

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

Is this possible already? I'd love to build web CRUDs using tcl/ttk for the GUI part

you could use emscripten to compile to wasm as a target https://kripken.github.io/emscripten-site/docs/compiling/Web...

Re: Hello wasm-pack

#147

Post by mwcampbell »

steveklabnik wrote: post #74
ndarilek wrote: post #66

Earlier quoted context omitted.

Got it. I assume the unknown target will never be able to link against native libraries beyond those provided by Rust's core itself? I assume the answer is no, but a few years ago I assumed I wouldn't ever be able to do what wasm is letting me now, so I don't want to hold too tightly to those assumptions. :)

By “native libraries” you mean “C libraries”? If so, then that’s correct, as rustc can’t compile C code. You need a C -> wasm compiler, and that’s emscripten. Hopefully we’ll have built the ecosystem enough that you won’t need to rely on those libraries :)

Unless I'm misunderstanding, this sounds like a mistake to me. On any other platform, Rust interoperates smoothly with C libraries and does not demand purity. There's lots of existing code written in C, and expecting all of it to be replaced with pure Rust libraries is unrealistic.

Also, doesn't clang also have a wasm backend now? Emscripten isn't the only option.

Re: Hello wasm-pack

#148

Post by steveklabnik »

pjmlp wrote: post #134
steveklabnik wrote: post #107

Earlier quoted context omitted.

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.

You're just repeating the same thing as the parent. I don't think that's true. People legitimately love JavaScript.

Re: Hello wasm-pack

#149

Post by steveklabnik »

mwcampbell wrote: post #147
steveklabnik wrote: post #74

Earlier quoted context omitted.

By “native libraries” you mean “C libraries”? If so, then that’s correct, as rustc can’t compile C code. You need a C -> wasm compiler, and that’s emscripten. Hopefully we’ll have built the ecosystem enough that you won’t need to rely on those libraries :)

Unless I'm misunderstanding, this sounds like a mistake to me. On any other platform, Rust interoperates smoothly with C libraries and does not demand purity. There's lots of existing code written in C, and expecting all of it to be replaced with pure Rust libraries is unrealistic. Also, doesn't clang also have a wasm backend now? Emscripten isn't the only option.

It's because this is all a little more complex than that.

Clang does have a wasm backend, same as the unknown target. It suffers the same problems; that is, one of the things that emscripten does is provide a runtime/support code that does things like "automatically translate opengl to webgl". That is, one of emscripten's major goals is "get code that was never assumed to be able to run on the web to run on the web with as little hassle as possible." Outside of the web, those C libraries were very much intended to work on the native platform. So there's extra complexity there.

We continue to support emscripten for when you need this use-case, but it effectively only works if you're building an application, not a library, and we want to support people writing libraries.

Re: Hello wasm-pack

#150

Post by Touche »

themihai wrote: post #88
Touche wrote: post #50

Earlier quoted context omitted.

You already got that from asm.js though.

why to use a half baked solution than something designed from the ground up for the job?

I don't read binaries so I don't particularly care how hackish the solution is as long as it works. There are benefits to wasm of course, but running C code in the browser isn't one of them.
Post reply on HN