Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I'm not sure how I feel about this; wasn't part of the point of core.async to push all this stuff into channels? I'm not convinced that having a JS-style async keyword is an upgrade.by tombert
- This is about using a JS feature without bringing in any additional dependencies like core.async. You don't have to use it and you can still use core.async. This was the most asked for feature in the recent ClojureScript survey.by Borkdude
- I remember a decade ago when JavaScript got Async/Await. 10 years is quite a long time.by seanclayton
- Clojurescript already had it, just didnt use native async.
- The beauty of Clojure/Lisp is that we have a nice macro system. Over the years, people created their own macros to simulate async/await. This is a powerful feature of Lisp, you don’t have to wait for an official release, you can just add that feature to the language yourself. Now we don’t have to use that custom macro anymore, which basically did the same thing.by ertucetin
- Epic win for cljs, congratulations!by chr15m
- Seems like wrapping async await functions with CSP was a better way to handle this . Clojure already had a nicer pattern for thisby nbardy
- You're still able to do so, as we've been able to in ClojureScript land for many years already, since ultimately they're just Promises! I don't think that's going away with this new function hints.
https://clojurescript.org/guides/promise-interop#using-promi...
- this release is about exposing the host language primitives to clojurescript
core.async isn't going anywhere, if async/await works better than promise based implementation, core.async will get an update in it's .cljs parts
- This is important for JavaScript interop without having to include additional libraries very cool and was missing for a long time
Congratulations on the release :-)
by slifin - I haven't kept up with cljs in a long time but I remember it originally being pitched as just clojure on js--at least I think that's how Rich originally described it. My impression was it was just supposed to be, as much as possible, another runtime. This change seems to add in features that are exclusive to cljs and actually conflict with clojure itself as await is already a keyword in clojure.core. Have the two impls diverged over time, or was this feature specifically important enough to the users to overcome the differences?by jhhh
- Massive, cheers dude and congrats on the release. I’d say it’s such a good time to get into Clojure/Script but, well … it has been for a while!by boczez
- This is huge. I haven't been this excited about the Clojure ecosystem since Jank got announce (which is pretty recently to be fair)by arikrahman
- I wish an alternative to JS for the front end would catch on and be something more than obscure... I'd love to use something like clojurescript, but I struggle to imagine doing so for anything but a personal side project :/ Maybe this is easier to adopt if you're already a clojure shop for the backend?by timwis
- Ten years ago we were writing ClojureScript for the frontend at work. We weren’t a Clojure shop at all. As my then manager said, picking ClojureScript was part of the hiring bar: people who weren’t interested in functional programming tended not to be good programmers and so we avoided hiring these people.by kccqzy
- https://www.scala-js.org/ is quite phenomenal.by ezst
- After reading
I came to the conclusion that the best frontend is no frontend.
by xmcqdpt2 - > I struggle to imagine doing so for anything but a personal side project
Don't imagine. You have any bash scripts your team uses? Rewrite them in Babashka. Start with your own personal scripts first, get a knack for it, feel the benefits (it's not going to be universally better for every case). You have to be very confident about it personally, because people will come for your guidance later.
This is a good strategy for introducing unfamiliar things - pick something less important, rewrite it, let it sit there. If it becomes problematic - easy to revert. If people start liking it, you can add more, and so on.
That's how I sneaked F# in my .net shop years ago - I started writing less important tests in it.
by iLemming - You should try Gleam. I'm using it in production to great delight:by oDot
- Are you worried because it’s not a mainstream language and coworkers may not know it, or are you worried about the language itself getting abandoned or being bad or such?
I’ve not used it in production, but I’ve shipped a few side projects and stuff for family members in it. ClojureScripts React wrapper, Reagent, honestly makes more sense to me than React does. I used Hiccup to generate HTML, and your components are just functions within Hiccups DSL (which is really just lists) and it ends up looking incredibly clean. Static things look static, dynamic things are obviously so, and it felt much less magic than regular React.
The only things I found that felt bad were trying to use non-functional components I found on NPM. It’s not a deal breaker, but the code was ugly. Nothing I couldn’t fix with a wrapper, but some JS libraries are heinously ugly in cljs by default.
by everforward - Don't be afraid, it's great! I certainly wouldn't call it "obscure", I've been using it for 10 years now to compile a complex app into highly-optimized client-side code. And the community is very welcoming and mature.by jwr
- Surprised to see Clojure/ClojureScript come up on socials more often all of a sudden. I used it professionally for a few years around ~2012 and like many others moved off JVM and moved into typed [functional] languages.
Is the sudden buzz due to agentic coding? Does it rip through code faster with no type checking and fewer invalid syntax errors and reserved keywords to deal with? are we in for a sexp resurgence?
by osener - I recall some documentary came out or was announced? maybe that has to do with it?by mercer
- Been coding in lots of languages with agentic coding and it performs much better with typed languages since it basically corrects the agent if it does any hallucination errors. Especially during major refactorings. I have been dealing with large untyped python code bases and it sucks with AI since if it's not covered with tests it's such a teadious job to make sure it did not break anything. The stronger the type system the better it is. Also AI model is trained on code and the more popular the language is the better the AI will be at it. ClojureScript while nice is not a major language so I would assume AI would perform worse in it compared to javascript.
But in the end. Choose typed languages or dynamic languages with type hints if you are going for the AI route.
by perarneng - I think a lot of the recent interest is being driven by the recent release of the Clojure documentary: https://clojure.org/about/documentaryby ethagnawl
- Another feature that plays well with agentic coding is REPL driven development. I don't know why that approach hasn't caught on in more languages that could theoretically support it.by Zak
- Personally I moved from typed functional languages to Clojurescript and then Clojure around 10 years ago
Most serious Clojure code bases I'm aware of invest heavily in their test suite so yes you can just add a skill to your AI that tells it the most effective way to use your test suite then send it to the races
Some of my colleagues let the agent interact with the REPL and they report faster performance because the agent is not paying the start up cost on every interaction, personally I've been lazy there its fast enough for me
As you've hinted at Clojure does have less bits that get in the way, everything is true except false and nil, the language does not have order precedence table the core language supports immutable and persistent data structures as default
Everything is an expression nothing is a mixture of operators and expressions map, reduce, filter are built in and expected in normal code
Code you wrote 10 years ago in Clojure will likely still work today the ecosystem and language authors treat breaking code as taboo
Of all the languages I've used its the least headache inducing and the most freeing in terms of expressing my ideas
Also the defacto reverse debugger Flowstorm is a programming dream
Its a lovely language if you want to be content
The flip side of that is most users take it for granted and don't talk about it much
There are also a lot of commercial Clojure programmers who do not understand the language and as a result not that happy, they often didn't willing choose it, probably not ready for it, I think most Clojurians should have gone through a decade of noticing things in their other languages they didn't like before using it
Rich Hickey the creator of Clojure does famously influential videos on software but that doesn't mean your colleagues have watched them or care
by slifin - fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself.
edit: i'm in no way trying to diminish the value of this release, just pointing out how cool it is that you can get new language features before they are available in the host language by just adding a library to your dependencies. clojure is awesome!
- True, but there are many reasons to avoid core.async, especially in 2026.
It balloons up the Js artifact, has no inherent error model, and transforms into state machine code that's hard to read/debug if something goes wrong. Plus, the `go` macro encourages overly-large functions, because it can't transform code outside its own sexpr.
As one Cognitect put it, "core.async is beautiful nonsense".
by KingMob - > fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself.
Definitely. I was heavily using it and it worked: a few quirks but we did have async/await since more than a decade. I think I discovered it after watching a talk by David Nolen.
Since then I moved to minimal JavaScript on the front-end: SSE is one-way and that is beautiful. I'm glad to see many devs, from a great many different languages, now getting interested in SSE.
Here's a great, recent, talk by David Nolen called "A ClojureScript Survival Kit":
I cannot thanks David "Swannodette" Nolen enough for all the work he did on ClojureScript (and core.async) since its inception. And what's amazing in this talk is that he's actually excited at the idea that we may do away with ClojureScript and use pure Clojure (on the server-side) and server-side events, with just a tiny of JavaScript.
The real demo starts around 26:30. He shows a Webapp running on the client and how much resources it's using, then he shows the exact same Webapp running on the server and pushed one-way to the client using SSE. It is wild: resources usage drops to near zero.
YMMV but I find it easier to reason about my webapps and manage state now that I'm using a minimal DOM morphing lib: I used to have two REPLs (one for Clojure, one for ClojureScript) and lots of back-and-forth traffic and hard-to-track / reproduce state. Now everything is definitely snappier and way easier to reproduce.
I'm not saying SSE is going to work in every case though: YMMV. But in any case the video or at the very least the demo starting @ 26:30 is very much worth watching.