I'm working on a ClojureScript introduction aimed at JavaScript programmers with no prior exposure to Clojure. For anyone here who has come from a JavaScript background, what were the most challenging issues that you faced getting started?

Setting up my environment

And interop/externals

I didn't go from straight up JS ecosystem (I used Rails before) to Cljs, but I think setting up projects for Cljs development used to be a major pain point for me - setting up lein+cljsbuild+whatnot and making sure it works was an absolute nightmare. I imagine lein templates and especially boot (I can't love it enough) helped a lot here, but I think it's a major thing that you want to make sure is as smooth for newcomers as possible so they don't get turned off.

@deddu and @jaen - thanks for the input! Environment setup was definitely a big pain for me as well. It sounds like that is still the biggest issue.

but the worst part was to figure out 'rlwrap lein figwheel '

I'm not so sure how it is now with lein, but boot really made it fairly straightforward. Though compared to Rails there's still things like deciding on the project structure or the choice of libraries (it can still be a bit paralysing after doing Clojure for a better part of year) which there you got figured out for you. So I think some project template for your newcomers can go a long way in making them more comfortable starting out with Cljs.

As for rlwrap lein figwheel - with boot + boot-cljs-repl + Cursive I've got Cljs repl history withotu such problems, though I imagine switching toolset could be a pain for you.

I haven't had a chance to do much with boot. Do you feel like it's friendlier than lein for people coming from a non-Clojure, non0JVM background?

I feel it would be

Yeah, I'm happy to suggest the toolchain that would be easiest for a beginner rather than weigh the pros and cons of all the options

I'm not that well versed in non-Rails JS ecosystem

But from what I understand of what Grunt is, then boot is quite similar

It also has quite nice and simple setup for Cljs development

That gets you live reload and such niceties with little setup hassle

Feel free to take a look at sample projects with boot - https://github.com/martinklepsch/tenzing and https://github.com/Deraen/saapas

@jaen: No! Lein = Grunt, Boot = more like Gulp. Lein and Grunt have declarative configuration while Boot and Gulp are code.

Awesome - thanks for the links!

@juhoteperi: thanks for the correction, I've only read a bit on those in my life, since Rails' asset pipeline was quite enough for me, so I might have mixed those up.

Also, Broccoli js might be closer to Boot than Gulp, it has asset pipeline which is similar to Boot filesets. In Gulp one has to manually manage all the paths.

Oh, I didn't even hear about that one before

webpack is the best one for me so far.

hot code reload with react, not nearly at the level of stability as figwheel though

the way it handles assets is also one of the most sane

@bbss: are there any examples/tutorials you can point me to for webpack?

The docs are pretty good, include links to tuts: http://webpack.github.io/docs

thanks. did you hook in the clojurescipt compiler with some sort of plugin?

Oh no, not using it with cljs sorry didn't notice you were looking for that, this I am using with ES6 and babel

Okay - good clarification

@asmeredith: I did a lightening talk at our local JS meetup about cljs. Here is the material I presented, if it helps you in anyway. http://monjohn.github.io/clojurescript-for-javascripters/

That looks great. I'll have to give it a thorough read.

Has anybody configured a repl script and figwheel from lein?

can i ^:export a goog-define so that it is not munged in :advanced?

^-- still not sure if that should work but defining a (def ^:export pointer-to-define goog-defined-var) works and is easy enough

@bensu yes I have, using mies scripts and lein-simpleton, but there was a bug in there that I PR-ed

I was able to laugh independently a figwheel and a vanilla cljs repl

If I understood hour question correctly

@richiardiandrea: thanks! I did manage to do it after a while

What did you use to serve files?

the thing that tripped me is that figwheel serves from resources/public and the repl serves from wherever you call it

so I had to use

Yes that is why I used lein-simpleton to decide where my root is

thanks, will look at it

shameless plug if you want it with bug fix 😄 -> https://github.com/arichiardi/lein-simpleton/tree/from-fix

yeah, don't know. I don't see the benefits beyond python SimpleHTTPServer which I already use all the time!

:)

why do you need a webserver at all when using static files?

don't always need it but in some configs the assets point to paths with a root

as in /imgs/your-face.img

instead of imgs/your-face.img

ah yeah makes sense

I hope so, it's your face after all 😄

looool

I’m having trouble building my project on cljs 1.7.170 & cljsbuild 1.1.1, worked previously on cljs 1.7.48, cljsbuild 1.0.6. Appears to have to do with a :foreign-lib.

compiling "resources/public/js/app.js" failed.
java.lang.IllegalArgumentException: Could not find namespace org.uaparser

org.uaparser is a foreign lib

@arohner first report of a problem like that

no known gotchas

@asmeredith: I have a strong JS background and recently started to study CLJS with a strong desire to put it in production (meaning that I'm not only evaluating the language but the whole environment and its surrounding culture from development to deployment) and I noticed a couple of things:

1. almost every CLJS blog/paper/podcast talks about CLJS as a replacement for front-end but JS has become very popular on backend with NodeJS and I believe that CLJS is great candidate for it (I'm myself focusing on CLJS running AWS Lambda).

2. CLJ/CLJS development are strongly based on a repl workflow which really works well mostly with "old-school" text editors like VIM, Emacs, etc which is unfamiliar to the majority of programmers and as such require them to learn a new environment before learning the language itself.

@ericchaves: I don’t find 2) to be accurate. You also have now integration with many popular IDEs and SublimeText as well.

as far as 1) it will likely be a smaller population of overall ClojureScript users for the forseeable future simply because most users are in fact using Clojure

Yeah, Cursive is possibly the best Clojure coding environment right now and it's an IDE not an "old-school" text editor.

and there are a variety of factors that make seamless integration with wider Node.js ecosystem problematic. These are unlikely to be addressed as the pay off for the development effort is too small given the other factors.

@dnolen: I tried Lightable and Sublime and I faced a lot of issues. With sublime repl kept disconnecting and I could not reconnect it. LT was better, but in my opinion lacked a lot of other IDE features that really boost my productivity.

@ericchaves: if you’re looking for a stable IDE experience then Cursive is probably your best bet

I use it exclusively for work at Cognitect

@bhauman the feature to focus on one card … pretty awesome!

@jaen: havent tried cursive yet but read good things about it. I settled with emacs (I belong to old school, 41 now) 😉 but my point is that fore those coming from other languages those things are speed bumpers.

I thought IDEs were an annoyance and distraction and all that (coded in Sublime exclusively before) and then I tried Cursive. Now I can't imagine living without it.

@ericchaves: quality of text editor integration is really a problem for the community to sort out.

@dnolen: I may give it a shot anytime. Anyway I'm not here advocating in favor or against any editor. I'm sure as CLJ/CLJS evolves a lot of IDE will come to light. Just like what happened with rails, where in the early days most people worked with textmate and now there are tons of choices.

Emacs & VIM are pretty solid because of how many users use and contribute to it

but nothing is stopping other options from being as capable and stable

nor is anyone recommending that you have learn Emacs or VIM to get things done

didn’t cljs recently get support for requireJS / AMD? I thought I remembered seeing a tweet or two. Are there any docs on it?

@arohner: I don’t think there are much in the way of docs

it works but I would consider it an edge feature

@arohner: for more info see @maria’s GSoC blog posts - probably the most accurate source of information

@dnolen: thanks

http://mneise.github.io

@arohner: ^

@dnolen: regarding point 1 I totally agree with you but I would love to see CLJS to grow among nodejs dev. I'm yet learning my away (I'm not yet good CLJ programmer. just started my first steps) but I see great potential. In my point of view it make a lot of sense. Most Nodejs programmers I know (myself included) already write a lot of "functional-ish" code. New ECMA6 are bringing new features towards it but I'm afraid that this bipolarity may drive the language to a crazy place. Also, there some things that I love with compiled languages that are being left on the world of dynamic languages, like code optimizations.

@ericchaves: the issue is one entirely of time / effort vs. payoff not whether the idea is a good or bad one

@dnolen: I agree.

Node.js enhancements to ClojureScript have driven largely by the users that want it / need it - this will continue to be the case. This is an easy area to move forward.

However making ClojureScript more palatable to JS devs is a gargantuan effort

it took us 4 years to get to where we are on the JVM

I guarantee it will take at least that long to have a compelling Node.js narrative

@dnolen: Oh, but thats not what mean.

@dnolen: I really having a great time learnign CLJS.

@dnolen: I dont expect that CLJS+Node to be toe-to-toe with CLJ+JVM. I think CLJS will have its own place and I strongly believe that it adds a lot to systems targeting nodejs.

@ericchaves: sure, but regardless someone who cares has to work on it

as one of the projects leads I can say we aren’t against such enhancements but also not interested in working on something I don’t actually need myself.

so the effort will have to come from eslewhere

@dnolen: forgive me again, but I'm feeling my point was mistaken, I was not trying to say that nodejs was lacking "presence" or "priorizations" on cljs development. On contrary, I'm very thank full for your efforts so far and I do believe you guys have done great.

@ericchaves: sorry for misunderstanding. We are aware that Node.js is a valuable target, but we really don’t think of it as anything more than that. i.e. the Node.js community at large doesn’t really factor into many of our considerations.

@dnolen: I suspect my earlier bug about ua-parser is an incompatibility w/ newer closure. ua-parse.js appears to have some barely legal JS that closure doesn’t like.

I previously had errors with ua-parse in rhino

@dnolen: just for curiosity, in what kind of system do you use cljs? where do you expect to see cljs being used?

@arohner: k good to know, thanks for the follow up

@ericchaves: ClojureScript was originally created to complete the stack story for Clojure. It can go all the places Clojure can’t - web, mobile etc.

Hi! I suspect this comes up a lot, but I'm rather confused by UMD support 😞

I have JavaScript module called bitauth that I can make a UMD module from Node.js sources (well, it's not mine, it belongs to a company called BitPay and I just consume it)

In the past I've wrapped bitauth in ClojureScript ; recently they've made some changes upstream and I'm puzzling how to integrate their new UMD module downstream.

Do I just make an extern.js file and go through CLJSJS? Or is the community going to migrate away from that?

(this is what I've done in the past)

I had the impression from the recently added UMD support that making an extern file wasn't necessary anymore...

I'd like to use CLJS for a project that needs to communicate using WAMP Protocol (currently using http://autobahn.ws/js in the client app I'm replacing). Curious if anyone suggests a lib/technique for WAMP in CLJS.

@xcthulhu: I am not aware of any plans to move away from CLJSJS.

@xcthulhu: And you still need externs even if you include your lib with the JS module compiler options.

@xcthulhu: Including your lib with the JS module compiler options means that your lib is included in any optimization steps, e.g. dead-code elimination, if it’s Google Closure compatible.

No idea if it is Google Closure compatible. The UMD I'm wrapping is generated by browserify 0.11.1, and browserify is super complicated and constantly changing.

But thank you very much maria! This answers my confusion 😄