It is only a matter of browsers getting native support for gRPC.
With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh.
It's a very specific technology, and as long as it can be implemented fairly efficiently 'up the stack' in JS, then it mostly belongs there. Aside from HTTP2 (which is a roadblock now, but not soon) it'll be fine in JS.
https://en.wikipedia.org/wiki/Billion_laughs_attack
It got me thinking about it. JSON is annoyingly simple at times, yes. But that also protects it from some pretty gnarly stuff seen in XML and YAML. I suspect it's a considerable contributor as to why it's the choice transport format.
I wouldn't toss it in with XML just yet.
Why do you think so? Jackson and Gson work very well. Serialising and deserialising from/to POJO/JSON is trivial with them.
In Java, you have to abstract the document and write a lot of code to access, add, remove things etc. - or - because there is no such thing as an untyped POJO in java, you have to set up a ton of things if you want to use real objects.
You could also use a POJO for the fields you know and put a map inside for the fields you don't know.
If that's not enough you can use JsonNode, or ObjectNode where you can freely add and remove json values.
Though Java was 'designed', it was not 'designed' to be an http/web server.
JS, particularly Node.js has really adapted itself to that well.
And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing.
As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a different comparison.
I quite like using Typescript on Node.js over Java - development speed is faster, and this is a really important thing.