[skybrian]

Back in the day, it wasn't used for private API's either. Different teams had come up with different ways of encoding protobuf-style messages as JSON for web apps.

For the best browser-side performance, usually you want to use browser's native JSON.parse() API call and this doesn't really let you use unmodified protobufs. In particular, you can't use 64-bit ints since that's not a native JavaScript type. Meanwhile, server-side folks will use 64-bit ints routinely. So if the server-side folks decided on 64-bit integer ID's, you need workarounds like encoding them as strings on the wire.

JavaScript has BigInt now, but still doesn't natively support decoding 64-bit integers from JSON.

It didn't seem like the gRPC folks understood the needs of web developers very well.

[akshayshah]

Is decoding performance typically a problem for web UIs? The lackluster performance of binary protobuf decoding in browsers (and unmarshaling BigInts from JSON) seems much less problematic than (1) using a 200 for unary error responses, (2) choosing a wire format that's _always_ opaque to the network inspector tab, and (3) having really poor generated code.

> It didn't seem like the gRPC folks understood the needs of web developers very well.

Agreed. Being fair to the team that designed the protocol, though, it seems like browsers weren't in scope at the time.