Hacker News new | ask | show | jobs
by pandeiro 1900 days ago
My impression is that CLJS, while an amazing way to write frontends with react, suffered from an incomplete/fractured tooling ecosystem, with the official maintainers leaning on the community to develop the 'batteries' and several good but incomplete and unofficial solutions being offered (lein-cljsbuild, figwheel, boot, etc).

I'm not actively involved with CLJS development anymore but last I checked that still continued, with tools like figwheel/deps.edn/shadow-cljs all sort of doing similar things differently, and there being good-but-not-as-good-as-clojure support in different editors like emacs, intellij and vscode. Similarly, there were a number of different, but still alpha quality ways, to use cljs with react native, all suffering from some major pain points.

2 comments

I shared a similar opinion a while ago, but lately (last two years perhaps?) the general consensus is pretty much shadow-cljs which has stellar support for node modules. shadow-expo also integrates with RN effortlessly.

Cursive is really good at handling cljs too, with jump-to-definition and refactoring without using a REPL

Do you know if shadow-cljs support source maps for React Native? (Their absence was a really significant pain point when I worked on a production CLJS/RN app.)
You need two source maps: one produced by ClojureScript and one produced by RN Metro. When you get an error with a stack trace from RN, you need to walk the source maps in the correct order to find where the error in the CLJS code originated. I wrote some custom code to do this but I haven’t polished it/made it into a lib at this point.
Sure, I understand. But that's several orders of magnitude less useful than what one gets in eg the chrome devtools console from a CLJS webapp.

I found this to be a major timesink when debugging things, and never came up with a good bulletproof solution to automate this traversal. It was especially painful with random breakages due to NPM's automatic dependency/transitive dependency upgrades due to version ranges (ie, things that don't just fix themselves by checking out a previous known good version).

All of the most popular Clojure DE's, namely VSCode/Calva, Idea/Cursive and Emacs/CIDER has great support for clojurescript for now.
Can you set a breakpoint in CLJS code within your editor? Can you instrument a CLJS function, call it and do step-by-step debugging like in CIDER or Cursive for clojure?