6 ms·

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinati

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

michaelsbradley 13y ago
And if you want to leverage those functional data structures in a vanilla JavaScript context, there's a pre-compiled ClojureScript library for that! http://swannodette.github.io/mori/ http://swannodette.github.io/mori/ https://www.npmjs.org/package/mori https://www.npmjs.org/package/mori
camus2 13y ago
clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.
- michaelsbradley 13y ago
  Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3] to David Nolen's mori library. [1] http://leiningen.org/ http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json#L41 https://github.com/swannodette/mori/blob/master/package.json...
  - jkrems 13y ago
    Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.
    - michaelsbradley 13y ago
      Getting the JVM installed requires very little effort. On ubuntu linux, for example, apt-get can be used to install openjdk or Oracle's distribution. Travis CI provides java (with a choice of JDKs) in its testing environments. So, I understand your point, but the installation "overhead" seems more like a mole hill, hardly amounting to even a speed-bump sized obstacle.
      - jkrems 13y ago
        I recently had write up for a README how to install the JDK and set it up correctly on OSX. You'd be surprised. Thanks to Oracle's policies it isn't even close to where other runtimes/sdks are (e.g. installing ruby, node, gcc, go, ocaml).
        michaelsbradley 13y ago
        With homebrew and homebrew-cask installed on Mac OS 10.9, I was simply able to do: brew cask install java That might not cover the bases for every Java developer's needs, but leiningen seems to work fine with the resulting installation.
        jkrems 13y ago
        I'll have to look into versions (gotta be java7) but that looks pretty great - thanks!
- auvrw 13y ago
  wouldn't it make more sense to implement the clojurescript compiler in clojurescript so it can run on node? i get disliking having to fire up the jvm versus a light runtime like python or node if that's where you're coming from, but i don't mind twiddling my thumbs for a moment when i first sit down to write clojure, because not just the language but also the libraries and tools are more fun/interesting to use than a pure node (or pure python, for that matter)두environment. in short, and not to be snide, perhaps you've already written some clojurescript, but to anyone else reading over: try writing some clojure/clojurescript. you might not like it for whatever reason, but at least then it'll be a case of "no return" instead of "no go."
  - deleted 13y ago
    [deleted]
chrisdone 13y ago
Really the only thing missing from Clojurescript, as all Lisps, is static types.
- cordite 13y ago
  This is especially a problem (which can only be discovered at runtime) with newbies. It has some nice constructs but my friends and even sometimes myself end up with problems like trying to deref an atom that is already dereffed, or not dereffing in the first place.

michaelsbradley 13y ago

And if you want to leverage those functional data structures in a vanilla JavaScript context, there's a pre-compiled ClojureScript library for that! http://swannodette.github.io/mori/ http://swannodette.github.io/mori/ https://www.npmjs.org/package/mori https://www.npmjs.org/package/mori

camus2 13y ago

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

michaelsbradley 13y ago
Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3] to David Nolen's mori library. [1] http://leiningen.org/ http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json#L41 https://github.com/swannodette/mori/blob/master/package.json...
- jkrems 13y ago
  Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.
  - michaelsbradley 13y ago
    Getting the JVM installed requires very little effort. On ubuntu linux, for example, apt-get can be used to install openjdk or Oracle's distribution. Travis CI provides java (with a choice of JDKs) in its testing environments. So, I understand your point, but the installation "overhead" seems more like a mole hill, hardly amounting to even a speed-bump sized obstacle.
    - jkrems 13y ago
      I recently had write up for a README how to install the JDK and set it up correctly on OSX. You'd be surprised. Thanks to Oracle's policies it isn't even close to where other runtimes/sdks are (e.g. installing ruby, node, gcc, go, ocaml).
      - michaelsbradley 13y ago
        With homebrew and homebrew-cask installed on Mac OS 10.9, I was simply able to do: brew cask install java That might not cover the bases for every Java developer's needs, but leiningen seems to work fine with the resulting installation.
        jkrems 13y ago
        I'll have to look into versions (gotta be java7) but that looks pretty great - thanks!
auvrw 13y ago
wouldn't it make more sense to implement the clojurescript compiler in clojurescript so it can run on node? i get disliking having to fire up the jvm versus a light runtime like python or node if that's where you're coming from, but i don't mind twiddling my thumbs for a moment when i first sit down to write clojure, because not just the language but also the libraries and tools are more fun/interesting to use than a pure node (or pure python, for that matter)두environment. in short, and not to be snide, perhaps you've already written some clojurescript, but to anyone else reading over: try writing some clojure/clojurescript. you might not like it for whatever reason, but at least then it'll be a case of "no return" instead of "no go."
- deleted 13y ago
  [deleted]

chrisdone 13y ago

Really the only thing missing from Clojurescript, as all Lisps, is static types.

cordite 13y ago
This is especially a problem (which can only be discovered at runtime) with newbies. It has some nice constructs but my friends and even sometimes myself end up with problems like trying to deref an atom that is already dereffed, or not dereffing in the first place.