Clojurians Log v2

Hey guys! I just published the finished Hoplon + shadow-cljs realworld app: https://github.com/rlander/conduit

Would love to get your feedback

BTW, I tried using only hoplon.goog to get rid of the jquery dependency but the app did not compile.

nice, congrats!

does it compare favorably size-wise to the othre frameworks? in terms of delivery

I'd say it's average with jquery but we could do much better. Personally, I don't mind jquery at all. But I know it might be a major turn off for some people.

Uncompressed ~600K

I got rid of ~200K by stripping "cljs.pprint"

wow i wonder why that was in there

I found a few pprint imports in hoplon.

oops that might have been me

(or maybe javelin, not sure)

200k is nothing to sneeze at, probably worth removing

I agree

It doesn't really matter for this app because, since I added a compiler directive, it won't get bundled

i just took a brief glance, but if i were to have to co-maintain that codebase, i would want each view to be in its own namespace. that's really personal preference, speaking, of course. i realize that some people prefer to have everything in one namespace for reasons(?)

The current bundle (compressed) is at 153Kb which is not the worst https://cdn-media-1.freecodecamp.org/images/DRmH8Fz15DLxXguz9d8NR0eVanX0U9xW9jom

I totally agree. Since I didn't have a lot of time on my hands and I couldn't find a reference large-ish hoplon codebase, I went with the same layout as the Re-frame implementation.

https://github.com/jacekschae/conduit

I guess without Jquery I can get to ~120KB which just about ties with Aurelia.

makes me wonder about having our own provider, i wonder if there is a runtime way to see code liveness

wdym "liveness"?

i would bet there's a lot of junk even in goog that doesn't get shaken out

oh, that the code delivered is actually exercised at runtime

live code as the opposite of dead code

Ah ok

Shadow-cljs does a great job at detailing the dependencies https://gist.github.com/rlander/ed45bd67ab1193d8bedb559eaa553b80

makes sense

But there's no way to know what's actually being used

I think the lowest hanging fruit there is jquery

at adzerk, we have a huge hoplon application and we organize the cljs files partly around views. like each conceptual "page" gets its own file

spec also gets bundled for some reason

some of those individual pages can be huge (like if there's a big complicated form with lots of logic)

and there are also a lot of them

The actual app code corresponds to less than 10% of the final bundle size.

oh interesting, it would be cool to instrument jquery maybe to see which methods actually get called by hoplon

to inform our own bare-bones provider

Interesting, that's what I was aiming at initially. But then I started factoring out the common parts and figured it wasn't worth the trouble for such a small app.

BTW, I'd love your opinion on how idiomatic that codebase is 😃

i'm taking a closer look now. one thing that sticks out to me is that your views have a lot of "markup," e.g. many layers of nested divs i think that's a good way to start out, but as you build more and more views, you typically end up coming up with abstractions and composing together elements a lot more

i still don't really know what approach to CSS i would recommend

my frontend skills are comparatively weak, especially when it comes to CSS

what we do in our app is we have most of our styling in a bunch of sass files, and our build pipeline includes compiling the sass to css

but we also end up doing some dynamic CSS stuff depending on the state of cells, because that's a superpower that hoplon enables

so in light of that, i'm not really sure if keeping your styling in CSS files is even the best approach anymore

anyway, what i'm getting at is that i don't think there's necessarily anything wrong with how you're doing styling

at any rate, i do think it's a good idea to define a lot of little "helper elements," in the same way that we compose together -small functions when doing FP

the way you're using cells looks good. it pretty much looks like something i would write, for whatever that's worth 😄

i like your "state" namespace where you define a bunch of cells at the bottom. we have something similar in our app

it really helps to have those cells in a single, really simple namespace, so that you can refer to it from a lot of other namespaces and avoid running into circular namespace dependency issues

App deployed: https://hoplon-realworld.netlify.com/