…after developing some toy projects with [Clojure] I came to the conclusion that you need to know the host language very well to be able to use it.

I think it’s important to be able to read the host language and be familiar with its idioms, and of course the ease of doing that scales up with ones reading proficiency in the host language.

danielo515:

In fact being able of writing stuff that will run on the JVM without writing any Java was one of the main selling points, but seems to be impossible.

I think the most Java I’ve written in a Clojure context was some throwaway code demonstrating a minimal example of a bug in a Java package over which I maintain a Clojure wrapper. The Java was only necessary because I wanted to literally “speak their language” when reporting the bug.

I think it’s quite rare for Clojurists to write any Java for their Clojure projects. Have you found it necessary?

I think it’s quite rare for Clojurists to write any Java for their Clojure projects. Have you found it necessary?

Sorry if I gave the impression that I wrote anything apart from configurations in Clojure. I only tried ClojureScript under nodejs. I didn’t need to write javascript code, but I had to write some code that was just javascript with a different syntax. Based on that experience I extrapolated that to Clojure. Maybe my judgment was not fair knowing that ClojureScript on node was not the primary target of the community and that may be the reason why I had to write so many interop by hand.
Maybe I am mistaken and it is different for Clojure, which is the original language and server side java is the main target

To answer the original question, for me, the killer feature of ClojureScript is the way atoms are built into the language and enable an observer pattern that works flawlessly and with the full complement of the built in language features.

This feature does what redux + immutable.js, mobx, and similar libraries try to do in JS. But these libraries all require you either to conform to a subset of the language (e.g., in mobx you have to manipulate arrays carefully) or require a giant amount of boilerplate and careful coding conventions (redux).

In cljs, you can just manipulate the state and everything else happens automatically. It seems to me that it is just not that easy to replicate this feature in javascript in a natural way.

I guess I’m starting to realize, maybe most of the ClojureScript trade-offs were due to its compiler being Clojure only. The special handling of macros, the fact very little is reifiable, the lack of eval, the more complicated repl setup, etc.

Now that self-hosted ClojureScript is real, do you think we could see some of those trade-offs be revisited? Maybe once the JavaScript Google Closure variant is out of alpha? Like reintroducing reified vars and namespaces, adding eval back, letting macros live in cljs namespaces, etc.?

Let’s not conflate quirks with explicit design choices. Self-hosted ClojureScript is impractical for most web applications due the order of magnitude increase in the base payload. Making self-hosted ClojureScript act differently is a portability liability.

Suffice to say the semantics of ClojureScript haven’t changed in many years and they aren’t going to.

I get where you’re coming from (switched to cljs 2-3 years ago from react+webpack). It’s not “just” hot reloading though, with figwheel you get a REPL into the app running in the browser. That just comes with the figwheel setup, and it integrates very well with Cursive in IntelliJ (switches the REPL to cljs mode) and Emacs, I imagine, for those with enough grit

This means that I can evaluate stuff in my REPL that directly uses re-frame’s “live” db atom, and events, subscriptions as well. I can trigger DOM events, or query the DOM, play around with my own namespaces and functions, mess around with Google’s Closure library, and so on. All the benefits of the REPL-workflow combined with hotreloading … unmatched, so far. Don’t forget that you’re getting all the other benefits from using Clojure in the first place, for which you’d need strong conventions, libraries and/or tooling set up (Immutable.js and friends) in webpackland.

I get the sense that many Javascript refugees just use hot-loading, which is familiar from their previous ecosystem, without ever realizing the tremendous advantages of also having an editor-connected REPL.

Getting a CLJS repl to work is incredibly difficult and conceptually difficult for newcomers like me to understand given all the multitude of cooperating libraries and servers and clients and keeping it distinct from the CLJ repl.

To be good in a repl you need to understand the namespace system well. I feel constantly stymied at trying to get the right commands issued so that I can actually call functions from other namespaces.

So hot loading is a godsend. I just use console print statements as a slightly slower repl where my editor does the “R” and the browser does the “EPL”.

It’s probably a good idea to understand the namespace system well in any case if you are at all serious about writing clojure(script) programs.

Anyway, I absolutely agree that the tooling could be better, but I think in addition that there’s a failure to really teach the whys and hows of the interactive style of programming, which is a shame. We’ve tried to make a teaching environment to help, but ultimately direct mentorship might be the best model here.

Based on that experience I extrapolated that to Clojure. … Maybe I am mistaken and it is different for Clojure, which is the original language and server side java is the main target

Like @dave.liepmann, in my seven years of production Clojure, I don’t recall having to write any Java code at all. With some libraries that I’ve chosen to use, I’ve had to rely on the interop syntax more than I would have liked – but, trust me, the Clojure-with-interop code was still a fraction of the size of the equivalent Java and much, much more readable!

Haskell’s JavaScript story is just not as far along as Scala / Scala.js or Clojure / ClojureScript. I’ve asked around members of the Haskell community about this and we’re really way further along. PureScript, Elm etc. are not Haskell.

Scala.js is not Scala.
ClojureScript is not Clojure.
PureScript is not Haskell.
Both languages per line have however very strong similarities and are super easy to pick up when you know the other.