Clojurians Log v2
squint
I understand the rationale of keeping squint lightweight, it's an important feature that gives squint its appeal and reason for existence. Many probably wonder if it can rise to the level of its big brother cljs without compromising its lightweightness. Though I wonder if the literal notation should not be kept for persistent data structures like in clj(s), especially since immutability has demonstrated its value in react and the like. Use of the standard js data structures could come from a special notation like a dot prefix in front of opening parens and brackets. That would be more aligned with clj(s) semantic and possibly make squint another target of cljc, Anyway I'm no front-end guy so maybe there are other constraints I'm not aware of that would make this harder to achieve. Edit: pressed enter inadvertently so check out the rewording, as it was a cut and paste from https://clojurians.slack.com/archives/C08DU3MN76U/p1745480620898519?thread_ts=1744272030.316099&cid=C08DU3MN76U
Check out cherry 🍒
It’s basically squint but with persistent data structures as default
I think the big appeal of using JavaScript mutable datastructures is interoperability with the rest of the JavaScript eco system. I am currently using Squint to build a library that can be consumed by other JavaScript libraries and I think it is useful if they talk "the same language" in terms of data structures. Despite Squint relying on mutable data structures, it is in many cases still possible to write quite functional code in Squint for cases when a data structure is populated once upon creation and then remains unmodified throughout its lifetime.
yes we don't want to loose the use of js data structures, I'm only wondering if we shouldn't preserve the initial persistent semantic of clj(s) and thus have another notation for reaching to js data structures.
to add an example to @uppfinnarjonas’s point, https://github.com/nextjournal/clojure-mode is a library that can be compiled with both normal CLJS and squint and all the test suite passes :)
thus have another notation for reaching to js data structures.this is what cherry is for indeed
ok thanks, I'll check cherry. I'm no frontend guy but still trying to make sense of things
There's also a channel #cherry
A squint playground: https://squint-cljs.github.io/squint/ A cherry playground: https://squint-cljs.github.io/cherry/
oh forgot about the #js tag in cljs
ok so squint doesn't care so much about being a cljc target, cherry is on top of the cake already 😉
The above link to the clojure-mode library disproves this: it can very much be a cljc target, it is exactly used like that in that library
ok so squint can be a cljc target but only for code that does not rely on the persistence of data structures or non-string keys, right?
squint's core library is still functional and behaves like as if you're working with immutable data, so in a lot of cases the same code will work, but also in some cases it won't, e.g. when you are comparing data structures or performance wise when you're updating an object that has a lot of keys multiple times
in those cases you could also bring in a library like immutablejs
It's called "squint", because if you squint it looks like ClojureScript 🤣, but the whole point is that it's more JS than CLJS. So compatibility and interop with JS I think is the priority. Then within that constraint, can it remain as close to ClojureScript as possible is the next goal. Correct me if I'm wrong @borkdude
sounds good
😑 (squinting in agreement)