12 May
2014
12 May
'14
5:50 p.m.
Just some arguments to take under consideration:
- do we want to add the bootstrap mixins and CSS preprocessors features in
the SSX objects? If so, then having a CSS preprocessor that caches the
bootstrap sources seems good.
- with SASS, it is easy to add a path where to find the includes. With
LESS, it does not work with the Rhino version (it uses some stuff related
to NodeJS). Even by modifying a bit the LessC source file, I haven't
managed to make it work.
I also prefer the LESS syntax + the fact that it is the default syntax of
Bootstrap, but technically, I find more and more reasons to prefer SASS...
---
We need to make a decision now, we should not wait anymore.
LESS pros:
- Syntax closer to CSS
- Syntax not to much similar to Velocity
- the Boostrap's choice
- Very popular
- Caty, Denis and I like it!
LESS cons:
- The java part uses Rhino and is less customizable
- No cache system
- include-path does not work with the java version so how could we handle
the @import command?
SASS pros:
- Good extensibility using JRuby
- Include-path works well
- Cache system so we can import Bootstrap mixin's in our SSX with better
performances
SASS cons:
- Syntax closer to Velocity
Guillaume
2014-05-06 10:02 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
My personal opinion about LESS vs. Saas is that I
prefer LESS,
both from a syntax non-similarity point of view,
but also because it's more close to the original CSS specifications and
thus they are more likely to keep things separate/simpler (separation of
concern of presentation vs. control structures that add complexity and that
can be achieved by a dedicated language).
But this preference is more of a hunch than an experimented study, so we
can further analyze the performance and other aspects in order to get a
conclusion.
Thanks,
Caty
On Mon, May 5, 2014 at 11:53 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
when
objects
2,480,000
for
not
http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom…
should
wrote:
it
run
handling
to
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi devs,
I am jumping in late on this debate, so do not baffle me if I have missed
something. IMO the performance should not be a priority criteria.
Performance could always be improved over time, and may vary in any
implementation to became better but also worse. So, our decision should
be
more based on proposed features, our perception
of the popularity and
community, and also our taste, even if this could be subjective.
Like Cathy, I am very concerned by the similarity of SASS and Velocity,
and
I see this as a misfeature of SASS for us. On an
technical point of view,
SASS seems more robust and complete than LESS, but is also a bit more
complex and less easy to adopt. Even if not really relevant here, I like
the idea that LESS could work client side thanks to its javascript based
implementation.
Bootstrap is initially made with LESS (which probably boost the
popularity
of it) and since we choose Bootstrap, it seems
also quite natural to
prefer
LESS like they do (I would have said just the
opposite if we had opted to
adopt, lets say, Compass, which is a framework based on SASS).
My perception of the community of both is quite the same, there is not
that
much contribution to any of them, since both are
mainly driven by one or
two developers. LESS appears after SASS and have gained popularity,
enough
to be adopted by Bootstrap, does it looks like a
indication... this is
probably a bit misleading, but once again we choose Bootstrap.
Performance seems to reflect the same as my perception of the technical
aspect of these products. SASS is more mature and complete, and therefore
it has been a bit more optimized, but LESS is not that bad and will
surely
improve over time as well.
So, you have probably decoded my though from the above, I have the
feeling
that currently LESS fits better for us than SASS.
Maybe we will have to
adopt both in the end, but I would start with LESS.
This was just my personal thoughts, thanks for reading,
On Mon, May 5, 2014 at 5:44 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> 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' 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 so
cjd(a)cjdns.fr
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
:
> On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
> > 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 <
> 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
>
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 >
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 > 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:
>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 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 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 > >>>>>>>> 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, > > 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 > > 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 > 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 > 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
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>>>>>> 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
>
>
>
> --
> Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
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