Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is definitely some impressive performance. In Firefox 24 the core.async example is significantly faster than When.js on average (though in repeated trials, the running times vary over wide (and overlapping) ranges).

Some commenters seem to assume David's point is "use core.async because it's faster than promises". I don't think so. My takeaway from this post is that, having been persuaded core.async is awesome and will give me joy as a programmer (and see David's other posts for evidence of that, e.g. [1]), performance concerns should not prevent me from going for it, because it's competitive.

For me personally, Clojure and ClojureScript still have a long way to go to catch up with JavaScript-based development using Node.js and say, Angular. A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective. I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server. Here, Node frameworks like Derby[3], which emphasizes sharing nearly all your code, and Airbnb's Rendr[4], seem light-years ahead.

But when you consider that this is an early release of a language and async lib written by a surprisingly small team, with basically no corporate backing, it's a pretty amazing accomplishment. I love ClojureScript in theory and I'm eager for the day when I can love it in practice too.

[1] http://swannodette.github.io/2013/07/31/extracting-processes...

[2] https://github.com/lynaghk/cljx

[3] http://derbyjs.com/

[4] https://github.com/airbnb/rendr



I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server.

I think this is definitely a "the glass is half-empty" interpretation. I mean, let's point out that you're complaining about an environment where you can share code between a codebase running on the server and one on the client--and it isn't JavaScript. And it's not ideal? Of course it's not ideal. But you can do inter-op with Java (server-side) and JavaScript (client-), using the same syntax, and with cljx, you can do this in the same file. This is freaking awesome, even with the messy bits that come along with it, in my opinion.

A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective.

As far as this point, there's less I can disagree with: the community, while small, is awesome, but there is a way to go before ClojureScript, at least, is going to have the ease of "install and get going" that you have with other platforms. Everything from testing to getting a reasonable console up and running is in a state of flux and cannot be favorably compared to JavaScript, other than the argument that ClojureScript provides a better enough programming experience to outweigh the ease-of-setup that JS provides. For me that's more than enough, but for others I can understand that it's not, yet.

But it absolutely is improving, very quickly. We really need more people to be using CLJS and hyping it (as David Nolen is doing) and putting in the time to shave the yaks that need shaving--as people like David Nolen, Kevin Lynagh (http://keminglabs.com/blog/cljs-app-designs/ as well as the aforementioned cljx), Chas Emerick (many contributions, but recently https://github.com/cemerick/austin), Mimmo Cosenza (the fantastic Modern CLJS series: https://github.com/magomimmo/modern-cljs) and many others are doing--so that we can get to that point where the advantages clearly outweigh the disadvantages. I think that time will come, but it's going to require some serious work.

But even now there are compelling reasons to use ClojureScript, including libs like core.async. I think you'd find that, with a bit of patience, there is a lot there to keep you invested in the tools and the community.

EDIT: I just want to add that cljx is not the only or oldest or simplest way to share code. Crossovers using lein-cljsbuild have provided this for a while: https://github.com/emezeske/lein-cljsbuild/blob/master/doc/C...


Thanks; great response. I had forgotten about crossovers.

I did a little project in CLJS and found the additional power of the language nice, but not revolutionary. I've found getting into Node.js that despite the well-known warts of JavaScript, the community has done an amazing job working around those problems, building powerful abstractions, and shipping simple, un-complected code. I hardly feel like I'm compromising on expressivity.

So for me, language like "callback hell" and "wasteful" rings a bit hollow, as it doesn't reflect my experience writing JavaScript. In fact, if I were a contributor to When.js I could imagine it being pretty insulting.

Maybe we can win more people to ClojureScript by recognizing, not diminishing, the great stuff folks have made with vanilla JS, and showing how CLJS provides interop while making JavaScript programming even better. Kevin Lynagh's post here[1] is a nice example of that.

[1] http://keminglabs.com/blog/angular-cljs-weather-app/

As for my "glass is half-empty" interpretation of code-sharing, I'm thinking of how you can trivially require jQuery from a Node.js application and use it for scraping[2]. Or how you can require('http') in the browser and effortlessly make HTTP requests in browser or server with the same code[3]. I'd love to be proven wrong, but ClojureScript seems far away from this kind of stuff. You can't use Compojure or HTTP-Kit in ClojureScript. So you could say that while Clojure has a decent client/server code-sharing story, there's this other thing, JavaScript, that has an amazing one.

[2] http://blog.nodejitsu.com/jsdom-jquery-in-5-lines-on-nodejs

[3] https://github.com/substack/http-browserify




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: