cljs-dev

dnolen 2025-11-17T15:10:20.165519Z

Spent some time messing around w/ Proxy - it's gotten a lot, lot faster

dnolen 2025-11-17T15:11:05.056699Z

it also can be done lazily - so seems like some serious advantages over clj->js

Roman Liutikov 2025-11-17T15:11:38.308949Z

sounds similar to cljs-bean?

borkdude 2025-11-17T15:12:00.811699Z

has it become a lot faster compared to just objects though?

dnolen 2025-11-17T15:13:35.991819Z

cljs-bean is useful, but the wrong way

dnolen 2025-11-17T15:14:55.222039Z

ten years ago or whatever it was 1000X slower, now <10x slower or something

dnolen 2025-11-17T15:15:02.344009Z

but that isn't the only thing we're measuring

dnolen 2025-11-17T15:15:14.459839Z

clj->js isn't lazy and generates a lot of garbage

dnolen 2025-11-17T15:16:20.594999Z

(meaning it just allocates like crazy on the way to producing a JS values)

borkdude 2025-11-17T15:16:28.251509Z

I've considered doing proper immutability in squint using proxy

borkdude 2025-11-17T15:22:09.889869Z

as a replacement for clj->js it might work nicely. I wonder if you can also accomplish "expose cljs data structure as JS object" without an explicit call to wrap it in a proxy? that might be messy and would likely cause perf issues for existing callers

borkdude 2025-11-17T15:22:43.213249Z

I wonder if the js-interop already has done something like this

dnolen 2025-11-17T15:23:48.040779Z

I did a bunch of research, there's no transparent way in the JS standard - doing anything in CLJS is just too magical

borkdude 2025-11-17T15:24:58.687109Z

transparent way of doing what?

dnolen 2025-11-17T15:26:56.287009Z

you need explicit calls to wrap in proxy

borkdude 2025-11-17T15:27:03.512789Z

👍

dnolen 2025-11-17T15:29:22.101379Z

exhibit A where this would be nice any JS lib way to deal w/ DOM attributes - having to always clj->js that is meh.

borkdude 2025-11-17T15:32:07.217339Z

If have this little thing for it now: https://github.com/borkdude/reagami/blob/7e23c82c37726f9e749a28cf94677b5631df589d/src/reagami/core.cljc#L75-L86 Do you think converting in a proxy would result in any perf wins? You have to visit them all anyway so the time building a new JS obj may be just as fast as looking up things via a proxy. Need to measure this.

dnolen 2025-11-17T15:35:45.621179Z

proxied get w/ carefully written code + caching is faster than convert then read. again that's not factoring memory issues in less trivial programs.

dnolen 2025-11-17T15:37:56.249719Z

this is JSC, I need to verify Chrome & Firefox, though my impression is Proxy perf is good there too.

dnolen 2025-11-17T15:38:42.277689Z

I didn't realize that Vue.js was using this as the dependency tracking mechanism since 2020 (?) - so I have a feeling this technique has been taken up elsewhere and JS engines have optimized

Felipe 2025-11-17T16:23:34.918859Z

I remember @wilkerlucio experimented with Proxy some years ago and wrote his findings here https://blog.wsscode.com/alternative-to-clj-js/

🙏 1
dnolen 2025-11-17T16:38:07.167299Z

yeah it seems most of those runs are out of date, Proxy doesn't look bad any more, especially as the size grows

borkdude 2025-11-17T16:39:10.443499Z

the benchmarks run in your browser

dnolen 2025-11-17T16:39:34.691039Z

I know I just re-ran them all in Safari and Chrome, Proxy wins almost always

dnolen 2025-11-17T16:40:02.455079Z

and this is probably naive proxy, not super finely tuned like I am considering

👍 1
borkdude 2025-11-17T16:40:10.649919Z

makes sense

dnolen 2025-11-17T16:41:40.636539Z

I always thought Proxy was cool, but 10 years to make it fast sounds about right 🙂

😄 1
neumann 2025-11-20T19:53:02.972029Z

This is very cool!