I have added more informations on: https://github.com/xwiki-contrib/less-vs-sass-benchmark
Guillaume 2014-04-28 16:48 GMT+02:00 Guillaume "Louis-Marie" Delhumeau < [email protected]>: > 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
