Wednesday, October 12, 2011

what's so wrong with our JSON API?

Nothing, it is just old-fashioned way of data transformation support.


1. Why JSON is used in general?
It has been times when the only language to fill the data into UI for web 2.0 apps( dynamic HTML content ) was JavaScript.
And for UI developers was quite difficult to parse artificial data formats. Especially accounting that JS has not given any reasonable parsing capabilities.
So once some kind of parser appeared ( eval() function or embedding JSON as SCRIPT tag ) everybody have started to use it despite of security and speed impact.
Than JS libraries covered gaps by making parsing themselves. That approach eventually picked by browsers and now we have JSON parsing support in JavaScript natively in most of current browsers(still need JS wrapper for compatibility).
On server side data serialization into JSON became widely supported by many frameworks. Python is exception and does not have native implementation.

2. Why JSON used in my company?
I guess nobody was considering alternatives.

3. What other ways?
Directly populate the data to UI bypassing JavaScript.
At the moment it could be done either on server by many technologies: from DB queries which rendering HTML to complex portal frameworks. On client side only technology available is XSLT.
That approach does not requires(but still could be used from) JavaScript and uses XML as data carrier.

Now to the history of XML in browser.
Till the moment when IE introduced XML support in XHR, it was available only via ActiveX which was not available as cross-platform solution.
Fortunately XHR became accepted despite of microsoft-fobia. Next significant step was done 4 years ago when rest of browsers followed IE and made XSLT part of native implementation. The process of XSLT support is still not complete in WebKit, but has enough developed to be useful.

(I still wiping the tears on fate of HTC(HTML Component), and VML - another strong Web 2.0 APIs by IE.)

Browsers have done poor job on introducing DOM model but wiping out remaining XML API from it. As result nobody have even been thinking to treat DOM as XML and apply XML technologies(XPath, XSLT) there. Time has been changed, most of browsers have changed the pattern, XHTML exist for decade, but W3C still not made the move. It looks like they will follow standard de-facto later on.

Meanwhile in same way as JS libs have closed the gaps in DHTML design and eventually became native API and later W3C standard, XML/XSL libraries will lead the way.

Modern applications have ability to use XSLT in browser without need to wait until generic frameworks matured enough to became a streamline.
The advantages given by XSLT use definitely worth the effort. It has been proven on multiple large scale projects on back-end. Now it is time to shift to browser.

Happy coding!

2 comments:

  1. perhaps it would makes more sense if you had supported it with real data and references

    ReplyDelete
  2. Numbers speaking itself:
    http://xmlaspect.org/XmlVsJson/results.jsp

    XML if data saved as attributes is SMALLER of JSON. For IE9 JS-based rendering is 5 times slower of XSLT. Note that no XSLT optimization has been done and JS cut to bare minimum.

    ReplyDelete