Hacker News new | past | comments | ask | show | jobs | submit login

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. It’s a non-goal.




>> 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 would compile to WASM(along with DOM/webAPI access)? The ecosystem may be a reason but that's only a matter of time(i.e. 1 -2 years).


One good reason is binary size; JS is going to have the advantage here since it’s runtime is already installed.

Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.


>> 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 not.

>> Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

I believe WASM could serve the other lot of people who are not that much into JavaScript. Using the same language on server and browser also reduces friction(i.e. see NodeJS). Personally I believe JS has a such rank based on reach not on merit.


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.


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.


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


>Using the same language on server and browser also reduces friction(i.e. see NodeJS). Personally I believe JS has a such rank based on reach not on merit.

And yet somehow thanks to NodeJS, javascript development seems to have gotten exponentially more complex.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: