3 ms·

(take 5 kevin-lynagh)

65 points by llambda 15y ago

puredanger 15y ago
Kevin will be talking about using ClojureScript and d3 to create graphics on the web at Clojure/West (Mar 16-17, San Jose, CA) - http://clojurewest.org/sessions#lynagh http://clojurewest.org/sessions#lynagh
- lynaghk 15y ago
  For anyone who's tempted to dive into my ClojureScript d3 wrapper (https://github.com/lynaghk/cljs-d3 https://github.com/lynaghk/cljs-d3), hold up---there just might be Clojure/ClojureScript-native data visualization library open sourced at Clojure/West...
lynaghk 15y ago
This interview is from November 2011; ClojureScript tooling has improved since then. Evan Mezeske's lein cljsbuild plugin (https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild) is a great place to start.
pfraze 15y ago
Clojure compiles to JVM bytecode; what's stopping browser-builders from creating a similar bytecode format (or even JVM) so developers can build in their language of choice? Time/effort?
- bokchoi 15y ago
  I've wondered this as well. Volta compiled MSIL to JS which made it language independent. The project seems to have stopped however.
  - bokchoi 15y ago
    Ignore that, I misread your comment.
- zephjc 15y ago
  I found this article [1] that makes the argument that JS doesn't need a bytecode format, and sorta-but-not-really comes to the conclusion that a compact AST format would be a better choice as an intermediate, and mentions JSZap [2] (which itself seems to be more about compression than being used as an IL). I think an AST format that v8 and other JS engines could read could be awesome. Ultimately, I'd like to have a Clojure that can compiled to this AST. On servers, the ast files could be cached a la Python .pyc files. [1] http://www.2ality.com/2012/01/bytecode-myth.html http://www.2ality.com/2012/01/bytecode-myth.html [2] http://www.slideserve.com/elina/jszap-compressing-javascript-code http://www.slideserve.com/elina/jszap-compressing-javascript...
  - deleted 15y ago
    [deleted]
pigs 15y ago
I've been using Clojurescript with a Noir backend to build an internal tool for work, and I thought I'd share my experience so far. Some background: I'm a Java guy by trade, this is my first FP language, and I'm not that well-versed in Javascript. In general, I've found the whole experience to be rather fun. A bit of a learning curve for sure, but once I ramped up I felt really productive. I don't feel like I get stuck as much as other times when I've tackled a new framework/language. And the nature of the language lends itself to just start writing functions rather than get caught up trying to abstract everything. I feel like my code flows better, is easier to refactor, debug, etc. Clojurescript may still be considered new/beta/cutting-edge, but I never found it to be buggy or frustrating to use. A few minor things I got hung up on: goog.dom.query - This isn't included by default, I'm guessing because it's a third-party wrapper around dojo.query. I had to follow a few threads on Google Groups to figure out how to include it. Another option is to use Chris Granger's jayq. But there's no way to do CSS-type selector queries by default (that I know of). Converting between Javascript objects and Clojure data structures - I had to scratch my head a bit the first few times I ran into this, but there are lots of code snippets on Stack Overflow and various other places around the web. I was able to quickly develop a few reusable idioms to handle this. Lazy sequences and side-effects - people with more experience in FP might not have gotten stuck on this, but this was another head scratcher for me. Basically any type of DOM manipulation is a side-effect, so if you're app relies on that, you'll need to occasionally force evaluation of a lazy seq. The browser-connected REPL takes a few manual steps, but it's well documented, and extremely useful. It's just not as easy as running "lein repl". The default compiler is not integrated with lein either, and is not automated, but lein cljsbuild is available as Kevin mentions. I ended up using Chris Granger's cljs-watch. In any case, if you can't find it through Google, it takes all of about 15 secs to get your question answered on #clojure IRC. My current setup includes VimClojure and a browser-connected REPL in my terminal. I'm using Noir on the backend, and the included Google Closure libraries on the front-end. I tried to minimize the number of additional dependencies (perhaps irrationally), so I opted out of using the remotes from fetch (formerly pinot), and just used goog.net.XhrIo calls to the noir backend to acheive a similar effect. I did find the crate library to be perfect for dynamically creating DOM objects. You can write something like [:form [<form body...>]] instead of "<form> <form body...></form>", and it's nicely highlighted with Clojure syntax. For debugging, I just use Chrome's debugger. It's compiled JS, but it's easy to figure out where you're at. All of your functions are at the bottom of the script. You're not going to have a lot of state to track in the actual Javascript either, so most bugs are easily sniffed out, at least in my somewhat simple app. Sorry for the long post.

65 points by llambda 15y ago

Kevin will be talking about using ClojureScript and d3 to create graphics on the web at Clojure/West (Mar 16-17, San Jose, CA) - http://clojurewest.org/sessions#lynagh http://clojurewest.org/sessions#lynagh

lynaghk 15y ago
For anyone who's tempted to dive into my ClojureScript d3 wrapper (https://github.com/lynaghk/cljs-d3 https://github.com/lynaghk/cljs-d3), hold up---there just might be Clojure/ClojureScript-native data visualization library open sourced at Clojure/West...

lynaghk 15y ago

This interview is from November 2011; ClojureScript tooling has improved since then. Evan Mezeske's lein cljsbuild plugin (https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild) is a great place to start.

pfraze 15y ago

Clojure compiles to JVM bytecode; what's stopping browser-builders from creating a similar bytecode format (or even JVM) so developers can build in their language of choice? Time/effort?

bokchoi 15y ago
I've wondered this as well. Volta compiled MSIL to JS which made it language independent. The project seems to have stopped however.
- bokchoi 15y ago
  Ignore that, I misread your comment.
zephjc 15y ago
I found this article [1] that makes the argument that JS doesn't need a bytecode format, and sorta-but-not-really comes to the conclusion that a compact AST format would be a better choice as an intermediate, and mentions JSZap [2] (which itself seems to be more about compression than being used as an IL). I think an AST format that v8 and other JS engines could read could be awesome. Ultimately, I'd like to have a Clojure that can compiled to this AST. On servers, the ast files could be cached a la Python .pyc files. [1] http://www.2ality.com/2012/01/bytecode-myth.html http://www.2ality.com/2012/01/bytecode-myth.html [2] http://www.slideserve.com/elina/jszap-compressing-javascript-code http://www.slideserve.com/elina/jszap-compressing-javascript...
- deleted 15y ago
  [deleted]

pigs 15y ago

I've been using Clojurescript with a Noir backend to build an internal tool for work, and I thought I'd share my experience so far. Some background: I'm a Java guy by trade, this is my first FP language, and I'm not that well-versed in Javascript. In general, I've found the whole experience to be rather fun. A bit of a learning curve for sure, but once I ramped up I felt really productive. I don't feel like I get stuck as much as other times when I've tackled a new framework/language. And the nature of the language lends itself to just start writing functions rather than get caught up trying to abstract everything. I feel like my code flows better, is easier to refactor, debug, etc. Clojurescript may still be considered new/beta/cutting-edge, but I never found it to be buggy or frustrating to use. A few minor things I got hung up on: goog.dom.query - This isn't included by default, I'm guessing because it's a third-party wrapper around dojo.query. I had to follow a few threads on Google Groups to figure out how to include it. Another option is to use Chris Granger's jayq. But there's no way to do CSS-type selector queries by default (that I know of). Converting between Javascript objects and Clojure data structures - I had to scratch my head a bit the first few times I ran into this, but there are lots of code snippets on Stack Overflow and various other places around the web. I was able to quickly develop a few reusable idioms to handle this. Lazy sequences and side-effects - people with more experience in FP might not have gotten stuck on this, but this was another head scratcher for me. Basically any type of DOM manipulation is a side-effect, so if you're app relies on that, you'll need to occasionally force evaluation of a lazy seq. The browser-connected REPL takes a few manual steps, but it's well documented, and extremely useful. It's just not as easy as running "lein repl". The default compiler is not integrated with lein either, and is not automated, but lein cljsbuild is available as Kevin mentions. I ended up using Chris Granger's cljs-watch. In any case, if you can't find it through Google, it takes all of about 15 secs to get your question answered on #clojure IRC. My current setup includes VimClojure and a browser-connected REPL in my terminal. I'm using Noir on the backend, and the included Google Closure libraries on the front-end. I tried to minimize the number of additional dependencies (perhaps irrationally), so I opted out of using the remotes from fetch (formerly pinot), and just used goog.net.XhrIo calls to the noir backend to acheive a similar effect. I did find the crate library to be perfect for dynamically creating DOM objects. You can write something like [:form [<form body...>]] instead of "<form> <form body...></form>", and it's nicely highlighted with Clojure syntax. For debugging, I just use Chrome's debugger. It's compiled JS, but it's easy to figure out where you're at. All of your functions are at the bottom of the script. You're not going to have a lot of state to track in the actual Javascript either, so most bugs are easily sniffed out, at least in my somewhat simple app. Sorry for the long post.