On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <[email protected]> wrote:
> 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).
No they don't, the only working implementation of less is in js for example.
>
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
