My major concern about Sass is the syntax very similar to Velocity and the way we will handle the parsable style sheets.
Thanks, Caty On Mon, Apr 28, 2014 at 5:21 PM, Guillaume "Louis-Marie" Delhumeau < [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
