tsslint really seemed like the best approach until the TS-Go port. Now it looks like there's going to be the trade-off of either: Go-JS communication layer; or forking TS-Go and running a seperate TS server for linting and no custom rules.

A neat thing about factorial is it's relatively easy to use a value up to n! as a encoding/ranking for any given possible permutation in the set, or in this case a specific mapping between 2 sets.

A simple use case is a seeded shuffle algo.

Why should it not be the case?
It's a useful feature of private fields. As is classes defined inside a class being able to access the private fields of the parent, which allows creating safe Foo, FooController objects without regressing perf by using WeakMaps.

I would've loved to see a progressive re-write in TS with major breaking changes. I bet something like that could've also improved perf.

The only clear benefit seems to be performance, but was that really needed... Compiler performance is something that's already solved by third parties. Have type checking and language server performance really been a pain point for users lately? If so it's news to me.

I'm no fan of Go, but rather than the language choice it's the act of porting itself that concerns me. There's a fair amount of blocked fixes and features due to design limitations, and this port isn't going to rectify that. Nor does it seem likely that it will improve the pace of development.

The Go port has made me the least optimistic I've ever been on the future of TS. I'm ready for a successor. There's a lot that could be learned from TS past mistakes (built-in jsx among them).

The funny thing is there would very likely be better JSX support in TS if it was a plugin. So many features that are hindered by the stagnant built-in support. You can get better typing capabilities by forgoing the jsx syntax and calling jsx/createElement functions directly.

If there's server caching on data or pages (CDN, Next force-cache, interservice caching with Redis, etc) then navigation really doesn't have control of staleness. It's pretty costly to avoid server caching at scale.

No telling when items will sell out. An item could sell out after navigating to the cart, before purchase. Or it could be a store for digital goods.

Inventory can also be a separate endpoint requested periodically as they browse, or sit on a page. No need to re-fetch name and description.

Avatar isn't critical so not seeing it update until navigation after ttl expires seems fine, ttl can even be pretty low. If you want instant, then you want a sync engine.

If someone viewed that screen before you, there's a possibility of it being stale, unless you never cache your bundles on a CDN.

Forward navigation can still be stale with bundled data, it can even be worse. It's easy to mess up the ttl of a bundle such that some of the highly variable data lives too long. Frameworks could detect the ttls of the bundled data and choose the lowest, but as far as I'm aware none do.

Social platforms near the area where a sync engine would be beneficial though.

Another example is a shopping cart where the list of items in the cart is in local storage, the user has the item data already since they were on the pages of each item when adding to cart.

Bluesky as an example. Author data does not need to be bundled with the list of posts. Doing so means you will be doing wasteful joins when the user navigates to the detailed post view, where they already have a good chunk of the author data.

Benefits are exaggerated, and it has negative impact on caching.

It's pretty common for some data on one page to be used on the next page, or a page after that.

It's worth bundling items in a list because of DB efficiency, but single units shouldn't be bundled with other single units IMO.

Similar to Events the propagation can also be halted, for example on a derivation that has it's cache invalidated.
It works quite well, and I've yet to find any kind of reactive primitive you can't build with it.

Sadly the reactive graph is often coupled to signals. In Metron I chose to decouple them using a stateless reactive node primitive. It can be thought of kind of like a EventTarget except it's part of a directed acyclic graph instead of a tree, and there is only one event type.