AJAX: http transports

# AJAX and HTTP transports

Almost everybody who ever tried to make a web-frontend had used AJAX at least once in one way or another but what people call AJAX nowadays it's actually not an AJAX but rather AJAJ since X in it stands for XML, markup language that dominated in API available over HTTP before JSON became widespread and is still used widely in legacy projects.

In this section I would like to talk about data formats used for client-server interaction in JS, explain why XML is not the best choice nowadays and show some edge cases that may be quite useful.

JSON today is not just a data format but rather an industrial standard for web APIs, both internal and external. It is easy to read, even without deserializing, easy to use (the serializing/parsing methods are consistent between browsers) and the parser outputs native JS structures.

Sometimes, however, it may not be the best option. When you use dynamic components, good performance is a must and the HTML rendering library may be this very bottleneck that pushes potential user away. This is especially true if you take into account that most of people in the world have low speeds when on mobile and portable devices have been steadily stealing the share of views from desktops and laptops.

The fastest way to render data is to make server output HTML and then just use it on the client side. Usually I see people using two methods for accident this: iFrames and using `innerHTML`.

Using `innerHTML` seems like the best option because you can control the request all the way through and all that is left is to only set `innerHTML` to result but it is not safe because innerHTML is susceptible to XSS if you do not properly escape special characters in your responses. Same thing happens if you want to use the shadow iFrame for fast loading and rendering and move its contents to the actual DOM for faster rendering. This method, however, gives less control over response than the XHR or fetch call.

Using iFrame is a very old method for displaying dynamic content but it doesn't give you any control over requests: `iframe` doesn't support `error` event unlike `img` or `script` and even such a simple thing as error catching becomes [quite hacky](https://stackoverflow.com/a/19630646). Hence the second part of why using shadow iFrames is not that good of idea despite performance increase due to browser-native request and rendering.

Back in the early 2000's these security concerns lead to intention of AJAX