Compiler instructions to generate browser specific code. - Printable Version
+- Aria Templates Forums (http://ariatemplates.com/forum)
+-- 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 12:40
There are two parts for this change request:
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.
RE: Compiler instructions to generate browser specific code. - flongo - 1 August 2013 16:12
I have a couple of comments on these specifications:
RE: Compiler instructions to generate browser specific code. - benoit.charbonnier - 2 August 2013 10: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 11: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 09:39
I would like to suggest cfg to be more generic as follows
RE: Compiler instructions to generate browser specific code. - fabio.crisci - 6 August 2013 12: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.
* 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 16: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 15: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 https://github.com/ariatemplates/ariatemplates/pull/668 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
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 http://modernizr.com/download/ (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 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).