It's not truly reactive if you have to do a build to make anything happen. But maybe that doesn't matter, as long as it's reactive during development?
It’s kinda cool to think about the shearing layers of reactivity. Reactivity is what originally drew me to Observable. But the way notebooks have to be recomputed live for every viewer every time makes them feel silly for, like, a BI dashboard that changes daily at most. Like they only have one pace layer. Like they’re trying so hard to be _live_ that they can’t be _fast_! Idk. I guess even a chalkboard is reactive on the timescale of “someone noticing some information and telling it to someone who writes it down” lol.
That's deliberate, since they don't want packages to update their dependencies without testing them, and builds are supposed to be deterministic.
So it seems like for cross-project data dependencies, there's a tradeoff between deterministic results and getting the latest data? If one project depends on a JSON file from another project, and the JSON changes, when do you want or expect to see the change? There needs to be a version history for changes to the external JSON file to get a choice in the matter. (Perhaps it's cached locally.)
When I first started working at Observable I explained reactivity to my now-wife as “when one thing changes, other things that depend on it update automatically.” She was at an asset management job at the time working in Excel all day, which of course is also reactive in that sense. But she interpreted my statement differently; she said “Oh that’s terrible! If a number changes I want to know.” E.g. if the estimated budget for a project had ballooned, she wanted to hear about it so she could check why, ask other people about it, try to contain the damage, warn others, make other decisions differently, etc. “Automatic” would be harmful, like in your Go example. She was also thinking about coarser-grained data than I was — a single very impactful number, not a stream of mousemoves or pageloads or ad clicks or whatever.