Indeed to both. I enjoyed it greatly. It was well written and on something that I think about someone's but never implemented.

It was great working with Redux, Immutable.js which was recommended by Redux, React, and Reselect managing thousands of points of time series streaming market data. The state stayed immutable, and when I needed to break cache I returned a new object for the affected slice in the root state tree. That change, changing the object reference on a leaf of the state tree, triggered Reselect to recompute its memoized selectors, and React / Redux (with shallow equality checks) picked up the new references and rerendered only the impacted components.

I used Ramda for all data transformations as data flowed through the app. I ran the code in React Native also and could count the precise number the of operations a megabyte or two of data updating every few seconds that included data visualizations needed. Nothing was hidden!

A decade ago I attached myself to Mongo, Express, Angular, Node stack and it was a disaster waste of time and nobody was hiring for that skill set. Beginning of 2018 I started with the React, Redux, Immutable, and ReSelect and it was a massive success. I got very lucky when I started that project that was the hot new JavaScript stack all the bloggers were raving about. A broken clock is correct twice a day.

Probably better to use an LRU cache rather than weak maps.

People are too addicted to automatic stack traces for mainstream languages to optimize away stack frames.

If my memory serves right, the browser vendors couldn't agree on the implementation.

On the one hand, allowing any function to be eligible for TCO means that the developer won't know if the code was optimized or not. A trivial change can easily convert a fast function to one that blows the stack. Additionally, every function created- or at least every named function- would need to be analyzed, causing a performance hit for everyone, even those who never write a recursive function in their lives.

On the hand, some argued that TCO eligibility should be explicitly opt-in with some sort of keyword or annotation. If a function so annotated did not end up being a valid target for TCO, the script would not compile, similar to a syntax error. This is an even more harsh failure mode than the implicit version, but would have been easier to identify.

I vaguely recall chrome devs generally being in favor of explicit annotations, and Safari implicit. I could be completely wrong on this, and I don't think anyone was particularly enthused about the trade-offs either way.

It does if you use JavaScriptCore (Safari, other Webkit browsers, Bun).

TCO is actually in the ES6 spec but browser vendors (except Safari) haven't implemented it due to concerns about debugging (stack traces become less useful) and security implications with stack inspection.