https://encrypted.google.com/search?q=less+css -> About 116,000,000 results (less is a common word so this is skewed) https://encrypted.google.com/search?q=sass+css -> About 2,480,000 results
https://github.com/less/less.js -> 1756 commits, 152 contributors, 2296 forks https://github.com/nex3/sass -> 5554 commits, 135 contributors, 650 forks Less feels a bit safer from a community standpoint, both have java/C/ruby/js implementations (node-sass is a binding to the C version). These numbers seem to be suggesting that consensus will form around Less if anything. Thanks, Caleb On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau wrote: > One point in favour of SASS (SCSS): it seems more customizable. For > example, we can define our own SASS functions (like > xwiki-colortheme-get('variable_name')) or our own Importer (for example, > @import will not look in the filesystem but somewhere in our XWiki > instance). > > In this case, we can simply avoid using velocity. > > See: > http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions > > > > 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <[email protected]>: > >> 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. >>> >>> >> That may be right but as of now at least, groovy/velocity are popular at >> least among xwiki current users (dev oriented ones). >> I'm really glad personally that you didn't choose PHP or JSPs even if they >> were (and are) far more popular than Velocity ... ;) >> >> >>> 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. >>> >> >> Maybe CSS preprocessing as we know now, will be a historical amusement. >> It's still very very young. To me it mostly looks like hacks added to >> workaround things that pure css SHOULD manage ideally, or should not have >> to manage at all... Not saying that css preprocessing is bad though of >> course :) >> The problem is that the "best" and the "most popular" are not always the >> same ... (to say the least) >> >> 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 >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
