> so many problems The thread is only focused on one particular problem of bindings being used in async contexts, no?

if you read Bloom's message about 6 from the end there's an example that isn't async, it /is/ about bindings but it's more broad than just async I think. Also if you're working in cljs you are forced into a lot of async, whether that's core.async, callbacks or promises etc. But by "so many...", I think a lot of design space is enabled/disabled by the ability to capture dynamic bindings like that

I think the user-space workaround is to copy over any dynamic vars, assigning in a let must somehow capture it: (binding [x "in binding"] (let [y x] (println x) (println y) (js/setTimeout #(do (println x) (println y)) 1000)))

The only other explicitly stated motivation apart from binding across async/sync boundaries is "Better parity with JVM Clojure". The example that that message by Bloom provides works the same way in both CLJ and CLJS, so at that point Bloom tries not only achieve better parity (which is a questionable desire by itself) and bind values in async contexts, but also extend what CLJ does. > if you're working in cljs you are forced into a lot of async Yes. And across three of the projects that I maintain that have a lot of CLJS code, I created exactly one dynamic variable. And even that was only to make things a tad more convenient without thinking too hard - I'm almost certain there's a better solution. Not saying it's an invalid desire, but I become quite suspicious when people say that something can't be done other way.

And your workaround with let works only for trivial cases where x is used right then and there and isn't referred to by some other function that you use in the same binding.

I don't think the example does work the same in cljs and clojure, iirc bound-fn doesn't exist in cljs so it can't work the same. What is said in that message is that it works the same /in his fork/

I don't think anyone said this? > people say that something can't be done other way. (edited)

I agree re the let binding, that's why it's difficult

> iirc bound-fn doesn't exist in cljs Ah, oops - I use dynamic vars so rarely that I've completely forgotten that bound-fn already exists in CLJ, heh. Alright, so I retract my statement about "trying to extend what CLJ does". The rest still stands. > I don't think anyone said this? That's how I interpreted "a lot of design space is enabled/disabled by the ability to capture dynamic bindings". To be honest, I become suspicious even when somebody tells that a dynamic var is the best solution somewhere. There are exceptions, of course, but few and far between.

I think we're in danger of agreeing then, apart from maybe re the relevance of dynamics but that could be discussed another day

https://github.com/tc39/proposal-async-context could be something that CLJS eventually rewrites (or, more likely, a separate macro is created for) that would give the behavior desired.

could be this https://github.com/cookpete/react-player/issues/1481