Fork me on GitHub
#reagent
<
2019-08-12
>
tianshu15:08:04

is there a big trade off on initial rendering on complex page with reagent, comparing to vanilla React.

lepistane15:08:02

i dont think so but maybe someone more knowledgeable can confirm

tianshu16:08:11

I have a page which render a lot divs, I think it's a bit slow, but I don't know where is the problem. I also using (cljs generating css), maybe that's the problem.

lepistane16:08:07

do u have a lot of state? is it locally or on production too? are u using vanila reagent?

tianshu16:08:59

@lepistane I'm using reagent with re-frame, it has states but I care about the initial rendering. the state will only have small changes, so after the first time, it's pretty fast. It's slow on old mobile phone but fast on well performance devices.

tianshu16:08:41

I want try an enhancement, but I don't know which part should I do first.

lepistane16:08:49

the only problem i've had with reagent and re-frame and slowness was when i had table with around 100 cells

lepistane16:08:54

and each cell was different state

lepistane16:08:20

after being in shock i implemented vanila html tables

lepistane16:08:23

and it was fast as hell

lepistane16:08:33

turns out antizer was the slow one

lepistane16:08:49

(lib that i delegated tables to)

tianshu16:08:11

what is the vanilla html?

tianshu16:08:30

you mean implemented without React or without Reagent or without Antizer?

lepistane16:08:51

when i say vanila - i mean re-frame/reagent custom table implementation without Antizer

tianshu16:08:43

Oh, I see. it seems to be a problem without a lot of interop work?

lepistane16:08:07

i think that version of Antizer didn't know to change state of only 1 cell but it updated all cells even if only 1 changed i know a lot of people have landing pages done in cljs and initial load should be on pair with React

tianshu16:08:30

I wondering will nested components cost a lot? will these two usage have big difference?

(defn foo [child]
  [:div child])

(defn bar [child]
  [:div child])

(defn baz []
  [:div])

[foo [bar [baz]]]
and
[:div [:div [:div]]]

tianshu16:08:58

in my head, I'm thinking if each layer is a component, it have to compare the state when state changes at its parent.

tianshu16:08:31

but some friend told me, not each component, each vdom need compare the state which passed. I'm confused now.

lepistane16:08:46

it depends how u structured the code. I suggest u have a look at re-frame docs (on github) they do very good job at explaining what is going on also https://reagent-project.github.io this should explain the referencing of the state (subscribes)

lepistane16:08:34

some things from React don't translate to reagent/re-frame directly (and they shouldn't)

lilactown16:08:05

@doglooksgood if you’re worried about performance, I would use something like Chrome’s performance analyzer to look at what might be taking up a lot of time

lilactown16:08:51

you could also try using the beta React DevTools profiler. I haven’t tried it with Reagent, but it might be able to illuminate what is React vs. what is Reagent vs. what is your code

lilactown16:08:02

IME, the initial rendering can take a little longer while developing because you load each namespace as an individual js file

lilactown16:08:15

so be sure you’re looking at performance after doing a release build

👍 4
dominicm19:08:03

Reagent is slow compared to vanilla react though

dominicm19:08:27

https://github.com/roman01la/uix/blob/master/README.md#hiccup-interpretation uix is 1.5x slower than vanilla react, but easily 2x faster than reagent. That would place reagent at 3x slower than vanilla react.

lilactown19:08:53

it is slower at a particular operation, yes

lilactown19:08:09

you’d want to profile your application to see if that’s actually what might be causing a performance issue

lilactown19:08:09

hiccup interpretation happens frequently and is slower than using raw react, but is still incredibly fast and should be assessed along with the rest of your application code

lilactown19:08:46

I’m not exactly making excuses for hiccup interpretation slowness, as it is an unavoidable cost to using reagent and therefore should be made better. but most projects will benefit from profiling and optimizing their application before they will find reagent hiccup interpretation the direct cause of slowness

lilactown19:08:40

saying that reagent is “slower” is also not exactly right; it’s render might be slower, but in some cases helps lead to architectures that are inherently faster than vanilla React

lilactown19:08:15

e.g. using RAtoms as subscriptions is faster than vanilla React context for global state management

lilactown19:08:51

also, speed to first interaction, is different than render speed over 1,000,000 operations, is different than perceived speed across an interaction....