3 ms·

I find this amusing considering that the JSON community are slowly re-inventing XML with their versions of XSL, XSLT etc.

tkiolp4 5y ago
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.
leetrout 5y ago
True but i do see a general shift to "types are good" so there is a shift to "schemas are good" by extension IMO. The big thing is JSON has common basic building blocks (simple types) so you are unlikely to see the same class of interop problems like SOAP and friends had ... "oh look this defines a new type my Python soap / xml lib doesnt natively support" (happened to me a few times, most memorable was akamai soap api using a custom list-of-string type nothing in python would parse out of the box)
- radicalbyte 5y ago
  Types are good and XML/SOAP was a good idea. The vendor lock-in shenanigans were the problem.
pjmlp 5y ago
Just like the WASM folks are now re-inventing application servers.

tkiolp4 5y ago

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.

leetrout 5y ago

True but i do see a general shift to "types are good" so there is a shift to "schemas are good" by extension IMO. The big thing is JSON has common basic building blocks (simple types) so you are unlikely to see the same class of interop problems like SOAP and friends had ... "oh look this defines a new type my Python soap / xml lib doesnt natively support" (happened to me a few times, most memorable was akamai soap api using a custom list-of-string type nothing in python would parse out of the box)

radicalbyte 5y ago
Types are good and XML/SOAP was a good idea. The vendor lock-in shenanigans were the problem.

pjmlp 5y ago

Just like the WASM folks are now re-inventing application servers.