How to replace JSON with TOON?

Someone really looked at JSON and said ‘you know what this needs? To be more like YAML because everyone loves YAML’?

The serialization of channels is configurable ootb with negotiation on connection. Feel free to add to the existing v1 and v2, both of which are JSON based. For browser/JS clients I’d wonder though if that’s really going to speed up things given how much of the js world is json.

It won’t change anything. The most important thing is how to ship strings to the browser as fast as possible. I don’t think any format change can beat the browser in parsing strings and modifying the DOM.

Ah, just looked at toon. I truely doubt it doing much at least for what the channel serialization or the lv contents transported on it is concerned. They’re already using no/short keys and efficient structures and on top of that stuff will most likely be compressed in transit. Unlike LLMs the browser doesn’t care nearly as much about a bit of duplication after decompression.

Currently, I use Phoenix Channel for communication between mobile and the backend. In some workloads, I noticed that parsing JSON is quite a heavy task. I replaced Jason with the native JSON library.

After looking at TOON, I found another interesting benefit: it can save bandwidth and reduce parsing time on both sides (mobile and backend).

I think I will try it with Phoenix Channel first. LiveView might require too many changes.

Make sure that you’re comparing the GZipped sizes in your bandwidth estimate. People tend to forget to do this.

And while he’s at it, he should compare the Brotli compressed payload sizes as well. Many CDNs and modern browsers support that as well.

Is it more efficient than MessagePack? There are already Elixir libraries for that.

MessagePack is more efficient than TOON, but TOON is easier to integrate with the LLM.