What is the future of this repo given Protobuf-ES?

[jcready]

I see you've been busy :) https://github.com/bufbuild/protobuf-es/blob/main/docs/migrating.md#from-protobuf-ts

protobuf-ts is an open source implementation of protocol buffers focused on TypeScript. If you are familiar with it, you will probably recognize many concepts from protobuf-ts in Protobuf-ES. To some degree, that is because many bits are from the same author, but also because they have proven themselves.

So why add another implementation? protobuf-ts comes with several RPC implementations, uses interfaces for messages (which is nice, but also has some downsides), and is married to the TypeScript compiler API to generate code, so it is not straight-forward to write plugins based on it. You can think of Protobuf-ES as a refined version of protobuf-ts, that is suitable as a foundation for other projects to build upon.

I get the sense from that last sentence (and the fact that you actually get paid to work on Protobuf-ES) that protobuf-ts will probably get less attention going forward. I would be happy to be wrong about that, but I'm also a realist and totally understand not wishing to support two competing implementations. I'd like to migrate to Protobuf-ES since that seems to be the future, but the switch away from plain objects and interfaces to a class-based implementation is a tough pill to swallow.

P.S. that oneof representation looks great!

[timostamm]

Yes, pretty busy indeed. JavaScript needs a generator that only generates base types - that wouldn't have been possible without turning protobuf-ts inside out all at once... I'm working on https://connect.build/ at the moment. When that's wrapped up, I plan to spend more time on protobuf-ts again. I think it should be possible to switch to the protobuf-es base types, and provide all the nice RPC features around them. I imagine this is a few major releases ahead, though.

Classes vs interfaces is a super interesting topic. There are many things like unknown fields, well-known types and other use cases that just fall into place when messages are self-describing. On the other hand, plain object types are typically easier to (de-)construct and mix. So far, object spread and destructuring have been working really well, see PlainMessage. Do you have some concrete use cases in mind where a class type would be an obstacle?

[jcready]

Yeah, the (de-)struct and mix thing is really the big one. One major issue we had with other implementations was that the default values were part of the prototype which meant that those values would not survive a round trip to/from a Web Worker. It doesn't seem like that's an issue with Protobuf-ES, though I haven't looked too closely.

Aside from that (and I realize this is purely a stylistic preference), but I much prefer function-style code over OOP. I realize protobuf-ts has classes, but they can essentially act just like plain object with property function as far as the consumer is concerned (e.g. a consumer never has to use new in their own code). Perhaps this could be solve with a feature request for some static from or create method on the Protobuf-ES MessageType class. In fact, it seems like the migration from protobuf-ts could be made even easier if other static methods were available like Example.toJson(examplePlainMessage) and Example.toBinary(examplePlainMessage).

[derekperkins]

Cc @tannerlinsley