tag:blogger.com,1999:blog-8146735945866635880.post4852980638552255316..comments2023-06-06T20:58:51.947-07:00Comments on Sasha Firsov: what's so wrong with our JSON API?Sasha Firsovhttp://www.blogger.com/profile/16451159675007318587noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-8146735945866635880.post-50042696253701594122012-05-06T23:51:17.723-07:002012-05-06T23:51:17.723-07:00Long ago when the web was young
Ten years ago XSLT...Long ago when the web was young<br />Ten 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />The right tool in the wrong context<br />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.<br /><br />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.<br /><br />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.<br /><br />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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8146735945866635880.post-10045098235796362412011-12-06T15:20:58.946-08:002011-12-06T15:20:58.946-08:00Numbers speaking itself:
http://xmlaspect.org/XmlV...Numbers speaking itself:<br />http://xmlaspect.org/XmlVsJson/results.jsp<br /><br />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.Sasha Firsovhttps://www.blogger.com/profile/16451159675007318587noreply@blogger.comtag:blogger.com,1999:blog-8146735945866635880.post-17164306684107752752011-10-13T01:48:04.995-07:002011-10-13T01:48:04.995-07:00perhaps it would makes more sense if you had suppo...perhaps it would makes more sense if you had supported it with real data and referencesAnonymousnoreply@blogger.com