5 May
2014
5 May
'14
5:44 p.m.
Update:
SASS have good performances because it does not always compute all the
sources. All imported files (using @import) are cached and not recompiled
when there is not change on these files.
It is good if we often recompute flamingo (that does a lot of @import), but
it means that the SASS' performances are not that better than LESS' when it
comes to compile new files, which can happen every-time we will compile a
SSX object in the future (if we decide to).
So I have done a benchmark without the cache, and then the performances of
SASS are quite the same than LESS, but a bit slower (see:
https://github.com/xwiki-contrib/less-vs-sass-benchmark ).
Other thing to consider:
In both LESS and SASS, it is possible to set a directory where the imported
files are searched. So we can add bootstrap sources in every SSX objects so
that users can use Bootstrap mixins (good thing IMO).
In this case, it will be good to have the cache system that SASS has.
Thanks,
Guillaume
2014-04-30 15:17 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Apr 30, 2014 at 3:04 PM, Caleb James
DeLisle <cjd(a)cjdns.fr>
wrote:
>
>
> On 04/30/2014 02:59 PM, Thomas Mortagne wrote:
>> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle <cjd(a)cjdns.fr>
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.
>
>
> https://github.com/less/less.ruby
> https://github.com/marceloverdijk/lesscss-java <-- wrapper around the
js
impl w/ rhino
"working" was an important detail. Guillaume already tried
https://github.com/marceloverdijk/lesscss-java.
Actually I tough you were talking about another one, If you really
look at the detail you will see this one is using rhino so no it's not
a java implementation.
> https://github.com/BramvdKroef/clessc
>
>
>>
>>>
>>> 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…
>>>>
>>>>
>>>>
>>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com>gt;:
>>>>
>>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle <cjd(a)cjdns.fr>fr>:
>>>>>
>>>>>> 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) <
>>>>> valicac(a)gmail.com
>>>>>>> :
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>
gdelhumeau(a)xwiki.com> 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 <
>>>>>>>>> gdelhumeau(a)xwiki.com>gt;:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>> devs(a)xwiki.org
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> devs(a)xwiki.org
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> devs(a)xwiki.org
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> devs(a)xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs