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!
Subscribe to:
Post Comments (Atom)
perhaps it would makes more sense if you had supported it with real data and references
ReplyDeleteNumbers speaking itself:
ReplyDeletehttp://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.
Long ago when the web was young
ReplyDeleteTen years ago XSLT was a respectable choice for building web interfaces. Data was increasingly represented in XML documents, browsers were rendering interfaces based on XHTML so it made sense to use XSLT to provide the means for transforming data into a UI.
It carried a number of advantages over the tools being offered by Microsoft, particularly to developers who wanted full control over the mark-up that was being generated. XSLT is platform agnostic, offered easier unit testing, supported MVC-based patterns and could be used to deliver better quality, standards-compliant mark-up.
This led to a proliferation of systems that handed the interface processing to XSLT templates. It offered a certain architectural simplicity and saved you from having to write a load of server-side code for every page. A number of web CMS platforms adopted it as a template building tool, particularly those that relied on XML-based content repositories.
However, XSLT has a number of drawbacks that make it difficult to work with over the long term. Anybody who has laboured on a system that is drowning in multiple XSLT templates that are impossible to debug will tell you – it’s not a terribly elegant UI tool.
The right tool in the wrong context
XSLT is the classic example of a technology solution that makes every problem look like a nail. It is a great tool for tweaking XML data from one format into another. However, it lacks the complex program flow constructs that you need to deliver modern interface logic. It just is not expressive enough to handle today’s more engaging and complex interfaces.
Websites are evolving and their taxonomies are more fluid than the strict, hierarchical sites of ten years ago. Web site developers have to manage a lot more complexity than was the case ten years ago. Pages have become more complex and featuring more content and interactive functionality. It becomes ever more difficult to render this kind of content using something as limited as XSLT.
If you work with .NET it’s also important to realise which way the train is moving. Microsoft have never been great supporters of XSLT and this is shown in their reluctance to support XSLT 2.0. However, they have developed superior interface building tools that address many of the issues that were used to justify using XSLT such as testability and standards compliance.
Ten years ago you could be excused for balking at using embryonic web forms along with the poor mark-up they produced and their design shortcomings. However, the options available in .NET 4.0 make the batch-based processing of XSLT look pretty last century.