Hacker News Reader

Comment by radicalbyte | Hacker News Reader

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

View on HN

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)

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

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

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).

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.

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/

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!

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?

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.

Reply on news.ycombinator.com