[skybrian]

Sadly the JSON format they chose isn't actually suitable for high-performance web apps. Web developers who use protobufs will continue to get by with various nonstandard JSON encodings.

[positr0n]

Why isn't is suitable? (I've never used protobufs)

[skybrian]

The fields are indexed by field names (converted to lower camel case) instead of tag numbers. It's great for readability, but it's a lot more verbose, particularly for repeated fields.

[ambrice]

> Added a new field option "json_name". By default proto field names are converted to "lowerCamelCase" in proto3 JSON format. This option can be used to override this behavior and specify a different JSON name for the field.

[skybrian]

Right, but nobody's going to set that for every single protobuf field.

[ambrice]

You're right. The only people that would use it are people that a) care enough about optimization to switch out shorter tag names and b) don't care enough about optimization to switch to binary format. Probably not many..

[skybrian]

Except everyone who is doing RPC in a browser. Not sure why that is, but binary formats aren't popular. We still care about performance.

[peq]

I think the only reason to use json over the binary format is readability, so why care about this?

[detaro]

What characteristics of a JSON format would be important?

[the_duke]

Why would you use JSON in a high performance context anyway?

[skybrian]

Because the code is running in a browser.

Browsers do support binary data using typed arrays but for some reason this isn't commonly used yet. Compatibility, maybe?

[artursapek]

This library is very good at serializing and deserializing binary proto3 messages in the browser.

https://github.com/dcodeIO/ProtoBuf.js/