rx

I've rewritten the framing in the README to first explain when you should use RX and when you should not. Most uses of JSON should probably stay JSON. Let me know what you think https://github.com/creationix/rx/blob/main/README.md#when-to...

Initial format docs are now here: https://github.com/creationix/rx/blob/main/docs/rx-format.md Railroad diagrams will come later when I have more time.

oh, sorry about that. I forgot to include the description of the format with examples. I did add some small examples to the repo. https://github.com/creationix/rx/blob/main/samples/quest-log... The older, slightly outdated, design spec is in the older rex repo (this format was spun out of the rex project when I realized it's actually a good standalone format) https://github.com/creationix/rex/blob/main/rexc-bytecode.md

Came to the same conclusion the moment I had to hunt to see the outputs https://github.com/creationix/rx/tree/main/samples

This is really interesting. At first glance, I was tempted to say "why not just use sqlite with JSON fields as the transfer format?" But everything about that would be heavier-weight in every possible way - and if I'm reading things right, this handles nested data that might itself be massive. This is really elegant. My one eyebrow raise is - is there no binary format specification? https://github.com/creationix/rx/blob/main/rx.ts#L1109 is pretty well commented, but you can't call it a JSON alternative without having some kind of equivalent to https://www.json.org/ in all its flowchart glory!

Very cool stuff! This did catch my eye, however: https://github.com/creationix/rx?tab=readme-ov-file#proxy-be... While this is a neat feature, this means it is not in fact a drop in replacement for JSON.parse, as you will be breaking any code that relies on the that result being a mutable object.