It was only http://reagent-project.github.io/ for React then there was https://github.com/lilactown/helix ! there is also https://github.com/roman01la/uix !??

Would be helpful if someone who has tried out all of these and has strong opinion on them 🙂

@thegobinath I haven't used helix myself, but a work colleague has and seems to have positive things to say about it. You might have better luck asking for insights around it in #helix

@yogidevbear for now, my idea is that, helix is a tiny library that is basically about hooks and uix is most of the other aspects of the react with its recent updates

Also, Reagent still works well, haven't tried the others

One of the biggest improvements to ClojureScript UI dev wasn't a CLJS library on our project - it was Storybook - https://storybook.js.org

some of this is possible w/ Devcards but Storybook has a mode optimized for React Native, so you can really "preview" the app and test the components in the simulator and on the device

the other thing here was needing to work w/ devs and designers who were learning ClojureScript - but knew JS / React / CSS etc. well

so we just write pure components in JS, which is fine - and then we put the app together in ClojureScript

one huge benefit is that it becomes obvious what the app actually does because there's only high level code

no component stuff, no styling

only business logic & state

That's pretty cool, thanks for sharing. Before this, I was thinking of Storybook only as of another way to document and present your components.

@p-himik I think Storybook is like TDD for UI, I wouldn't do another project without it

the JS / ClojureScript split has a secondary benefit in that you really can't get lazy about state management since you have a hard barrier

everything in Storybook has to be completely decoupled from everything, can't get lazy

the end result is that there are much, much fewer bugs than in other UI projects I've worked on

Storybook proves the component can do what it's required to do in complete isolation

and the ClojureScript bits are only about essential state management

and you're not wading through irrelevant styling gunk

Very interresting feedback, thank @dnolen! All this set up within Krell?

yes but Krell is really just a REPL, the build stuff is just plain old ClojureScript

Krell is only needed when releasing because of React Native assets for advanced builds

the only true custom pass

all the stuff about pulling everything together is just standard tooling including leveraging :bundle

Yes, that's why Krell is great, a thin layer over Reat Native 👍

@dnolen given :bundle, where do you think the barriers still are between cljs and the js world? Friction wise

I haven't personally encountered any issues

we've written components, leveraged RN components

integrated custom (iOS/Android) native modules

run advanced compilation and not written a single extern

Personally, I’d love to see really seamless requires between cljs and js. cljs from js and js from cljs. Is this something we might end up with?

Right!

the only issue is that Krell is a little rough around the edges still and hopefully can work on that

cljs <-> js is really problematic because JS modules and ClojureScript namespaces are fundamentally different

I’ve also wondered about esm and leveraving tools such as rollup

and both require build tools

and ClojureScript needs it to work at the REPL which really JS users don't care about - precise hot-reloading is not really a thing post-ES6 modules

I've thought about it a lot in the past but I think it's not worth the effort, but won't get in the way if someone comes w/ a good plan and patches

How critical is the Closure compiler to cljs future given static analysis tools in js land?

the static analysis tools in JS land still aren't that good was my impression every time I check

Closure is still state of the art

IS there any place for a 2 step process. cljs compile to Closure friendly but js native output, with optional closure optimisation as part of standard build tooling in a js world

also Google is using more ES6 / TypeScript so perhaps Closure will make this stuff easier ...

it's already a 2 step process

Or is this at odds with compile chain? I’m not too clued up

fair

the problem is if you want a JavaScript files to depend on a ClojureScript file

the other way is easy

Is there some literature out there about issues with that direction?

I think nothing substantial

Other then maybe dynamic ns declarations or late defs, doesnt a namespace look a lot like a module?

^fixed

yes, but the "other then maybe" is a big one

ES6 modules are like closures you can't get at them - ClojureScript namespaces are global objects and redefinition is trivial

most of the reason you're using a Lisp is redefinition

Racket works like this (which is where ES6 modules came from), and I really don't like it

there's a lot of things that we do at work like REPL into a running service or a running device and do some surgical change

that opaque modules close the door to

Fair. Static esm exports would be an issue for compile time optimisation maybe, But why would exporting a dynamic namespace as default esm export not be suitable?

that is an interesting bridging idea

so importing from a cljs namespace gives you a live blob

and then having a second path like cljsRequire(“x.y.m”) for live stuff

but I think there's lot of annoying details / non-obvious problems here

but I think there's also enough stuff in ClojureScript right now to just try it

writing custom passes is not that hard - https://github.com/vouch-opensource/krell/blob/master/src/krell/passes.clj

^ fair, I guess I just dont have a good idea about how the compiler works. But I’ll check it out!

https://www.youtube.com/watch?v=Elg17s_nwDg

is a good intro

I’m starting to build more into nodejs and I want to be able to integrate more natively into the ecosystem. npm publish cljs libs etc. Have people on the team writing in TS.

etc

Thanks! Will look into that.

Not just node, but browser as well. Really feel like theres untapped value in those ecosystems, that we’re missing out on in clj(s) land

:bundle and shadow-cljs go a long way to bridging the gap. But theres always work to be done

there's a big maybe there

@dnolen Another idea re js<-cljs could be a default as suggested above, but when static defs are expected, a ns metadata tag could suggest static esm exports rather then the live default thing

using JS is not that bad anymore IMO, could be improved a little

the other problem w/ using CLJS from JS is how meaningful is it

those fns will be bridging stuff

because of the data exchange problem

ClojureScript data structures are not arrays and not objects

and fns that can be called from JS must marshal to EDN to be idiomatic

so this won't be core fns, only bridging fns

Fair, but I think using cljs as a lib language can offer a bunch. I expose a cljs stuff to TS engineers in Kepler 16, and often they’re manipulating cljs data-structures from TS (they’re just opaque lib datastructures)

I’d also love to be able to easily publish cljs libs that expose js interfaces

And have that work in downstream compiler chains

Without bundling cljs every time.

Considering cljs lang as an npm lib that is simply required,

So that cljs libs can use js libs that use cljs libs. And then someone wants to ship that to the browser and so they compile and optimise it downstream somewhere

Like what happens in js world

one wacky idea would be to write a tool that just takes ClojureScript and converts it into a series of ES6 modules and you publish that

I'd be curious to see what problems you run into

this could probably be done w/ compiler passes as I said above

Right!

I could also imagine publishing clojurescript as a library to npm

yes that would be the point

right

I misunderstood what you meant. But thats exactly it

happy to see someone try that and help tweak whatever needs to be done to support that

would also be interesting as it would allow better measurements between Closure and other JS tooling for ClojureScript specifically

I’d support the same. Potentially financially, or time this year. Going to be building out more clj/cljs infrastructure this year for Kepler 16. Would be glad to have some of that feed back into the broader ecosystem

My own time is limited. But might get some time to play

I’m looking to hire someone full time into infrastructure mid 2021. Happy to commit some time to this effort

Good to know we would have some of your support

happy to help make things possible

I'm wondering why aclone is coping elements with dotimes? Isn't Array.slice much faster? https://github.com/clojure/clojurescript/blob/r1.10.773-2-g946348da/src/main/cljs/cljs/core.cljs#L432

@namenu historically, no - not consistently across every JS engine

we haven't measured recently should do that

@dnolen Thanks for the video. Good intro

Cont'd from https://ask.clojure.org/index.php/9949/macro-that-uses-cljs-async-and-clojure-async-how-to, cljs needs a designated, no-hack, future-proof way to answer compiling-cljs? when compiling clj for cljs use.

@claudius.nicolae probably we could add something to env map, every macro gets that

that said, very little in the analyzer has changed in a long time and I don't expect it to

@dnolen Although I put it in this room, my view is that it's something clojure (as a language) should do - expand the reader conditionals to work in clj macros somehow (not necessarily that, but the point is made).

Folks already use most often (:ns &env) presence as a flag (which could potentially be breaking in the future)

We can make a ClojureScript specific key to avoid the case where Clojure might use :ns, I don’t see anything else happening