I stopped using clojurescript around 2015, primarily because I was tired of searching for/implementing clojure-idiomatic wrappers around the many javascript libraries out there. Put another way, I left clojure on good terms, and often missed its core functions, immutable data structures and lisp syntax when writing front-end applications. However, since then, javascript has changed a lot, specifically in terms of execution-suspending operators like async/await/yield/yield*. Meanwhile, the core clojurescript team has almost completely ignored these developments, preferring the immutable seq abstraction over iterators, and the core.async channel abstraction over promises/async iterators.<p>For this reason and this reason alone, I’ve personally stopped considering clojurescript as a viable technology or recommending it to others. I have no idea how comtemporary clojurescript developers interoperate with javascript libraries and built-ins which are now overwhelmingly promise-based when async. I am also incredibly skeptical of the core.async channel abstraction as an alternative to promises/async iterators insofar as I think it is strictly inferior to both promises and async iterators because:<p>1. There’s no standard way to communicate error conditions.<p>2. There’s no logical separation between data producers and data consumers, and any code with access to a channel can take or put values.<p>3. There’s no way to communicate nil values insofar as core.async chose to use nil to represent end of iteration.<p>I do not understand the decision by the core clojure team not to support promises or iterators, because one of clojure’s main selling points was pragmatic interopability with host language features. Nevertheless, I infer it must be an intentional decision not to support them, insofar as it’s so easy to support new language features in clojure with macros. Maybe it comes from a desire to adhere to “functional programming principles,” but I’ve found async/await, promises, and iterators/generators to be incredibly useful, so much so that I am unwilling to give it up for clojure’s immutability or nicer syntax.
Great to see people putting effort into making Clojure(Script) more accessible! As much as I like the language and the community, it historically wasn't a very beginner friendly place in my opinion. Not that people weren't friendly towards beginners but just a lack of resources targeted at beginners.
Having read most comments under this post, my conclusion is that the Blub Paradox is very real. I am surprised that otherwise sophisticated HN readers fall prey to it. I see a lot of comments which are outright dismissive, from people clinging to what they know, and in most cases not knowing much about what they are criticizing.<p>Over the years I've learned that if there is something very different about a language or a solution, or if there is something I do not understand, it is a strong indicator that it's something worth learning about. Sure, it might be worse than what I'm using, or might not be applicable to my use case, but usually there is something there worth investigating, and sometimes you discover a better way to program.
As someone who has been doing Clojure/Cljs for a long time, I really appreciate it whenever someone goes the extra mile in explaining the basics - All the things clojurians take for granted in their every day work. Kudos to the author!
Closure seems to focus on purity instead of productivity. When I read this article I imagine my team spending days to implement basic features they could implement in few minutes with vanilla JS.
Business don't care about code purity. Only security, performance and correctness really matter.