10 ms·

ClojureScript Year in Review

288 points by pella 11y ago

wiineeth 11y ago
Really intresting clojure and clojurescript seems to be wonderfully designed and with the advancements that's going to take place in jvm I hope it can be as good at performance as java or Go.
- yjgyhj 11y ago
  I don't know about Go, but it certainly is as fast as Java. And it can definitely be faster than your average Java program, because you will have a really easy time doing concurrency. That is why it is a neat language, worth investigating. It is by default slower than Java and Go because the default data structures are immutable. When execution speed is more important than statelessness you can make your data structures mutable. Read more about that here http://clojure.org/transients http://clojure.org/transients Happy holidays :)
Touche 11y ago
Very cool to see such a robust community. As far as self-compilation, I haven't seen anything on how to compile a ClojureScript project without Java, is there an article somewhere on how to do so?
- cp9 11y ago
  https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting https://github.com/clojure/clojurescript/wiki/Optional-Self-... here's how to bootstrap cljs.
  - Touche 11y ago
    I don't quite follow, this creates a cljs.core "analysis cache". I don't know what an analysis cache, but I guess it is something that's needed to compile ClojureScript code? Has no one distributed such a cache in a way that it's easier to do a compile without Java installed? Is there not anything as simple as (where cljs-compile is a Node script): cljs-compile file.cljs > out.js yet?
    - spiralganglion 11y ago
      If memory serves, it is certainly possible to get up-and-running with CLJS without needing Java, but I cannot remember how. There is this tool, which might also be helpful: https://github.com/oakmac/cuttle https://github.com/oakmac/cuttle
- deleted 11y ago
  [deleted]
- _halgari 11y ago
  One of the reasons that ClojureScript is so fast and efficient is that it leans heavily on the Google Closure optimizing compiler. This compiler goes beyond normal "minimzation" and goes into dead code removal, function inlining and a ton of other stuff. That compiler is written in Java. So it's highly unlikely that JVM is removed as a dev-time requirement anytime in the near future. On the other hand, I have never really seen a need to remove it. Once the CLJS compiler is up and running, incremental compilations on huge codebases (~300 files) takes a fraction of a second. So in the end...I'd rather have the JVM as a requirement if it allows that fast of a dev cycle.
  - pjmlp 11y ago
    Another reason is that is doesn't do all the things that standard Clojure does, which are the actual cause for slowness, it is not the JVM. http://blog.ndk.io/2014/02/11/jvm-slow-startup.html http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
keldlundgaard 11y ago
For devcards, you can see the full strangeloop talk about the tool here: https://www.youtube.com/watch?v=G7Z_g2fnEDg https://www.youtube.com/watch?v=G7Z_g2fnEDg
- swannodette 11y ago
  I meant to link to that one actually. Thanks for the catch, post updated.
chowes 11y ago
I highly recommend devs (especially JS devs) try out a Clojure/script project. The tooling has improved immensely, and Cursive is one hell of an IDE. JS devs will really appreciate how clearly you can express these seemingly new frontend paradigms (immutability, one way data flow, single source of state) in Clojure. Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: https://github.com/danielsz/holygrail https://github.com/danielsz/holygrail I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?
- erichmond 11y ago
  I'm not a boot guru, so take my $0.02 with a grain of salt. I've been using boot for smaller and experimental projects because by default it feels so much leaner then leiningen does, however, because the support tooling around leiningen is still so further advanced, for project we're putting into production here, those are still all lein based. The other thing I'd say is, I've found what tool lein vs boot gets minimized over time as the project evolves. In general, I do think it's gaining traction and its a great project!
- billrobertson42 11y ago
  I've done Clojure, but haven't had much contact in the last several months, and I haven't been keeping too close tabs on the community. Regarding Boot, I just heard of it the other day for the first time. This all seems really exciting for Clojurescript. To me, it seems like it is a good option to have code that runs on multiple architectures. The ecosystem was lacking in some basics though, especially interacting w/3d party JS libraries, and I think CLJSJS (or something like it) will probably be one of the most important things for Clojurescript. Seems like there's a decent quickstart on the Clojurescript github wiki (https://github.com/clojure/clojurescript/wiki/Quick-Start https://github.com/clojure/clojurescript/wiki/Quick-Start), is there a good next-steps resource that's current?
- pgz 11y ago
  That holygrail project looks cool thanks. As a Clojure newbie, I'm not too fond of Lein to be honest.
abhishivsaxena 11y ago
Since the GSoC project mentioned still seems to be incomplete, can anyone suggest a way to use npm/es2015 modules with cljs applications for the browser? I build the first version of my app with cljs, and it was the cleanest/simplest code I ever wrote. Just the lack of npm interoperability makes in non-viable for me. Anyone tried systemjs with cljs?
- glenjamin 11y ago
  The simplest approach that works for this at the moment is to have something like webpack build a UMD bundle and then add that bundle as a foreign lib.
dmohs 11y ago
I think that cljs-devtools [1] also deserves honorable mention. Not only does this improve console output, but it improves inspection while doing interactive debugging (e.g., pause on exception) in Chrome. [1] https://github.com/binaryage/cljs-devtools https://github.com/binaryage/cljs-devtools
- dr_win 11y ago
  Thanks for the plug. I'm glad you find it useful. I've been working on Dirac - a Chrome DevTools fork for ClojureScript developers. That will be a complementary tool to cljs-devtools: https://github.com/binaryage/dirac https://github.com/binaryage/dirac
cnp 11y ago
Parinfer is the craziest lisp exponent ever. I highly recommend any curious and / or skeptical dev to download Atom, install it, and give it a shot. This book also helps: http://funcool.github.io/clojurescript-unraveled http://funcool.github.io/clojurescript-unraveled From straight up confusion to basic productivity in just a week, it has also completely removed the learning fear. Highest regards to this beautiful tool that will hopefully bring lisp to the masses.
- chrisoakman 11y ago
  Thank you for the kind comment :) I'm glad you like atom-parinfer!
modarts 11y ago
Clojurescript has made me excited about frontend again.
neoncontrails 11y ago
Diving into clj/s 4 months ago was such a wonderful, arbitrary decision. The #clojure community on Freenode is friendly and wildly clever. They are delighted to answer your Clojure questions. The language itself is great. It's a terrific language for a CS Sophomore to pick up after learning Scheme and Java. My one complaint with cljs has been the difficulty of configuring Ring HTTP beyond the trivial SPA defaults: getting it to respond to other URL requests, other types of HTTP requests. I spent close to 3 hours trying to configure it to accept a POST action before finally giving up, frustrated by the opaque stack traces that went >1000 frames deep. 20 minutes later, I had an Apache server up and running. So it wasn't really a big deal, but I can't remember the last time I felt so baffled by a problem that I simply had to throw in the towel.
- sotojuan 11y ago
  Same here! Except college senior. You are lucky to have found Clojure so young :-)
- dropit_sphere 11y ago
  If no one has suggested it before: have you tried Compojure? I know very little about http but it was a snap for me. There's even a lein template.
- yogthos 11y ago
  I put together the Luminus micro-framework http://www.luminusweb.net/ http://www.luminusweb.net/ to help with this kind of stuff. The docs provide lots of examples on how to get stuff done. For example, here's the section on doing Ajax with ClojureSCript http://www.luminusweb.net/docs/clojurescript.md#ajax http://www.luminusweb.net/docs/clojurescript.md#ajax
  - neoncontrails 11y ago
    Thanks for putting this together. This looks like a fantastic tool, and really well-documented. I noticed from a quick perusal of the docs that Luminus still requires a handler function to map URLs to a named page asset (about-page, home-page, etc.) using defroutes -- requiring too, of course, definitions for each of those pages. Could you explain in a few words why that is? Is it a Node requirement? Isn't that a lot of complexity to have to deal with? If so, how do people manage it? I'm just curious because my only exposure to the HTTP layer so far has been via Apache. Apache is... for lack of a better word, a bro. It's up for just about anything. It seems like the default mode of Apache is to do whatever the HTML recommends. Apache is happy to serve an arbitrary "/about.html" URL, provided it exists, and asynchronously execute any server-side scripts to which it injects a dependency. I don't know if this strictly requires the use of jQuery, but it certainly seems easier to do it that way. Is it even possible to serve a cljs app this way? In light of the fact that jQuery is not compatible with the Google Closure compiler?
idibidiart 11y ago
ClojureScript will enrich your mind but at some point you might get tempted, as I have, to switch to ES6/7 via the Babel route and enjoy the benefits of a much more diverse ecosystem, with your ClojureScript-enhanced perspective. Same with Elm and Haskell and prefty much any language wortg learning. In fact, learning a new language esp one drom a different world will always expand your horizon and I can't over recommend ClojureScript as one of those enlightenment languages.
- yogthos 11y ago
  I switched to using ClojureScript in prod last year and couldn't be happier. The Js interop is great, ClojureScript is fast, and the runtime is pretty small. I simply can imagine any reason to bother with ES6/7 at this point as they will offer nothing that's not already available in ClojureScript right now. You also get a clean and well designed language as opposed to a mountain of kludges that is current state of Js https://twitter.com/capotej/status/677926991513780225 https://twitter.com/capotej/status/677926991513780225
draw_down 11y ago
They do seem to be doing really nice things. And from time to time I try to keep up, watching videos on new tools and things. But I guess I always get hung up on the idea that you should just write in the language that you're targeting, and I wonder about the cost of the (admittedly pretty nice) developer experience of cljs. When you have a bug in production you're stuck debugging the generated JS. This was also my problem with CoffeeScript.
- yogthos 11y ago
  I've been using ClojureScript in production for about a year now. The runtime is very fast, and in some cases it actually outperforms native Js. For example, both Om and Reagent are actually faster than React.js itself (http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s). Debugging story is very good. You pretty much never have to see the generated JavaScript. ClojureScript uses source maps, so any errors in the compiled Js will map back to the original ClojureScript source that caused them. Chrome dev tools even do syntax highlighting for ClojureScript now. Having a live dev environment with Figwheel and a REPL goes a long way here as well. You can inspect a lot of things at runtime very easily. Using immutable data structures by default avoids a lot of the debugging pain as well. You practically never have to trace through a bunch of function calls to find the problem. In most cases the problem is exactly on the line where the error occurred.
  - draw_down 11y ago
    What if your thing crashes in IE?
    - yogthos 11y ago
      IE 11 supports source maps, so that's helpful. The other nice thing is that you rarely end up dealing with browser specific quirks since all popular ClojureScript libraries piggie back on React.js and the Google Closure library. These do a great job of handling the platform specific quirks for you. The first app I developed with Reagent actually had to run on IE8, and to my shock and surprised worked without any issues after I added the standard IE shims. So, overall my experience is that you're better off dealing with IE than with most Js frameworks.
jhund 11y ago
I'm exploring ClojureScript via the re-frame SPA pattern and it got me really excited about UI development again. What's the best way to sync data with a REST server backend?
- yogthos 11y ago
  I recommend the cljs-ajax library https://github.com/JulianBirch/cljs-ajax https://github.com/JulianBirch/cljs-ajax
- _halgari 11y ago
  I recommend the following: 1) read up on how Om.Next handles remote calls. Not that it's the only way to do it, but it de-couples the async functionality of a remote call from the rendering loop. 2) Just code against something like Google Closure's XHR libraries, making a HTTP call isn't complicated, just wrap basic functions to suit your needs. But over all, no matter what you use, core.async, or callbacks or whatever, limit the async bits to the edges of your code. Done correctly (Om.Next is a great example) you shouldn't need a whole lot of async bits to get a nice clean app. If you have core.async "go" blocks littered all through your codebase, you're doing something wrong.

288 points by pella 11y ago

Really intresting clojure and clojurescript seems to be wonderfully designed and with the advancements that's going to take place in jvm I hope it can be as good at performance as java or Go.

yjgyhj 11y ago
I don't know about Go, but it certainly is as fast as Java. And it can definitely be faster than your average Java program, because you will have a really easy time doing concurrency. That is why it is a neat language, worth investigating. It is by default slower than Java and Go because the default data structures are immutable. When execution speed is more important than statelessness you can make your data structures mutable. Read more about that here http://clojure.org/transients http://clojure.org/transients Happy holidays :)

Touche 11y ago

Very cool to see such a robust community. As far as self-compilation, I haven't seen anything on how to compile a ClojureScript project without Java, is there an article somewhere on how to do so?

cp9 11y ago
https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting https://github.com/clojure/clojurescript/wiki/Optional-Self-... here's how to bootstrap cljs.
- Touche 11y ago
  I don't quite follow, this creates a cljs.core "analysis cache". I don't know what an analysis cache, but I guess it is something that's needed to compile ClojureScript code? Has no one distributed such a cache in a way that it's easier to do a compile without Java installed? Is there not anything as simple as (where cljs-compile is a Node script): cljs-compile file.cljs > out.js yet?
  - spiralganglion 11y ago
    If memory serves, it is certainly possible to get up-and-running with CLJS without needing Java, but I cannot remember how. There is this tool, which might also be helpful: https://github.com/oakmac/cuttle https://github.com/oakmac/cuttle
deleted 11y ago
[deleted]
_halgari 11y ago
One of the reasons that ClojureScript is so fast and efficient is that it leans heavily on the Google Closure optimizing compiler. This compiler goes beyond normal "minimzation" and goes into dead code removal, function inlining and a ton of other stuff. That compiler is written in Java. So it's highly unlikely that JVM is removed as a dev-time requirement anytime in the near future. On the other hand, I have never really seen a need to remove it. Once the CLJS compiler is up and running, incremental compilations on huge codebases (~300 files) takes a fraction of a second. So in the end...I'd rather have the JVM as a requirement if it allows that fast of a dev cycle.
- pjmlp 11y ago
  Another reason is that is doesn't do all the things that standard Clojure does, which are the actual cause for slowness, it is not the JVM. http://blog.ndk.io/2014/02/11/jvm-slow-startup.html http://blog.ndk.io/2014/02/11/jvm-slow-startup.html

keldlundgaard 11y ago

For devcards, you can see the full strangeloop talk about the tool here: https://www.youtube.com/watch?v=G7Z_g2fnEDg https://www.youtube.com/watch?v=G7Z_g2fnEDg

swannodette 11y ago
I meant to link to that one actually. Thanks for the catch, post updated.

chowes 11y ago

I highly recommend devs (especially JS devs) try out a Clojure/script project. The tooling has improved immensely, and Cursive is one hell of an IDE. JS devs will really appreciate how clearly you can express these seemingly new frontend paradigms (immutability, one way data flow, single source of state) in Clojure. Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: https://github.com/danielsz/holygrail https://github.com/danielsz/holygrail I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?

erichmond 11y ago
I'm not a boot guru, so take my $0.02 with a grain of salt. I've been using boot for smaller and experimental projects because by default it feels so much leaner then leiningen does, however, because the support tooling around leiningen is still so further advanced, for project we're putting into production here, those are still all lein based. The other thing I'd say is, I've found what tool lein vs boot gets minimized over time as the project evolves. In general, I do think it's gaining traction and its a great project!
billrobertson42 11y ago
I've done Clojure, but haven't had much contact in the last several months, and I haven't been keeping too close tabs on the community. Regarding Boot, I just heard of it the other day for the first time. This all seems really exciting for Clojurescript. To me, it seems like it is a good option to have code that runs on multiple architectures. The ecosystem was lacking in some basics though, especially interacting w/3d party JS libraries, and I think CLJSJS (or something like it) will probably be one of the most important things for Clojurescript. Seems like there's a decent quickstart on the Clojurescript github wiki (https://github.com/clojure/clojurescript/wiki/Quick-Start https://github.com/clojure/clojurescript/wiki/Quick-Start), is there a good next-steps resource that's current?
pgz 11y ago
That holygrail project looks cool thanks. As a Clojure newbie, I'm not too fond of Lein to be honest.

abhishivsaxena 11y ago

Since the GSoC project mentioned still seems to be incomplete, can anyone suggest a way to use npm/es2015 modules with cljs applications for the browser? I build the first version of my app with cljs, and it was the cleanest/simplest code I ever wrote. Just the lack of npm interoperability makes in non-viable for me. Anyone tried systemjs with cljs?

glenjamin 11y ago
The simplest approach that works for this at the moment is to have something like webpack build a UMD bundle and then add that bundle as a foreign lib.

dmohs 11y ago

I think that cljs-devtools [1] also deserves honorable mention. Not only does this improve console output, but it improves inspection while doing interactive debugging (e.g., pause on exception) in Chrome. [1] https://github.com/binaryage/cljs-devtools https://github.com/binaryage/cljs-devtools

dr_win 11y ago
Thanks for the plug. I'm glad you find it useful. I've been working on Dirac - a Chrome DevTools fork for ClojureScript developers. That will be a complementary tool to cljs-devtools: https://github.com/binaryage/dirac https://github.com/binaryage/dirac

cnp 11y ago

Parinfer is the craziest lisp exponent ever. I highly recommend any curious and / or skeptical dev to download Atom, install it, and give it a shot. This book also helps: http://funcool.github.io/clojurescript-unraveled http://funcool.github.io/clojurescript-unraveled From straight up confusion to basic productivity in just a week, it has also completely removed the learning fear. Highest regards to this beautiful tool that will hopefully bring lisp to the masses.

chrisoakman 11y ago
Thank you for the kind comment :) I'm glad you like atom-parinfer!

modarts 11y ago

Clojurescript has made me excited about frontend again.

neoncontrails 11y ago

Diving into clj/s 4 months ago was such a wonderful, arbitrary decision. The #clojure community on Freenode is friendly and wildly clever. They are delighted to answer your Clojure questions. The language itself is great. It's a terrific language for a CS Sophomore to pick up after learning Scheme and Java. My one complaint with cljs has been the difficulty of configuring Ring HTTP beyond the trivial SPA defaults: getting it to respond to other URL requests, other types of HTTP requests. I spent close to 3 hours trying to configure it to accept a POST action before finally giving up, frustrated by the opaque stack traces that went >1000 frames deep. 20 minutes later, I had an Apache server up and running. So it wasn't really a big deal, but I can't remember the last time I felt so baffled by a problem that I simply had to throw in the towel.

sotojuan 11y ago
Same here! Except college senior. You are lucky to have found Clojure so young :-)
dropit_sphere 11y ago
If no one has suggested it before: have you tried Compojure? I know very little about http but it was a snap for me. There's even a lein template.
yogthos 11y ago
I put together the Luminus micro-framework http://www.luminusweb.net/ http://www.luminusweb.net/ to help with this kind of stuff. The docs provide lots of examples on how to get stuff done. For example, here's the section on doing Ajax with ClojureSCript http://www.luminusweb.net/docs/clojurescript.md#ajax http://www.luminusweb.net/docs/clojurescript.md#ajax
- neoncontrails 11y ago
  Thanks for putting this together. This looks like a fantastic tool, and really well-documented. I noticed from a quick perusal of the docs that Luminus still requires a handler function to map URLs to a named page asset (about-page, home-page, etc.) using defroutes -- requiring too, of course, definitions for each of those pages. Could you explain in a few words why that is? Is it a Node requirement? Isn't that a lot of complexity to have to deal with? If so, how do people manage it? I'm just curious because my only exposure to the HTTP layer so far has been via Apache. Apache is... for lack of a better word, a bro. It's up for just about anything. It seems like the default mode of Apache is to do whatever the HTML recommends. Apache is happy to serve an arbitrary "/about.html" URL, provided it exists, and asynchronously execute any server-side scripts to which it injects a dependency. I don't know if this strictly requires the use of jQuery, but it certainly seems easier to do it that way. Is it even possible to serve a cljs app this way? In light of the fact that jQuery is not compatible with the Google Closure compiler?

idibidiart 11y ago

ClojureScript will enrich your mind but at some point you might get tempted, as I have, to switch to ES6/7 via the Babel route and enjoy the benefits of a much more diverse ecosystem, with your ClojureScript-enhanced perspective. Same with Elm and Haskell and prefty much any language wortg learning. In fact, learning a new language esp one drom a different world will always expand your horizon and I can't over recommend ClojureScript as one of those enlightenment languages.

yogthos 11y ago
I switched to using ClojureScript in prod last year and couldn't be happier. The Js interop is great, ClojureScript is fast, and the runtime is pretty small. I simply can imagine any reason to bother with ES6/7 at this point as they will offer nothing that's not already available in ClojureScript right now. You also get a clean and well designed language as opposed to a mountain of kludges that is current state of Js https://twitter.com/capotej/status/677926991513780225 https://twitter.com/capotej/status/677926991513780225

draw_down 11y ago

They do seem to be doing really nice things. And from time to time I try to keep up, watching videos on new tools and things. But I guess I always get hung up on the idea that you should just write in the language that you're targeting, and I wonder about the cost of the (admittedly pretty nice) developer experience of cljs. When you have a bug in production you're stuck debugging the generated JS. This was also my problem with CoffeeScript.

yogthos 11y ago
I've been using ClojureScript in production for about a year now. The runtime is very fast, and in some cases it actually outperforms native Js. For example, both Om and Reagent are actually faster than React.js itself (http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s). Debugging story is very good. You pretty much never have to see the generated JavaScript. ClojureScript uses source maps, so any errors in the compiled Js will map back to the original ClojureScript source that caused them. Chrome dev tools even do syntax highlighting for ClojureScript now. Having a live dev environment with Figwheel and a REPL goes a long way here as well. You can inspect a lot of things at runtime very easily. Using immutable data structures by default avoids a lot of the debugging pain as well. You practically never have to trace through a bunch of function calls to find the problem. In most cases the problem is exactly on the line where the error occurred.
- draw_down 11y ago
  What if your thing crashes in IE?
  - yogthos 11y ago
    IE 11 supports source maps, so that's helpful. The other nice thing is that you rarely end up dealing with browser specific quirks since all popular ClojureScript libraries piggie back on React.js and the Google Closure library. These do a great job of handling the platform specific quirks for you. The first app I developed with Reagent actually had to run on IE8, and to my shock and surprised worked without any issues after I added the standard IE shims. So, overall my experience is that you're better off dealing with IE than with most Js frameworks.

jhund 11y ago

I'm exploring ClojureScript via the re-frame SPA pattern and it got me really excited about UI development again. What's the best way to sync data with a REST server backend?

yogthos 11y ago
I recommend the cljs-ajax library https://github.com/JulianBirch/cljs-ajax https://github.com/JulianBirch/cljs-ajax
_halgari 11y ago
I recommend the following: 1) read up on how Om.Next handles remote calls. Not that it's the only way to do it, but it de-couples the async functionality of a remote call from the rendering loop. 2) Just code against something like Google Closure's XHR libraries, making a HTTP call isn't complicated, just wrap basic functions to suit your needs. But over all, no matter what you use, core.async, or callbacks or whatever, limit the async bits to the edges of your code. Done correctly (Om.Next is a great example) you shouldn't need a whole lot of async bits to get a nice clean app. If you have core.async "go" blocks littered all through your codebase, you're doing something wrong.