When I first considered taking ClojureScript for a spin, there were several things that gave me pause: “What’s the debugging experience like?” “How often am I going to find a problem in my app, only to discover that it’s actually a bug in ClojureScript?” And so on.
I was new to ClojureScript (and fairly new to Clojure at the time as well), so I didn’t take these things lightly. Once I got started, I was pleasantly surprised with the results. The actual experience wasn’t just better than I expected; the actual experience was pretty darn good.
If you’re on the fence about giving ClojureScript a shot, I hereby present: 4 things that might worry you, but shouldn’t.
The following screenshots illustrate this workflow.
ClojureScript is barely a year old.  I’ll bet the dev team is still rapidly evolving the API. I don’t want to have to fix my app every time I upgrade to each and every point release of ClojureScript.
ClojureScript benefits from the stability of Clojure’s API. I’ve upgraded the same app to new releases of ClojureScript several times. Only once did an upgrade require changes to my application code, and even then, those changes were minor syntax tweaks.
Did I mention how young ClojureScript is? I’m okay with “leading edge,” but am I prepared for the bleeding that goes with “bleeding edge?” Do I really want to be the guinea pig for some bug-ridden alpha software?
ClojureScript is quality software with a responsive dev team. In eight months of working with ClojureScript, and through several ClojureScript upgrades, I’ve only been impacted by a single bug. I reported that issue on the mailing list at 7:30pm on a Monday night. Figuring that I wouldn’t hear anything until the morning, I decided to go grab some dinner, and then work on something else.
Enter David Nolen. Fortunately for me, David hates dinner, and he hates software bugs even more. So for him, 7:30pm seems like a perfectly reasonable time to be churning through JIRA tickets. Clearly my expectations were too low; David wasn’t going to let me wait 16 hours for a reply. Instead, he fixed the issue, committed it, and replied—in just 42 minutes.
I’ve paid good money for support nowhere near as responsive as this!
Performance profiling and tuning
What the heck am I going to do when I discover that part of my app is too slow? I’m pretty sure there are zero ClojureScript performance profiling tools out there.
While you’re unlikely to find a ClojureScript-specific perf tool, the Google Chrome profiling tools give you what you need. 
Eventually, part of my ClojureScript app became slow—unusably slow. The Chrome profiling tools helped me track down the bottleneck.  The screenshot below describes the process.
Runtime tooling in general?
What, me worry?
I approached ClojureScript expecting each of these things to be a source of pain. Thankfully, I was wrong. If any of them have caused you to think twice about giving ClojureScript a try, I contend that they shouldn’t.
 “Transpiles” if you’re nasty.
 I suspect that one day—perhaps very soon—we’ll have source maps for ClojureScript. When that day comes, we’ll look back on the current workflow as “The Olden Days of ClojureScript Debugging.” You know: when we used to walk 7 miles in the snow, uphill both ways, in order to track down the source of an error. But in all seriousness, while I look forward to having source maps for ClojureScript, the debugging experience is sufficient without them.
 Actually, my initial worry dates back to early 2012, when ClojureScript was even newer. Do I really want to dive head first into a six-month-old language?
 Safari, Firefox (via Firebug), and Internet Explorer offer similar functionality.
 It turns out that you probably don’t want to construct a 30 kB string (30 kB!) for every single event that fires inside your app.