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

151–160 of 160 posts

Re: Hello wasm-pack

#151

Post by themihai »

fulafel wrote: post #145
themihai wrote: post #143

Earlier quoted context omitted.

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

Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser? Why nobody compiles to JS outside the web browser if it's such a good compilation target?

>> Also, "transpile" is just another word for "compile"

Well, I prefer to use the "transpile" term when the target is a high level language.

JavaScript is a high level language. It seems some smart folks decided that a new "language/IR" is needed (wasm) so that people can use other languages on the web. Now let's make this new IR a first class citizen on the web.

Re: Hello wasm-pack

#152

Post by fulafel »

themihai wrote: post #151
fulafel wrote: post #145

Earlier quoted context omitted.

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

Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser? Why nobody compiles to JS outside the web browser if it's such a good compilation target? >> Also, "transpile" is just another word for "compile" Well, I prefer to use the "transpile" term when the target is a high level language. JavaScript is a high level language. It seems some smart folk…

I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript.

WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to a byte addressable, untyped program heap.

Re: Hello wasm-pack

#153

Post by themihai »

fulafel wrote: post #152
themihai wrote: post #151

Earlier quoted context omitted.

Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser? Why nobody compiles to JS outside the web browser if it's such a good compilation target? >> Also, "transpile" is just another word for "compile" Well, I prefer to use the "transpile" term when the target is a high level language. JavaScript is a high level language. It seems some smart folk…

I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript. WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to…

What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?

Re: Hello wasm-pack

#154

Post by bajablast »

themihai wrote: post #91
steveklabnik wrote: post #85

Earlier quoted context omitted.

There’s a bunch of uses of wasm outside the browser. I’m personally not a huge fan of crypto currencies, but Etherium is looking to use it as a language for smart contracts, for example. Just like any small language, you can embed the interpreter into whatever and use it for scripting; the spec is written so that this is pretty easy. That said, none of this means “replacing” JavaScript, no matter what the parent says…

>> That said, none of this means “replacing” JavaScript, no matter what the parent says. It’s a non-goal. I believe a better term would be "skipping" javascript than "replacing" javascript. There won't be many rewrites but I'm sure that many people would skip JS on new projects if they would have that option. Why would a Python, Go, Ruby developer choose JavaScript over Python given that their language of choice woul…

Python and Ruby will never compile to WASM since they would need to have the entire interpreter compiled with it and it would be extremely slow and bloated experience. Not to mention those languages do not have very good support for async operations and the lack of closures make it a terrible idea for the web.

Re: Hello wasm-pack

#155

Post by bajablast »

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.

Let me see. A lazy developer that only knows Ruby compiles the entire Ruby interpreter into WASM just to run Ruby. Then the user clicks a button that does an API fetch and the whole browser freezes while it waits for the response. . . . Yeah not happening. WASM was built and meant for high performance low level languages, there is no way in Ruby and Python will make the cut.

Re: Hello wasm-pack

#156

Post by fulafel »

themihai wrote: post #153
fulafel wrote: post #152

Earlier quoted context omitted.

I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript. WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to…

What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?

Let me count the ways:

- code size - a runtime for a managed language is much bigger if you have to reimplement & ship the primitives you get from the JS platform.

- implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

- poor cross-browser development tooling support to have a good debugging experience

- GC implementation complexity and performance - firstly, there is no GC support currently and no timeline about when/if something materalizes. The current "future GC" support in webassembly[1] doesn't provide a GC implemnetation, just hooks to peacefully coexist with JS GC.

- JS interop

- browser support

Now, it may be that some of these get solved eventually - but they would all have to be solved, with high quality solutions, to beat JS as a managed language compile target.

[1] https://github.com/WebAssembly/reference-types/blob/master/p...

Re: Hello wasm-pack

#157

Post by pjmlp »

bajablast wrote: post #155
pjmlp wrote: post #134

Earlier quoted context omitted.

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.

Let me see. A lazy developer that only knows Ruby compiles the entire Ruby interpreter into WASM just to run Ruby. Then the user clicks a button that does an API fetch and the whole browser freezes while it waits for the response. . . . Yeah not happening. WASM was built and meant for high performance low level languages, there is no way in Ruby and Python will make the cut.

That lazy developer will download a Ruby WASM based VM that someone else compiled for them.

Also the revival of Java, .NET, Flash, ActiveX is already brewing, this is not only about Python and Ruby.

Just doing games in Unity, compile to WASM and deploy, just like plain old Flash.

And while at it, use the 2D GUI to build a complete web site, just like plain old Flash.

The difference is now we can all be happy, because it is a Web standard.

Re: Hello wasm-pack

#158

Post by creatonez »

maxyme wrote: post #51
mpolichette wrote: post #18

I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect. https://hackernoon.com/im-harvesting-credit-card-numbers-and...

You could already do this tons of ways. Native modules come to mind.

Which don't run in browsers

Re: Hello wasm-pack

#159

Post by themihai »

fulafel wrote: post #156
themihai wrote: post #153

Earlier quoted context omitted.

What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?

Let me count the ways: - code size - a runtime for a managed language is much bigger if you have to reimplement & ship the primitives you get from the JS platform. - implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in. - poor cross-browser development tooling support to have…

>> - implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

I strongly disagree. Wonder why no language(managed or unmanaged languages) designer uses this gem named JavaScript as compile target?(web stuff excluded)

It seems your whole argument revolves around the fact that JS has better support than WASM in browser. We already know this. WASM is a work in progress. It's not ready yet for prime time. This year we will get some managed languages compiled to WASM. Next year we might get GC. I believe in some distant future javascript will be compiled to wasm either by the client or by the browser itself(for backward compatibility). JavaScript is JIT-ed in the browser anyway.

Re: Hello wasm-pack

#160

Post by Nekorosu »

IshKebab wrote: post #108
austincheney wrote: post #96

Earlier quoted context omitted.

Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started. As others have mentioned there is the hosting bindings API that is well underway, which provides web APIs to the WASM container so that code compiled to WASM can interact with the JavaScript outside it. This doesn't sound like what you are hoping for though. At this time, and for the foreseeable future, there are no…

Code compiled to WASM can already access Javascript outside it. Obviously. Otherwise how could it do anything at all?? > Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started. I didn't say work had started on it. I just said that it is planned. See here for proof: http://webassembly.org/docs/high-level-goals/ > access browser functionality through the same Web APIs that…

> Otherwise how could it do anything at all??

By passing data.

Post reply on HN