The :hoplon: ClojureScript Web Framework - http://hoplon.io/
rlander 2020-03-02T17:32:01.044900Z

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

rlander 2020-03-02T17:32:09.045300Z

Would love to get your feedback

rlander 2020-03-02T17:33:39.046100Z

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

rlander 2020-03-02T17:35:32.048Z

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.

rlander 2020-03-02T17:35:56.048300Z

Uncompressed ~600K

rlander 2020-03-02T17:36:41.048800Z

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


wow i wonder why that was in there

rlander 2020-03-02T17:37:55.049600Z

I found a few pprint imports in hoplon.


oops that might have been me

rlander 2020-03-02T17:38:18.050300Z

(or maybe javelin, not sure)


200k is nothing to sneeze at, probably worth removing

rlander 2020-03-02T17:39:25.052100Z

I agree

rlander 2020-03-02T17:40:11.052900Z

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

dave 2020-03-02T17:41:07.054Z

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(?)

rlander 2020-03-02T17:43:05.054900Z

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

rlander 2020-03-02T17:44:58.055300Z

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.

rlander 2020-03-02T17:45:24.055500Z


rlander 2020-03-02T17:47:21.056500Z

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

rlander 2020-03-02T17:48:26.057500Z

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

rlander 2020-03-02T17:49:00.058700Z

Ah ok

rlander 2020-03-02T17:50:43.059200Z

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

dave 2020-03-02T17:50:49.059500Z

makes sense

rlander 2020-03-02T17:50:52.059700Z

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

rlander 2020-03-02T17:51:17.060100Z

I think the lowest hanging fruit there is jquery

dave 2020-03-02T17:51:21.060200Z

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

rlander 2020-03-02T17:51:36.060600Z

spec also gets bundled for some reason

dave 2020-03-02T17:51:49.060700Z

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

dave 2020-03-02T17:51:57.060900Z

and there are also a lot of them

rlander 2020-03-02T17:53:16.061400Z

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

rlander 2020-03-02T21:47:54.062Z

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.

rlander 2020-03-02T21:48:30.062200Z

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

dave 2020-03-02T22:19:55.062400Z

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

dave 2020-03-02T22:21:14.062600Z

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

dave 2020-03-02T22:21:27.062800Z

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

dave 2020-03-02T22:21:48.063Z

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

dave 2020-03-02T22:22:28.063200Z

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

dave 2020-03-02T22:22:44.063400Z

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

dave 2020-03-02T22:23:52.063600Z

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

dave 2020-03-02T22:24:20.063800Z

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

dave 2020-03-02T22:25:48.064100Z

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

dave 2020-03-02T22:26:22.064300Z

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

dave 2020-03-02T22:26:55.064500Z

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

rlander 2020-03-02T23:47:29.064900Z

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