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!
> 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.
I can finally use this little brain worm that has lived in my head for more than a decade now: IcedCoffeeScript has existed for ages https://maxtaco.github.io/coffee-script/ since well before ES got it.
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?
Check out Mint (https://mint-lang.com), it's s language where everything is built in: small to mid size projects can be built without any third party dependencies and JS interop is easy.
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.
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.
> 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.
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.
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?
I noticed borkdude posted this thread *and* he is listed as a contributor for this release.
For the longest time, I recall the opposition to async/await support being twofold:
1. adding support would require deep changes across the CLJS compiler (theller, creator of shadow-cljs, once tried and concluded this)
2. macros from libraries like Promesa provided similar convenience
There were some other arguments brought up at the time (e.g. just use core.async, expression-oriented languages aren't a good fit with async/await, etc.), but they were usually specific to one person rather than something you'd see repeated in forums.
In the Clojurians Slack, borkdude once stated he wasn't convinced it'd be impractical to add support. It seems that he eventually took the time and made it happen. Extremely thankful for that.
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.
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?
26 comments
[ 3.3 ms ] story [ 46.3 ms ] threadedit: 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!
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":
https://youtu.be/BeE00vGC36E
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.
https://hypermedia.systems/
I came to the conclusion that the best frontend is no frontend.
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.
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.
https://clojurescript.org/guides/promise-interop#using-promi...
Congratulations on the release :-)
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?
For the longest time, I recall the opposition to async/await support being twofold:
1. adding support would require deep changes across the CLJS compiler (theller, creator of shadow-cljs, once tried and concluded this)
2. macros from libraries like Promesa provided similar convenience
There were some other arguments brought up at the time (e.g. just use core.async, expression-oriented languages aren't a good fit with async/await, etc.), but they were usually specific to one person rather than something you'd see repeated in forums.
In the Clojurians Slack, borkdude once stated he wasn't convinced it'd be impractical to add support. It seems that he eventually took the time and made it happen. Extremely thankful for that.