To be fair, I have upgraded SASS to the last version too: https://github.com/xwiki-contrib/less-vs-sass-benchmark
The results are still quite the same. Thanks, Guillaume 2014-04-29 11:01 GMT+02:00 Guillaume "Louis-Marie" Delhumeau < [email protected]>: > For your informations, I have updated > https://github.com/xwiki-contrib/less-vs-sass-benchmark with a new > implementation of LESS (Asual LESS) which is ever worse! > > I have also upgraded LESS to the last version and it is a bit better from > the performances side. > > Thanks, > Guillaume > > > 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <[email protected]>: > > My 2 cents worth is all that matters is community. >> Between Groovy, Velocity (I think we're now the biggest user of that) and >> prototypejs, we're pretty good at backing the wrong horse. >> >> In 3-5 years, one of LESS/SASS (or perhaps something else entirely) will >> be >> the standard for CSS preprocessing and the other will be a historical >> amusement. >> Lets not be the ones left holding the bag. >> >> Thanks, >> Caleb >> >> >> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" Delhumeau wrote: >> > 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) <[email protected] >> >: >> > >> >> My major concern about Sass is the syntax very similar to Velocity and >> the >> >> way we will handle the parsable style sheets. >> >> >> > >> > I think you talk about the fact that variables are prefixed with $ in >> SASS. >> > >> > 2 solutions: >> > - it should be possible to escape the $ when velocity should ignore the >> > variable >> > - when the variable does not exist in the velocity context, it displays >> > $variable and it does not fail. >> > >> > I personally prefer LESS for the reason for this reason, but regarding >> the >> > performances, we might consider the things differently, even with a >> cache >> > system (which will be needed anyway). >> > >> > I need more opinions about this. >> > >> > Thanks, >> > Guillaume >> > >> > >> >> >> >> 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 >> >> >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
