Sunday, July 17, 2011

HTML structure-presentation-behavior and its programming

Original Wave: Thinking aloud on in-browser development languages and tools.

Thinking aloud on in-browser development languages and tools.

In the concept of 3-tiered HTML page design ( structure/HTML, presentation/CSS, behavior/JS ) none of tiers has given good enough OOP or aspect-OP capabilities I get used to. Could be any language be used on all tiers? Sure, yes.

JS is capable of all. Could not see much of positive sides besides of

sufficient to achieve the goal.

Weakly support of OOP.

lack of strict definitions and validation

Weak interaction with other tiers (css&html). Browser does not support sufficient native interfaces to be used by JS:

§Do you recall how and why getComputedStyle used? Browser does not give API for CSS parameters get and set. Even most popular layout computation routine get box dimentions needed quite CPU expencive work around.

§Structure/HTML dom tree also suffering of lack support on JS level. No transactional and detached/group operations. Each dom node operation accomplished by layout recalculation, while that should be explicit function to finalize series of dom changes.

CSS covers just own tier and almost none of others. IE behaviours do not count since absent in other browsers.

HTML tags. Interesting beast.

Has limited support on all tiers. Styles as inline attribute and result of HTML structure. Behavior as inline scripting and tags( reload meta, MARQUEE, animateTransform, etc. )

Obviously, nothing toward OOP or any serious modular development. IFrame or HTC do not count.


HTC need to be highlighted as BEST solution for HTML modularization on ALL page tiers(structure,layout,behavior). Sadly it did not became a standard even with effort to be part of W3C.


FLASH, Silverlight, Java are just proprietory plugins and have no support on all 3-tiers.


XSL till 2006 was not available in major browsers. Not the issue since.

Has no direct support for either of 3 tiers. But:

natively capable to use any natively supported languages. HTML as structure, behaviors as JS, layout as CSS

not to mention the mix of all 3 for efficiency.

there is no more need to separate tiers for either development or efficiency.

new higher level entities could be introduced on native level: themes, languages, etc. AspectRule (see XSL pipeline implementations ) is one of them.

no frameworks ( working on one)

no developers ( need HTML stack and XSLT in same hands )



Working on XslAspect, I found the need to define own language for "Aspect" rules. I.e. what(rule), where(in model) and when(environment) should be applied. The thing is that the rule should be functional on any point of delivery chain: back-end, before DOM loaded in browser, in run-time. From another side, it should have OOP and AOP capabilities. XSL has all needed, but for syntax makes me uncomfortable. So there is a dilemma: should be new(or some existing) XML-based language invented/used or use old-fasioned XSL for things it is not meant to be ( like methods definition ).


Since XslAspect uses XSL templates, they also need to be OOP capable. ( AOP has XSL nature anyway ). If that will be done, than invention of new things is not necessary. I guess. And even if some new features need to be added, there is still a way to alter XSL with own namespace or add the data into XSL code.


To make the OOP match, it would be wise to make basic OOP stuff defined in XSL terms:

o    deployment or source module (group of files). Not OOP stuff, but still needed

o    package/namespace ( to separate "classes" )

o    Type/Class

o    Object

o    Method

o    Parameters

o    return values

Than AOP things. But the join/attach points will define not just what and where the code should be applied but also the (server, browser, runtime) environment and model peaces.

At our disposal XSL has:

·         template mode.

·         template name.

·         template match filter. Which is good for model navigation.

In addition in XSL could be used:

o    XslAspect namespace to define own attributes on


§xsl:stylesheet as grouping tool

o    folder and file name convention

o    embedded xml with own namespace

In general, it would be better to use as much native XSL stuff as possible and as last resort - own namespace.


Procedural vs AOP.

Another problem - developer convenience in procedural programming. Aspect assumes applying of rules all instantly and on whole model.

Which is quite different than sequential step-by-step execution. While the efficiency of parallel execution in AOP is not under question, the order of operations and their encapsulation in XSL is not developer and data-driven dev-t friendly: rules applied to same data could be spread in modules and there is no dependency to make strict order. In XSL that dependency could be done on data level by RuleSet ( embedding XML with recurrently enclosed rules ). Usually rules are quite simple (do not confuse with implementation). That way 1st implementation of XslAspect has been done. Another name for such use data processing is pipelining. Result of XSL processing is the source data for further processing.


Is there native XSL way of strictly define the sequence and enclose-dependency?

Sure, there are few ways in addition to RuleSet. Question is, what is more convenient?

·         xsl:call-template with parameters. Parameters are calculated first. The parameter value could be the call to another template.

·         xsl:apply-template has ability to pass parameters. Unfortunately not cross-browser capable. (or it is in modern ones?)

·         Blend input with RuleSet and use complex filtering in xsl:apply-template making select on original data set AND on joint RuleSet.



Actually all methods in framework could be equal and transformed one into another during platform-targeted packaging. So no actual restrictions are in place, just developer's convenience. Speaking of which, lets compare 3 approaches:

·         RuleSet

<xa:AcpectRule aspectName="ScrollableTable" >

<xa:AcpectRule aspectName="SortableTable_UI" >

<xa:AcpectRule aspectName="SortableTable_DataSort" >

<xa:sort colNum="2" order="ascending" data-type="text" />

<xa:sort colNum="1" order="descending" data-type="text" />

<xa:AcpectRule aspectName="TestTable" />




·         xsl:call-template

It is definitely native XSL. Bulky at least.

<xsl:template name="AspectRule1">

<xsl:call-template name="ScrollableTable">

<xsl:with-param name="data" >

<xsl:call-template name="SortableTable_UI">

<xsl:with-param name="data">

<xsl:call-template name="SortableTable_DataSort">

<xsl:with-param name="data" select="."/>

<xsl:with-param name="Sort">

<xa:sort colNum="2" order="ascending" data-type="text" />

<xa:sort colNum="1" order="descending" data-type="text" />








·         xsl:apply-template. How to to make the match reference only to the select with 2 nodes(data & rule) and access data from both. It could be done by mode but it will exclude the use of mode for other purposes (like define the module). From another side why module name should differ from aspect rule name? Another problem is pipelining. To make it work apply-template should be called from parent.

<xsl:template mode="AspectRule1_asApply">

<xsl:variable name="d1">

<xsl:apply-templates select="." mode="AspectRule2_asApply"/>


<xsl:apply-templates select="$d1" mode="ScrollableTable" />


<xsl:template mode="AspectRule2_asApply">

<xsl:variable name="d1">

<xsl:apply-templates select=" . | $sort " mode="SortableTable_DataSort"/>


<xsl:apply-templates select="$d1" mode="SortableTable_UI" />





It is obvious to see that AspectRule is shorter and more readable. Note that in all implementation the result of previous processing used as an argument for following one. XSL 1.0 is strictly prohibiting that. But with some tricks and magic it could be worked around on all browsers.

The performance impact which you could see on additional data processing could be relocated to packaging routine, that way xsl:call-template will be generated and delivered to client instead of AspectRule.


In terms of native/interpreted languages the xsl:call-template is natively compiled and AspectRule is the interpreted scripting.


Sunday, July 10, 2011

JSON as fast alternative for XML is wrong

While going over Learn page ( the first page new bee will read ) on prototype site, I found the statement which leads to misdirect development community:
JSON is notably used by APIs all over the web and is a fast alternative to XML in Ajax requests

It would be nice to remove "fast" word since it brainwash populous without good reason.
I am not sure has anyone on site tried to compare JSON and XML against each other, but my conclusion was totally opposite.

On the chain web server - network - reader - browser rendering   the XML is a winner on ALL tiers.
Why? The answer on all is "native support". I.e. no interpreters involved, all compiled and multi-threaded, polished to perfect in memory and CPU use:

  • web server - back-end serialization could start from DB level. In most DB XML is one of native outputs. Than Object serialization. While on ALL platforms there are zillions of implementations, most platforms are supporting XML as embedded API. Java, .NET, PHP, name it.
    ANY popular enough "Middle" tier on server (the one which does the business and UI logic) has support for use the XML as data holder. 
  • Network. On network JS people are counting each byte. And JSON looks less polluted with unnecessary text. But hold, in production all content goes over gzip-ed stream. And surprize! XML actually has few bytes smaller footprint
  • Reader. Browser needs to parse data. XHR has XML support and EACH implementation uses native (C-based xml lib) code. As result it could process larger amount of data with smaller CPU and memory use. XML gives 100 times faster and 100 times larger data volume. That is right. JSON will die on 100K records, XML will hold 10 times more.
  • Browser rendering. What rendering API does support multy-threading and native code? JS+JSON? No way. Answer is XML+XSL. In addition to run-time (lazy) rendering of heavy UI it gives extra option: rendering before page is loaded. And with speed no JS could be compared to.
On development side "fast" usually mean many things.
For startup where people are working on all tiers, having same data format and API is quite development time saver. As mentioned, XML has support on all, JSON - on some platforms. Documentation and feature set for XML is way behind of what JSON could offer. From validation against schema to encoding.

For large projects communication between tiers has become more important. Cross-team development speed relies on strict data format and validation, performance on data transformation, same data/API on different platforms, etc. XML has it all. JSON - no.

Could you have JSON be applied in all or at least in half? No.

Analysis on why JSON has become so popular and advertised is out of scope of this review. Industry is not always going the rational ways.

Happy coding!