Clojurians Log v2

Hm, normally everything down the dependency tree is rebuilt

That's what I thought, but not what we're seeing 🤔

that is the way it is intended yeah. it only recompiles/reloads files that are directly referenced. so c doesn't have a direct reference on a (or more specifically the namespace it is in), so it is not reloaded

you can change that behaviour by using :devtools {:reload-strategy :full} but depending on the build size that may be substantially slower

the actual strategy is this. you change namespace A, it is recompiled. on a previous compile all namespaces that had any direct reference to A are collected, so any var used. These will also be recompiled.

https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html#recompile-logic

:reload-strategy actually only affects the files that get reloaded, not recompiled. since if a file doesn't have any direct references it doesn't need to be recompiled, you are just relying on side-effects during load to occur.

Interesting. Thanks for the info, I'll check out that blog post.

Ha, interesting. I guess I never noticed this since in react apps the ui is updated after reload and everything is pulled by reference

Yes, this is rarely an issue for me as well.

I had the same question here :) https://clojurians.slack.com/archives/C6N245JGG/p1758813529397059

I'm terrible at searching 😅 🙈

I was terrible at finding this thread even when I knew it existed ;)

I'm very curious if there's actual technical limitations to why this would not work for us in cljs-land (which would be very sad indeed), and if those reasons are actually "impossible" or more like "infeasible" right now. Rails seem to be lovin' the new way since a few years back at least: https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203

I think its complete nonsense and CLJS is never going to be "bundler-less" since the browser doesn't understand it natively. so something must convert it to JS, and while doing so might as well do the positive things bundlers do

that being said, for JS dependencies you can use import maps just fine today

yeah, for external deps. but would be great not to have the one huge JS file (which is cache-busted on every tiny change to any namespace) 🙂 just feels so clunky.

but thanks for the insight, I assumed there was a deep technical reason why this would be hard (near impossible?) for cljs-land.

well the unoptimized code could be output in a way where each namespace is in a separate ESM .js file that is only :simple optimized, but given that its lacking :advanced optimizations overall things just will be much much larger. so one option is downloading 50 different .js files that result in like 1mb of JS. or downloading one highly optimized file (that also compresses better) and having 100kb total or whatever

I don't think the tradeoff is worth that. I also think the hey screenshot from the blogpost shows exactly that issue. 1.88s to finish is horrible.

thanks

@avocade a lot of stuff that is praised in Rails is usually exaggerated or incomplete, to be honest. I remember someone proudly showing a post about "caching" where they somehow "praised" the N+1 approach of loading associations in Rails because these all would be cached, but the logs "conveniently" removed the actual time to render the full page (but even what they kept showed that there was no performance gain)