Sunday, January 30, 2011

SCC freeze, Precompiled Static CSS vs. Dynamic

Insulation of simple CSS rules as substitution for global scope will produce fast and reliable code, remove the danger of breaking complex Web 2.0 app UI and behavior outside of module/widget.
How to achieve that using SCC freeze and  Precompiled Static CSS you could read on my Precompiled Static CSS vs. Dynamic wave:

    Precompiled Static CSS vs. Dynamic
    Part of Designing better Web Stack and Browser initiative.
    CSS as selector and style/behavior had served relatively good job on
    1. Static HTML: abstraction and insulation of style from document structure (link-s)
    2. Dynamic HTML: operations on page delegated to native brouser layer as in opposite to JS-driven styling.( like CSS group visibility switch )

    But as complexity of web apps where growing and volume of CSS sometime overwhelming the HTML both targets were working against each other. Once the static part was exercised there is no need for CSS rules unless they are involved in dynamic HTML behavior.
    Lifecycle control over different types of CSS rules allows significantly accelerate the dynamic HTML changes.
    Imagine the stages of each HTML widget and page overall:
    1. Loaded
    2. CSS rules applied
    3. DOM adjusted
    Those operations could be dedicated as external transaction and done way ahead of implementing on the page. During the prepackaging/widget compiling. If the packager is aware of complete context, HTML could be premade. Obviously DOM events(if any) for such operations need to be chained and fired in appropriate order. But after the widget content is rendered.
    Systems utilizing those principles exist: IceFases doing that on server side, XSLT does it for inline styling and so on.

    When it comes to real life app, the following could improve the CSS-related performance:
    For the selected theme(set of CSS rules applied across whole app ) the widgets HTML to be extracted from rendered page and placed into most efficient for library format as a template. In best case it would be XML with all package resources, in worst JS strings map.

    The preference of general XML over JS(link) is a separate subject but in this case we are talking about JS string hash map versus XML (not string, but native object) in
    a) load and
    b) conversion to HTML.
    It goes to
    • memory allocation heap(native XML vs. JS VM),
    • load speed ( native XML object vs JS parsing - JSON parser usually is not compatible with JS framework packager ),
    • selector speed ( precompiled XPath vs. JS hash map) and so on.
    All of above is not in favor of JS, especially in embedded browser conditions

    Such HTML template for widget will consist of computed styles with default ones extracted. There is good amount of optimization could be done here, but important that there is a 1. original CSS + HTML class code and 2) complete set of applied computed styles. Which is quite handy during troubleshooting.

    If you have a luxury of generating target browser specific JS, performance and reliability will be even better.

    ... find more on original WAVE