Clojurians Log v2

there is a branch, but nothing finished yet

I love Squint so much!

DHH's article, and his Rails talk, which inspired me some time ago: https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203

We're using shadow-cljs (I guess like most others), and the google closure step is not only extremely time consuming, but the monolithic JS file (~25MB for our app) is getting to be a real burden 🙂

yes, sure. squint just compiles to JS so at that point you can use everything JS supports. no magic there

Would be awesome to have separate JS files in the end, since most of our branches/deploys only end up changing a small amount of our many namespaces.

squint does support that use case. but note that squint isn't fully compatible with all of CLJS :)

just so i don't miss any technical reasons why cljs just can't work this way, due to how everything is compiled or whatever 😄

so it would require rewriting some of your stuff probably

shadow-cljs does support a per-file output with ESM as well. but I'm pretty sure it recompiles your whole app every time you restart it

right, I noted that it's not production-ready. but is this the goal eventually, to be fully compatible and be a drop-in replacement for shadow-cljs?

I'm not sure about a drop-in replacement for shadow-cljs

> shadow-cljs does support a per-file output with ESM as well. but I'm pretty sure it recompiles your whole app every time yeah, but it seems only useful for keeping external JS modules separate, meanwhile cljs still compiles to just one big fugly blog hehe

there is :target :esm-file or something

> I'm not sure about a drop-in replacement for shadow-cljs sure not completely, I get that. but for the most common use cases.

squint does live-code compile/reload like shadow as well, right?

squint itself doesn't but most people use vite for that. squint is just a transpiler from CLJS to JS basically. it does have a file watcher to recompile sources that changed, but "reloading" stuff happens through other tools (so far)

btw maybe I'm just talking about the wrong abstraction level: I probably mean cherry, which is built atop squint, yes? 😂

cherry is more or less the same thing indeed, mostly the data structures change

so cherry is more targeted to being used in production, for larger cljs web apps?

cherry and squint are equally (non-)production ready but squint is more suitable for smaller builds since it doesn't bring in the immutable data structure machinery

do you have an idea of a timeframe for it to be viable? feels like a really exciting prospect to modernize the cljs stack.

I deem it production ready in the sense that most stuff already works, but tooling-wise it could be better. In 2026 I want to focus more on bringing nREPL to the browser for squint and cherry. Another thing currently missing is source maps, those are the two big ones. But if you can do without it, you can already use squint and cherry in production and I'm fixing bugs actively.

cool, sounds like 2026 will bring some important stuff. source maps feels very important for debugging in prod 👍

> In 2026 I want to focus more on bringing nREPL to the browser for squint and cherry I take this as that there is no browser nrepl for squint yet? Please just interpret that as a question. 😃 I just want to know If I am missing something when searching for it.

A project using cherry — and which depends on another project using cherry — happily running off an import map and JSDelivr: https://willcohen.github.io/clj-proj/ https://github.com/willcohen/clj-proj/blob/main/docs/index.html