Clojurians Log v2
announcements 2026-10-15
https://github.com/nextjournal/markdown: A cross-platform Clojure/Script parser for Markdown
0.7.228
• Point at the README from the default :html-block and :html-inline renderers instead of reporting an unknown node type https://github.com/nextjournal/markdown/issues/69
• Render the link title in the default :link renderer https://github.com/nextjournal/markdown/issues/71
I would like introduce https://github.com/WhimsicalCode/clojurific, a ClojureScript compiler fork, optimized for interoperability with modern JavaScript tooling, runtime performance and build speed:
• Compiles ClojureScript to ES modules
• Is should be compatible with existing ClojureScript libraries
• Runs as a Vite plugin, no need for shadow-cljs
• Browser and backend support
• Integrated REPL in dev for both browser and backend
• Doesn’t need extern definitions
• 2x faster build times and hot reload
• About 40% less time on runtime benchmarks
• Bundle sizes comparable to the classic compiler with advanced optimizations
The rationale for Clojurific is to optimize ClojureScript based on our own product needs, while choosing different tradeoffs compared to ClojureScript classic (more about this in https://github.com/WhimsicalCode/clojurific#why-clojurific).
What we lose in hardware prices we gain in software speed increases.
@k7d Do you feel like this is ready to go to prod for smaller projects? Or is it at an alpha stage where things break randomly?
The one data point i can give is that http://whimsical.com has been running on clojurific for couple weeks now in prod, without issues. It also does pass the extensive test suite we have accumulated for the app over the years.
So I think it’s reasonably safe. One thing I don’t know is whether it breaks some 3rd party ClojureScript library (that we don’t use internally).
But in that case you would more likely get build errors than hidden runtime regressions.
> Compatible with existing ClojureScript libraries > One thing I don’t know is whether it breaks some 3rd party ClojureScript library 👀
@borkdude i guess “should be compatible” could be a better framing
It avoids google closure right? but it still works when you use goog.whatever libs I guess? are those libs also ESM-friendly?
yes it includes ESM versions of goog.*
what I mean is, goog.* isn't written in a DCE-friendly ESM-compatible way right - so using one function probably uses all, if you use rollup/rolldown/esbuild
got it, you just rewrote goog ;)
"you"
yes, all credit for this goes to opus 5.5
so I think that’s where 3rd party libs could break, it doesn’t yet implement the whole closure library, although that shouldn’t be too big of a deal to fix
just add more tokens? ;) have you considered: why use CLJS at all, we're just vibing our whole thing to JS now?
(devil's advocate question)
1. we have 400865K LOC of clojure, it’s much much harder to rewrite it to JS than optimizing compiler
2. I still read most of the code, even when i don’t write it by hand and clojure is much easier to follow/understand
and perhaps a bit more esoteric but from my experience 3. Agents generate better clojure code than JavaScript / TypeScript (I’ve written as much TypeScript both by hand and more recently agent-written) as Clojure over last couple years
I don't disagree with that solution, but just wanted to double check ;)
This is cool, since it's based on Vite one should be able to run things like TanStack with SSR and client hydration?
> This is cool, since it’s based on Vite one should be able to run things like TanStack with SSR and client hydration? haven’t tested it but in theory, yes, can’t think of why not
@k7d thanks a lot for creating Clojurific and using it in production to harden it
I suppose clojurescriptstorm won’t be working since it is also a fork from original. I’ve found it really helpful with agents.