4 ms·

JSON is already 20 years old. I guess things can’t stay the way they are forever (and 20 years in the IT world is a lot).

marcyb5st 5y ago
I am not sure. There are already superior (IMHO) alternatives and JSON still sticks around unaffected. For instance, at work we use protobuffers everywhere and now I am so used to that that I started using them also on my personal projects since I believe they are so convenient. In fact, I am not sure how many hours I saved from not having to write serialisation/deserialisation code, and how you can get full IDE support for your messages. However, it seems protobuffers (or alternatives like flatbuffers, cap'n proto) are still niches compared to JSON.
- leetrout 5y ago
  Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them. However I have yet to convince anyone at an org that isn't already using them that they will change things for the better. Schema once, code everywhere. It is really nice. Have you seen Buf? https://buf.build/ https://buf.build/
  - marcyb5st 5y ago
    Indeed a chicken and egg problem since investing in the tooling to make protobuf usage smooth requires some prior use. No, thanks for sharing! I will have a look!
- vstollen 5y ago
  I'm not too far into protobuf, etc., but do you only prefer them for your internal services, or do you actually see them as a viable solution for public-facing APIs?
  - marcyb5st 5y ago
    Great question! My rule of thumb would be for server to server apis use protobufs. Also probably for Android/iOS/Flutter clients (depending on how well the protobuf compiler is integrated in your toolchain). For web clients, last time I checked, grpc-web was the most complete implementation/tool, but couldn't make it work with the rest of our stack. Maybe spending more time I could've, but it got really frustrating and I gave up.

marcyb5st 5y ago

I am not sure. There are already superior (IMHO) alternatives and JSON still sticks around unaffected. For instance, at work we use protobuffers everywhere and now I am so used to that that I started using them also on my personal projects since I believe they are so convenient. In fact, I am not sure how many hours I saved from not having to write serialisation/deserialisation code, and how you can get full IDE support for your messages. However, it seems protobuffers (or alternatives like flatbuffers, cap'n proto) are still niches compared to JSON.

leetrout 5y ago
Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them. However I have yet to convince anyone at an org that isn't already using them that they will change things for the better. Schema once, code everywhere. It is really nice. Have you seen Buf? https://buf.build/ https://buf.build/
- marcyb5st 5y ago
  Indeed a chicken and egg problem since investing in the tooling to make protobuf usage smooth requires some prior use. No, thanks for sharing! I will have a look!
vstollen 5y ago
I'm not too far into protobuf, etc., but do you only prefer them for your internal services, or do you actually see them as a viable solution for public-facing APIs?
- marcyb5st 5y ago
  Great question! My rule of thumb would be for server to server apis use protobufs. Also probably for Android/iOS/Flutter clients (depending on how well the protobuf compiler is integrated in your toolchain). For web clients, last time I checked, grpc-web was the most complete implementation/tool, but couldn't make it work with the rest of our stack. Maybe spending more time I could've, but it got really frustrating and I gave up.