4 ms·
Why choose this over Google's Protocol buffers? https://github.com/google/protobuf https://github.com/google/protobuf
by mukundmr 11y ago
Why choose this over Google's Protocol buffers? https://github.com/google/protobuf https://github.com/google/protobuf
- mateuszf 11y agoOne reason is compatibility - it can be encoded to json and thus is handled by http proxies, etc. It is also human readable in encoded form.
- icebraining 11y agoProtobuf is just a serialization format; you can send it over HTTP.
- jzwinck 11y agoOne issue with Protobufs is they do not always enable optimal performance (latency, power). Better than JSON but worse than some others. Compared to MessagePack, Protobufs require a schema, which is not always convenient. Compared to Cap'n Proto, Protobufs are less CPU efficient. Trade offs all around.
- zamalek 11y agoIt looks like Transit can be late-bound - like JSON: you don't need to know or negotiate the schema ahead of the serialization.
- mstade 11y agoOne reason for using something like Transit in browser-land is performance, believe it or not. According to tests we did (6+ months ago, so take with some salt) there was significantly less latency in deserializing Transit, which matters more than size on the wire in some cases. This is because Transit is just JSON with some semantics added, so in the simple case it's just a `JSON.parse` away from being a usable data structure in Javascript. Of course, if you actually want to make use of Transit features, you'll want a reader, but these can be made very performant (especially if you don't have to support all features) so latency can still be kept very low. There are other reasons as well, but deserialization latency is a big one.