Fork me on GitHub
#clojurescript
<
2018-12-18
>
kwladyka10:12:18

Is there any “official” docker image for clojurescript + node + clojure cmd instead lein ?

dnolen12:12:04

not that I'm aware and you probably won't see anything like that from the core team

kwladyka13:12:01

ok, thanks for feedback

bhauman16:12:51

announcing this new npm library for react-native https://github.com/bhauman/react-native-figwheel-bridge

👏 28
bhauman16:12:58

and figwheel

lilactown17:12:58

AWESOME! super excited to see anything moving the needle on RN + CLJS 😄

lilactown17:12:57

does this remove metro from the workflow?

lilactown17:12:17

😉 wishful thinking

lilactown17:12:18

yeah! super interesting

bhauman17:12:35

what was the name of your library?

lilactown17:12:20

I’m taking the “runtime interpretation, possibly slow templates” approach right now 😛

bhauman17:12:58

yeah that’s not the best 🙂 and its really not good for react-native

bhauman17:12:19

I’ve seen some pretty slow screens render in reagent

loading 4
lilactown17:12:25

but it is incredibly interesting. I went down the macro hole earlier this year and like he outlines in the article, found it frustrating and dangerous for new users to figure out what was interpreted vs. not

lilactown17:12:07

I could play some tricks to get certain things to compile but then that just ended up being even more confusing when it didn’t

bhauman17:12:13

I get it but I think this approach that uses inference is really good

bhauman17:12:46

and the hybrid approach can still save lots of invocations

lilactown17:12:52

yeah I think it’s awesome

bhauman17:12:48

we actually need some good numbers though

bhauman17:12:07

I’ve done some tests that show a X2 speed up

lilactown17:12:10

yeah, I was thinking about last night how best to do a benchmark of the actual cost of the runtime hiccup interpretation vs compilation

bhauman17:12:00

and 2x speed up makes a difference when you are trying to render at 60 fps

lilactown17:12:25

yeah absolutely. I’m kind of surprised at that number but if that’s true, woof

bhauman17:12:49

but to be fair this really only matters on large node counts

lilactown17:12:55

I’m guessing it grows… yeahh

bhauman17:12:02

actually I could build the render timing into the figwheel-bridge

lilactown17:12:05

and I wonder how it changes with large trees of shallow components (so you’re calling the interpreter many many times) vs. deep components, shallower total tree

lilactown17:12:32

that could be nice to have!

bhauman17:12:33

and its really the initial render that matters when changing screens

bhauman17:12:00

incremental renders should be comparatively minimal

lilactown17:12:17

I’ll play with this more today. I have a project that I’m going completely into outer space with; using hx + a fork of re-frame, react@next and hooks, all the new toys.

lilactown17:12:46

replacing hx’s hiccup compiler with kevin’s hicada fork is easy

bhauman17:12:02

thats awesome 🙂

dpsutton21:12:27

how do you check if something is defined in js/window? ie, if ('requestIdleCallback' in window)

lilactown21:12:42

(exists? (.-requestIdleCallback js/window)) ?

dpsutton21:12:17

thanks. will try

lilactown21:12:24

goog.object also has containsKey

👍 4
dpsutton21:12:34

much appreciated