Hacker News Reader

Comment by addisonj | Hacker News Reader

Prepare for the onslaught of new (and old) languages targeting the web.

While this is welcome news, I am also torn. The possibilities are pretty amazing. Think seamless isomorphic apps in any language that can target WebAssembly and has a virtual dom implementation.

However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform.

Either way, it will be an interesting time... and a time to keep up or risk being left behind.

View on HN

> However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform.

This announcement means JavaScript can no longer rely on "you must target JavaScript to work on the web" as a motivating factor. The set of people who like JavaScript as a language in its own right can keep using it, and will have the advantage of new JavaScript engines and extensions implemented on top of WebAssembly. However, the set of people who would rather write in another language will no longer be constrained by waiting for JavaScript to catch up.

Personally, I think this will be a good thing for both JavaScript and other languages.

I'm 100% ready to jump ship there. I would rather work at a shop that does any other language besides Javascript for web guis even with more than a decade of js dev under my belt. The problem is they are impossible to find.

> The problem is they are impossible to find.

Scala.js[0], GHCJS[1], and Js_of_ocaml[2] among others.

[0] http://www.scala-js.org/

[1] https://github.com/ghcjs/ghcjs

[2] http://ocsigen.org/js_of_ocaml/

Languages that compile to JS are plentiful; shops that use those languages are much less so (with the possible exception of coffeescript).

I believe smrtinsert is referring to places that you could work at to write those languages, not that the languages themselves are impossible to find. I don't know if anyone is actually being paid by someone else to write ScalaJS, GHCHS and/or Js_of_ocaml.

> places that you could work at to write those languages

Ah, missed that, assumed OP meant if only there was a way to write JS without having to write JS.

There are some end to end Clojure shops. Pretty sure Relevance uses cljs.

I have already replaced all JavaScript with Go (by using GopherJS compiler) in my personal projects, as of about a year ago.

I am really enjoying it and I don't see myself going back to writing JavaScript by hand anytime soon. I use it to do some frontend stuff that involves DOM manipulation, XHRs, WebSockets. Another use is WebGL, it allows me to write simple multi-platform games in Go that target OS X, Linux, Windows, but also the browser. I would not be writing those games in JavaScript by a long shot.

> Prepare for the onslaught of new (and old) languages targeting the web.

"Prepare for"? As if that hasn't happened already, with virtually every modestly popular language having at least one web-use-oriented compile-to-JS transpiler, and several new languages being invented whose only implementation is such a transpiler.

WebAssembly makes the process easier, and may make it easier to maintain those along with the non-web implementations of the languages, but its a little late to prepare for the onslaught of web-targeting language implementation.

True, but they have (generally) been second class citizens with very little adoption, mostly because targeting JS has had quite a few drawbacks, such as huge payload size or tons of time to parse and optimize.

Assuming wasm delivers on its promises, that should change, and that is when those languages will stop being mostly experiments but real viable platforms.

WebAssembly still has a long way to go. They don't have a plan yet for:

* GC

* Interoperating with browser objects (even strings)

* Debugging and other tooling

I don't think any high level language will be able to compete with JS on an even playing field until that language can use the high performance GC that's already in every browser.

If your language has to either not use GC (huge productivity loss) or ship your own GC to the end user with your app (huge app size), it's an unfair fight.

Right now, though, all non-JS languages are second class citizens. They have to be turned into JS to actually run, and JS gets to run natively. This has huge implications for debugging, among other things.

And that won't change in the MVP of this, where JS will still have capabilities that WebAssembly-targeting languages won't have. But their clear vision is to make WebAssembly a VM that puts languages on equal footing, with tooling and debugging that works cleanly for all targets.

> Prepare for the onslaught of new (and old) languages targeting the web.

I'm not even joking when I say an RPG IV compiler would probably make you some cash.

Of course, I knew people who wrote their website in COBOL (Micro Focus COBOL to be specific). This would probably please them greatly.

Eh, the problem with JS is that it's starting to suffer the language feature bloat that, say, C++ has. I think the party will end in like 5 years, mostly after introduction of shared memory objects and traits.

Meanwhile, this is going to allow people to port really dumb things into the browser and expose all sorts of new crazy.

Still neat, I agree, if you prefer native code. That said, it's not an unalloyed good.

Not sure what you mean by virtual DOM. From the WebAssembly FAQ: "Is WebAssembly trying to replace JavaScript?

No! WebAssembly is designed to be a complement to, not replacement of, JavaScript (JS). While WebAssembly will, over time, allow many languages to be compiled to the Web, JS has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. "

https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

The WebAssembly team is being incredibly thoughtful and open about their motivation and long-term plans, which is very refreshing.

Reply on news.ycombinator.com