[stijlist]

It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.:

> If you look at other compile-to-JS languages like:

> - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskell-to-Javascript compilers (Haste, Faye) > You'll notice one thing in common: none of them have a standard way of writing code that runs on both their "original" runtime (JVM, MRI, CPython, CLI, ...) and on Javascript. And the reason why is straightforward: none of them are compatible enough, complete enough to really let you write "full" Java/Ruby/Python/C#/etc..

ClojureScript is mentioned in the article, but only for this specious comparison:

> Clunky Interop > Many other languages are not as fortunate. For example, here's how you create an element in ClojureScript, compared with Javascript

(let [paragraph (.createElement js/document "p")] (set! (. paragraph -innerHTML) "<b>Bold!</b>"))

var paragraph = document.createElement("p") paragraph.innerHTML = "<strong>It works!</strong>"

> Now, the conversion between these two snippets is mechanical, so it's not something you need a PhD to perform. Nevertheless, it is clear that using Javascript APIs in ClojureScript, while looking like ClojureScript, looks almost nothing like the Javascript it represents.

> This mapping is something that everyone who wishes to learn Clojurescript will have to internalize.

This seems misinformed at best - both Clojure and ClojureScript have interop as a first-class concern, and interop forms are exactly the same between them.

I appreciate the work that Li's done, but I'm disappointed by what seems like a rather disingenuous omission of the only other language which fulfills Li's criteria.

Interop, IDE support (IntelliJ), parent language compatibility, static optimization (judging by the payload size numbers, ClojureScript utilizes dead-code elimination more effectively than Scala.js), performance (ClojureScript immutable vectors are faster to build than JavaScript arrays, far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has been - since 2011) a compile-to-JavaScript language that is in the same league as Scala.js, and arguably eclipses it on many dimensions.

A language-agnostic comparison can't reasonably leave out ClojureScript.

[methehack]

I'm glad you pointed this out. That's way mal-informed for how you'd build that DOM in clojurescript. I mean, you _could_ do it that way, but there are libraries (like hiccup) that make it more natural.

Here's an example of a react component from the re-agent tutorial (http://reagent-project.github.io/), e.g., but you'd build straight html in the same-ish way using a library:

  (defn simple-component []
    [:div
      [:p "I am a component!"]
      [:p.someclass
        "I have " [:strong "bold"]
        [:span {:style {:color "red"}} " and red "] "text."]])

[lihaoyi]

The point wasn't to show how to build HTML fragments, the point was to show javascript interop.

You could create a nice wrapper-library around anything in any-language, really, but that misses the entire point of that example: to show how interoperability is when you haven't wrapped a nice wrapper-library around everything.

[tel]

Except for: types. That's a big deal about what the author liked about Scala.js.

[stijlist]

It wasn't mentioned as a criterion, and OpalRuby, Python variants, and Coffeescript all got significant discussion in the article. The ClojureScript omission on all the axes other than "superficial similarity to JavaScript" is still pretty glaring.