here’s a fun anecdote: every once in a while i peek my head back into js land to see if anything interesting has happened. this time, i read through the svelte manuals front to back. it seemed kind of cool in the first few chapters; then more complex in the next few chapters; then egregiously complex by the time i reached the svelte-“kit” chapters. i figure i would give it a week of my time to see if i could learn something new, and maybe pickup a few tricks. just an hour or two into earnest fiddling revealed that there have been major breaking changes from svelte 2 to 3 to 4. each release caused a bunch of barely-new supporting libs and pluggable alternatives to sveltekit to break in basically irreparable ways. the fragmentation of tooling was immediately confusing, and the majority of the projects seem abandoned in the upgrade transition, with dozens (or hundreds) of ghissues essentially complaining about a lack of keeping up with the churn. i just want to drop a huge kudos for the reframe team. i’ve been using it for ~6 years at this point with great success. it’s always paid off in dividends to just go all-in with reframe from the start. every app seems to inevitably grow into something requiring rich client side interactivity eventually. the ideas and their implementation have held up so well, i don’t know if there’s a more straightforward and resilient way to build a “sufficiently complex” web app.

Hey, is there a doc somewhere that describes how re-frame handlers should be set up, specifically, should we set up generic handlers (like based on a path that should be updated), or specific ones (like, with the name based around the action that triggered it)