[tel]

I feel like you've not seriously used each of them. Ghcjs is very interesting, but also very, very early. The ecosystem is tiny, the compiler produces huge and slow builds, the interop is tricky, the semantics imperfect. It may be a very long time before any of those are resolved, too! Compiling a lazy language to Javascript is no simple trick. Luite deserves all the praise in the world for getting it this far... but there's just a long way to go.

So, in the terms of this article, Ghcjs might be around the same place Scala.js was 2 years ago. In the mean time, Scala.js has taken off in a lot of ways. It's yet to be seen what will happen with Ghcjs.

[willtim]

Your hunch is correct, I have not really used either, I'm just generally interested. From a distance, they both appeared to be ambitious and somewhat immature. I'm curious about your comment regarding tricky interop and "imperfect semantics" of ghcjs, could you elaborate? Certainly laziness does make FFI harder, but I wouldn't call that a problem with the semantics.

[tel]

Laziness doesn't just make FFI harder (although it does do that too) it also makes code generation harder and implies the need for a sophisticated runtime. All of this makes the generated code bigger, slower, and more opaque.

A strict language can just skip all of that so long as it's willing to live within the limitations of the Javascript model. Scala.js does that for the most part and ends up with both nice FFI and a minimal runtime.

[willtim]

I don't see being strict or lazy as being the main source of the size of the deployed code (especially as Ghcjs inherits an excellent strictness analyser from GHC). Scalajs would have to emulate many JVM characteristics and port many JDK classes. Then you have huge core Scala libraries like collections, which are far larger and more complex than the Haskell equivalents. You will have to back up your argument with numbers to convince me. You also haven't elaborated on your comment about "imperfect semantics".

[tel]

I'm not really interested in putting in the effort to convince you. This opinion arises from conversation I've had with users of ghcjs, developers of ghcjs, and people very familiar with GHC compilation pipeline details and runtime details.

The last I heard, the primary dev of ghcjs intended to build a new codegen which would alleviate some of the issues here, but that hasn't happened yet to my knowledge.

The comment about imperfect semantics arises from a few weirdnesses around JS interaction with laziness. Perhaps the biggest one I remember is that when calling Haskell from JS you have to be prepared for the idea that results may not be fully evaluated. There wasn't any real mechanism to force and block on the Javascript side and certainly no mechanism to handle it asynchronously (promises wouldn't work unless they decorated inner layers of a data types which would be terrible).

This also plays out on the Haskell side in terms of managing retention strategies.

In a strict language both of these obviously just vanish.

[premium-concern]

The main difference is that Scala.js people sat down and did all the painstaking work, while Haskell devs spent the time talking how intellectually superior the are and got nothing done.

[codygman]

> Haskell devs spent the time talking how intellectually superior the are and got nothing done.

I could give a recap of Haskell development that's happened while Scala.js has been developed to debunk this silly accusation, but it wouldn't change your mind.

[premium-concern]

Well, Scala.js went from not existing to rock solid in 3 years. The various Haskell-to-JS efforts existed much longer, but none have the support, completeness and maturity of Scala.js.

[dllthomas]

FWIW, this matches my understanding of the situation with Ghcjs, although there's substantial risk that my understanding is dated.