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
