There are other considerations that are not approached by this post: community and tooling. I am not experienced with Flow, but TS (though I like it) can be a huge hindrance to adopting libraries. Sometimes, the libraries won't have types (which makes TS refuse to use them). Sometimes they will have types, but wrong types, or half-written types that are not compatible with other libraries defining slightly different types for the same library. From what I understand, Flow is architecturally more lenient with this.

as @JanVladimirMostert says, XML is more descriptive. If you need annotated data, XML is more practical (ex: list of movies with cast). Similarly, if you need highly nomenclature-d data, XML is better (e.g, defining node types and what they can or can't have as properties is easier in a DTD). If size is an issue, or if you want higher compatibility (XML parsers can differ, JSON parsers not so much), go for JSON. So in summary I'd agree with the senior architects of your company that it is "better as a data interchange format", in the strict sense that XML conveys more meaning than JSON (after all the whole purpose of the -ML family was to semantically annotate data). As for which is better in a vacuum, it's a bit of a meaningless point. You could also go with URL-encoded strings, or your own custom format. If, say, the data you need to send is "user logged in" or "user logged out", you could go with an 8-bit identifier with a 1 bit flag. It all depends on the purpose of whatever data you're exchanging. I'd say in the end it's about convenience. I haven't used XML in years because I have no particular use for it, and since I'm basked in JS most of my day,. Json is one JSON.parse() away. If I was using a framework with XML baked-in or part of the stdlib, I'd use XML instead.

I have long experience in both branding and photo retouching (+15 years) as well as websites design (+10 years). I've opened my own studio and used the Adobe suit extensively. Five years ago, I dropped all the Adobe stuff to rely exclusively on open-source software on a Linux box. Works like a charm, as long as I don't need co-workers to intervene on the files (getting people to switch from their beloved Photoshop is hard). Even then, it's possible, just a bit cumbersome. I use: Gimp (photo retouching): ugly as sin, but functional Krita (photo retouching, drawing): great MyPaint (freehand drawing): closest to paper drawing I've ever seen Inkscape (vectors, layout, icons, logos): A bit cumbersome at first sight, but ends up being immensely more powerful than Illustrator once you become efficient with it Blender (3D modelling & animating, Video editing, FX): Blows any other 3D package I've used out of the water (and I used to be a 3DSmax then Maya fanatic) To answer your question more directly: To design a UI, I'd use Inkscape for a quick sketch, then implement it directly in the browser, where a responsive design can take place. If I don't want to code anything, the web provides a number of application (both free and subscription based) to design a web UI, a Google search for "design UI mockup online" will provide results. To design UI components, I'd use either Inkscape, if I need to export at different resolutions, or Gimp/Krita if I don't.

It doesn't have Facebook backing it It isn't as easily implementable in your app without changing a lot of things Examples look more complex at first sight. Doesn't have jsx (which is really more of an obfuscation than a helper, but hey, it really separates cleanly logic and display) It doesn't have Facebook backing it