Thanks, 2014-04-28 16:44 GMT+02:00 [email protected] <[email protected]>:
> 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? > It's 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
