spyder81

Thanks! (I'm the author). I focussed on JavaScript because it's what I know, it's my day job, and I wanted to share a bit of my research while trying to introduce AltJS to it.

I wasn't (and am still not) really enough of an expert in either Haskell or OCaml to talk about other differences; including a bunch of dot points I don't understand wouldn't help anyone :)

As far as I can tell Elm is more of a GUI focused language, when I was evaluating AltJS languages I was looking for something a bit more low level. The JS and DOM bindings of js_of_ocaml were what really sold me although I didn't mention this in the post.

I knew about scala.js when writing the post (although it was still experimental at the time) but I didn't mention it because I don't like Scala. It looked promising when I first saw it, but then I had to write some production code in it.

My opinion now is that if you're forced to use the JVM then Scala is one of the best options. But that's a low bar, given the choice I would pick something else.

I'm the author, and to be honest I agree. I was still fairly new to OCaml (and ML in general) at the time, so I tried to focus on what I knew rather than rattle off a list of things I had heard were better but didn't really understand.

Well, sort of. It's possible if you're willing to take on maintenance of that library if/when they abandon it, and be able to dive into the guts to track down bugs or weird behaviour.

As a good example, we're on the verge of ditching JQuery.

I don't think multicore will be touted as a reason to choose OCaml over Haskell, but it will remove one of the reasons to avoid OCaml. Subtle but important difference :)

I haven't, no. We excluded the vast majority of AltJS languages as the size of community and availability of third-party libraries was a significant factor in the evaluation.

OCaml has quite nice JavaScript integration; it has the ability to interact with JS objects, constructors, DOM objects, etc. See the "dom bindings" thread elsewhere in this discussion.

Most other AltJS languages I've seen are primarily based around FFI declarations, where all interaction with JS is done via functions declared in the native language as external and implemented in JS.

For me (the author), it's because SML as it was taught to me is a closed language. It can never and will never change. Perfect for education, perhaps not so useful as a career choice.

OCaml has been moving forward; GADTs were added recently, multicore support is coming, and who knows what else is on the horizon.

I've put a lot of work into a compile-to-JS evaluation for my day job. It's not suitable for public consumption, but of our top 5 choices:

- both Kotlin and ClojureScript don't compile code written in their "native" language (java) to JavaScript, limiting the ability to leverage existing libraries. - ScalaJS is still experimental. - Haskell looked promising, I asked a haskell programmer to run that evaluation for me, but fay/haste aren't complete enough for serious (non-ui) JavaScript work and GHCJS generates 5mb JS files. - OCaml had a viable project in about half the time I estimated it would take.

And on a personal note, Scala seemed great at first but after SML/OCaml I find the number of times that I have to tell the type checker what I'm doing immensely frustrating :)

I looked at Haskell options - fay and haste are both good, but not complete (try compiling tagsoup). GHCJS works, but generates 5mb JavaScript files.

This is what I meant when I said "by virtue of support for existing libraries". js_of_ocaml translates compiled bytecode and can therefore make any pure OCaml library work in JavaScript without recompilation.

I have to admit JavaScript isn't the only driver for my interest in OCaml. It is however the angle I'm pushing for using it in my day job :)

Yeah, I should've addressed this in my post. Right now multicore doesn't mean squat to me as I'm using it for JavaScript support. I did investigate this, but forgot to add the links (others have already replied with) about work that is progressing nicely.

I'll update the post once this traffic calms down a bit :)

js_of_ocaml has excellent DOM bindings: http://ocsigen.org/js_of_ocaml/api/index

I'm also looking at whether TyXML can be used with js_of_ocaml for statically typed goodness: http://ocsigen.org/tyxml/