Aria Templates Forums
Compiler instructions to generate browser specific code. - Printable Version

+- Aria Templates Forums (
+-- Forum: Public forums (/forumdisplay.php?fid=3)
+--- Forum: Specifications (/forumdisplay.php?fid=13)
+--- Thread: Compiler instructions to generate browser specific code. (/showthread.php?tid=34)

Compiler instructions to generate browser specific code. - smadapathi - 31 July 2013 10:40

1. Requirements
There are two parts for this change request:
  1. The first part is to implement an atpackager visitor which converts aria templates files to browser specific code removing the unnecessary code which is not used by specific browser. This should generate multiple AT code specific to a browser.
  2. The second part is to implement the javascript code which will be loaded first and depending on the browser, AT code will be provided to the browser

2.Technical Solution

This specification is for the first part of requirements. We need to implement a visitor which tranforms the javascript files to browser specific code.The browser is provided as an input to the config object as below.

var ATBrowserSpecificCode= function (cfg) {
    cfg = cfg || {};
    cfg.files = cfg.files || ['**/*.js'];
    cfg.broswer = cfg.browser || "";
    this.config = cfg;

The transfomation of javascript file to browser specific code can be done by using TreeTransformer of UglifyJS as below

new UglifyJS.TreeTransformer(null, function(node){
   if(node instanceof AST_If){
   //logic for removing the code which is not necessary for a browser

It is to be noted that we need to handle the following scenarios if we are expecting IE7 specific code. Similarly we need to check for the other browsers too.


31/07/2013 Creation of the Specification.

RE: Compiler instructions to generate browser specific code. - flongo - 1 August 2013 14:12

I have a couple of comments on these specifications:
  1. I think that many usecases have to be taken into account for the generation of browser-specific code. For example, consider class aria.utils.History. Inside of it, there is a lot of browser-specific code, but the detection is not based explicitly on the user agent, but on feature detection (in this case, the choice is also due to the fact that the detection is done before calling the Aria.classDefinition method, so that no assumption on the presence of class aria.core.Browser can be done).
  2. In my opinion, we should have a more generic visitor that is able to cut code paths depending on a list of conditions, or even on a boolean expression. For example:

    cfg = {
        files : ["**/*.js"],
        condition : "browser.isIE7 || aria.core.browser.isIE7 || _isIE7OrLess || !html5History"

    The condition could be also parsed with uglifyJS.
    This would also allow, for example, to use the same visitor to remove the code that we use in debug mode:

    cfg = {
        files : ["**/*.js"],
        condition : "!Aria.debug"

    I don't how feasible it is, but it would be very interesting to have this feature.

RE: Compiler instructions to generate browser specific code. - benoit.charbonnier - 2 August 2013 08:45

I never followed any discussions about this feature, but i clearly don't get the point related to what we want to achieved....

First I think that browser specific computations are far more complex than that.

Second, we need to be aware that it is going to (again) increase the size of the code in terms of number of files, kilobytes, ... that the user will have to deploy to it's server, and to my humble opinion, we already are today too big in terms of size, number of files .. when we compare with all other libraries where you just need 1 or 2 files...

The ratio gain vs time invested in that direction is clearly not worth it for me !

RE: Compiler instructions to generate browser specific code. - Marc Laval - 2 August 2013 09:54

This US is a first step where the aim is to be able to build a lighter version of the framework by removing useless code for a particular application.
IE7 specific code is a good example as it is not needed by many existing projects, mainly the mobile ones.

For the technical approach, I agree with what Francesco propose.
Let's do a POC to see if it is doable and what can be gained with that.
Then, we'll see if we can go for a more advanced solution (e.g. tagging some blocks of the source code with comments).

For sure, as pointed by Benoit, it shouldn't impact te size of the framework for applications which do not use this feature!

RE: Compiler instructions to generate browser specific code. - smadapathi - 6 August 2013 07:39

I would like to suggest cfg to be more generic as follows
cfg = {
files : ["**/*.js"],
condition : "browser.isIE7 || aria.core.browser.isIE7 || _isIE7OrLess",
hasNoMethods:["addEventListener", "html5History"],
allBrowsersExceptIfCondition:["browser.isFF", "browser.isChrome", "browser.isSafari"]
Let me know what do you think of this?

RE: Compiler instructions to generate browser specific code. - fabio.crisci - 6 August 2013 10:52

I'm more for tags in the code.

Browser specific code that can be magically detected is a tiny fraction of the code, probably only few lines of code.

And honestly I believe tagging is simpler than automatic detection.

More than browser specific code we should talk about profile specific code.

Some profiles:

* Aplications that need to support IE7 and will never use any touch specific feature (don't want to make names). You can get rid of delegated gestures from `Delegate`.
* Mobile (only) applications, which don't need any IE stuff, XHR, File transport and probably NavigationManager (at least the part that deals with keymap)
* Production code, in production you might not be interested in certain logs (remove all calls to $logWarn, $logInfo, $logDebug), you don't want the Aria.memcheckMode (~100 LoC in Aria.js), you might want to disable checking the correctness of classpaths (other ~100 LoC), you might want to avoid completely IOFilters (thus removing some code in IO)
* You might as well opt out from some features that are time consuming and active by default, like VisualFocus (to support it, the delegate raises the events elementFocused and elementBlurred every time something gets focused /blurred), FlowControllers (~50 LoC in ModuleCtrlFactory), liquid layout (and Layout class which is mostly used for handling page resizing)
* There are also advanced features that might be disabled like customization, localization, macro libraries, css templates

Consider also that in the maven build we used to have two profiles

* Profiling, for performances analysis
* Backward compatibility, to remove any non backward compatible code

RE: Compiler instructions to generate browser specific code. - Marc Laval - 7 November 2013 14:13

I tried the automatic detection way by adding a new visitor which does some cleaning.
With it, the full minified framework goes from 1721.4kB to 1718.0kB ...
So clearly more advanced work would be needed, but I'm not even sure it is worth the effort.

For more details, the code is available in a branch in my fork:

RE: Compiler instructions to generate browser specific code. - jakub-g - 11 November 2013 13:41

I think we may gain a bit more with the more aggressive minification like I've suggested some time ago:
1) removing all $logWarn / $logError calls the error message strings altogether (though this would require some effort to identify the string in $statics which are error messages and the ones which are needed in the UI - perhaps establishing some naming convention would be useful),
2) making somehow UglifyJS shorten the names of private / protected methods (i.e. the ones starting with _) if at all possible

Prerequisite to this would be running the Attester over minified files instead of src (which Fabio tried to make in but there were some edge cases I've found and didn't manage to fix yet).

I think in 1) we may gain quite a significant bit - since the unique strings are gzipping poorly, in 2) perhaps not that much, and mostly just in minified code, but in Gzipped the difference could be even smaller. Also making 2) assumes that class Foo doesn't use private methods of class Bar, and I'm not sure if this contract is in place everywhere Wink

Regarding Fabio's post, it would be great to have several profiles. If we want to go mad, we may create some kind of custom build generator like (not providing every possible build ourselves naturally).

However I'm afraid this would add a lot of complexity and would add a big potential for PTRs on our side... (release testing all the possible combinations on IE7 anyone?)

Since we're discussing things... I somehow feel in the air that the usage of flow controllers and liquid layout is generally discouraged, but no one has the courage to write it down officially Smile So the new AT users don't know that unless they explicitly ask. Maybe we should deprecate those features? (not saying about removal right now, they will probably be needed forever in SECO, but let's say honestly, in the world of HTML5/CSS liquid layout is hell complicated and error-prone, at least that was my last experience with it).