On the perfs: - See also http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-recompilation-performance/ - And about Nashorn (JDK8+): http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the first 2 passes. - Now, regarding your figures, are they averages or the whole time for 100 recompilations?
Thanks -Vincent On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote: > Hi guys. > > Since we did not have made a strong analysis on SASS, I have played a bit > with it to compare. > > Thomas had the intuition that it should perform faster, because JRuby is a > better implementation for Ruby than Rhino is for JS. > > So I have published a little benchmark about them, that you can see there: > https://github.com/xwiki-contrib/less-vs-sass-benchmark > > The benchmark is about the time that it takes to compile Bootstrap. > > The results are very clear, SASS perform 2 times faster than LESS. > > Since it seems easy to switch from LESS to SASS (bootstrap had written a > converter), maybe we should consider this option. > > Other thing: > I would like to run Velocity on the sources of my CSS, in order to easily > integrate the color theme variables. But it is risky to run velocity on the > whole tree of bootstrap sources (just imagine that bootstrap has an "#if" > ID...). > > So Thomas and I suggest that we can run Velocity on files suffixed by > .scss.vm or .less.vm, to only run velocity on some files (for example: > color-theme.less.vm) that we handle. > > WDYT? > > Thanks, > Guillaume > > > 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" Delhumeau < > [email protected]>: > > > Hello. > > > > In 6.0, we have released a first version of Flamingo. It uses Bootstrap > > and the LESS preprocessor during the build to create the final style.css > > file. > > > > But currently, there is a serious regression compared to Colibri: it does > > not support color themes. > > > > So I have started a proposal about the color theme handling in Flamingo, > > that you can see there: > > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo > > > > My conclusion is that we need to integrate the LESS preprocesor on the > > runtime. This way, we can add velocity variables (corresponding to the > > color theme) in our LESS sources BEFORE the LESS preprocessor is launched. > > Doing the opposite, (process velocity after LESS) causes some problems that > > I have reported on the previous link. > > > > To me, it would be a good step ahead for proposing LESS to our users. > > > > Regarding this, some ideas are coming to me: > > - it is quite easy to integrate LESS since we can use Rhino to launch the > > LESS preprocessor (which is a javascript program). See: > > https://github.com/sandroboehme/lesscss-java > > - we need a cache system in order to not always compute the style.css > > served to the user (performances issue). > > - we need to add this in the "skin" action. > > - in the future, we also need to modify the skinx actions, to enable it > > for Skin Extensions. > > > > We also need to agree on the use of LESS instead of SASS. I have used LESS > > on Flamingo because Bootstrap has originally been written with it (although > > an official SASS port exists), so this choice is not based on a strong > > analysis. Anyway, it looks quite simple to move from one to the other and > > it is probably too soon to predict which of these 2 preprocessors will win > > on the long term. > > > > Do you think I am going in the right direction? > > > > Thanks for reading, > > Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
