The differences with ts-proto?

[frederikhors]

Can I ask you what are the differences with this other project: https://github.com/stephenh/ts-proto?

Thank you!

[timostamm]

Of course.

protobuf-ts took some inspiration from ts-proto. Most importantly using interfaces to describe messages.

There are quite some differences, though:

conformance

ts-proto uses the third party library protobuf.js to encode / decode messages in the binary format.

protobuf-ts on the other hand implements the binary format from scratch. Compatibility is tested with the protobuf conformance test, which also covers the JSON format.

protobuf.js does not pass the conformance tests.

3rd party requirements

The code generated by ts-proto usually does not need any packages (except long.js). I consider this a big plus for ts-proto.

The code generated by protobuf-ts requires the runtime package @protobuf-ts/runtime.
For a web application, protobuf-ts requires much less javascript code than ts-proto. See code size vs speed, where protobuf-ts uses little more than a third of the code size that ts-proto requires.

reflection

protobuf-ts provides field information. You can generate a form for a protobuf message, for example. You can use custom options to annotate your fields, for example to set validation rules. I think ts-proto generates some reflection information for services, but as far as I know that's it.

bigint support

ts-proto uses the 3rd party package long.js for 64-bit integral types. protobuf-ts can use native bigint.

well-known types support

protobuf-ts supports all well-known types, including the specialized JSON representations.
At the time I was evaluating ts-proto, support for well-known-types was quite spotty, especially in the JSON format.

specialized field representations

ts-proto has some special handling for certain type. For example, a google.protobuf.Timestamp field is generated as a Date property. This can be very convenient. protobuf-ts does not provide this feature.

rpc support

ts-proto has the RpcInterface which lets you provide your own implementation. I would like to think that protobuf-ts takes this a bit further with better support for streaming methods. With the upcoming 2.0 release (available in the "next" channel), you can also generate gRPC clients and servers.

There are some more obscure points like unknown field handling where protobuf-ts has some advantages. On the other hand, ts-proto provides way more options to customize the output.

Please take this comparison with a grain of salt. I wasn't happy with some shortcomings of ts-proto and decided to start an alternative. But it is possible that protobuf-ts has some shortcomings for your use case that ts-proto might solve. ts-proto is an excellent package and I don't want to diminish Stephen's work.

[frederikhors]

Thank you very much indeed.

Why don't we join forces and create a unique and powerful library?

[xmlking]

ts-proto has some special handling for certain types. For example, a google.protobuf.Timestamp field is generated as a Date property -- this is a big deal, considering 2-way data binding with many angular/react/svelte components expect JS Date.

[louisrli]

I wanted to just give my two cents here after trying to set up the infrastructure for an app that would use protos on the web and server sides (using TS for both sides for simplicity). I've made a blog post about it, which discusses some of the differences between the two apps for the web use case and also highlights discrepancies in the quality of documentation. Again, emphasizing, this is focused on those using it for web.