Comment by murukesh_s

16 hours ago

Sometimes I wish we could have kept XML alive alongside JSON.. I miss the comments, CDATA etc, especially when you have to serialize complex state. I know there are alternatives to JSON like YAML but I felt XML was better than YAML. We adopted JSON for its simplicity but tried to retrofit schema and other things that made XML complex. Like we kind of reinvented JSON Schema, and ended up like what XSD did decades ago and still lacking a good alternative to XSLT..

The XSL:T equivalent for JSON is React.

Let's not romanticize XML. I wrote a whole app that used XSL:T about 25 years ago (it was a military contract and for some reason that required the use of an XML database, don't ask me). Yes it had some advantages over JSON but XSL:T was a total pain to work with at scale. It's a functional language, so you have to get into that mindset first. Then it's actually multiple functional languages composed together, so you have to learn XPath too, which is only a bit more friendly than regular expressions. The language is dominated by hacks working around the fact that it uses XML as its syntax. And there are (were?) no useful debuggers or other tooling. IIRC you didn't even have any equivalent of printf debugging. If you screwed up in some way you just got the wrong output.

Compared to that React is much better. The syntax is much cleaner and more appropriate, you can mix imperative and FP, you have proper debugging and profiling tools, and it supports incremental re-transform so it's actually useful for an interactive UI whereas XSL:T never was so you needed JS anyway.

I just had to explain to some newbies that SOAP is a protocol with rigid rules; REST is an architectural style with flexibility. The latter means that you have to work and document really well and consumers of the API need tools like Postman etc. to be even able to use the API. With SOAP, you get most of that for free.