On 12 May 2014 at 17:51:32, Guillaume Louis-Marie Delhumeau
([email protected](mailto:[email protected])) wrote:
> 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
- Requires JRuby which we shouldn’t provide by default ideally whereas Rhino is
bundled in the JDK.
Thanks
-Vincent
> Guillaume
>
>
>
> 2014-05-06 10:02 GMT+02:00 Ecaterina Moraru (Valica) :
>
> > 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 wrote:
> >
> > > 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 <
> > > [email protected]> 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'
> > 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 > > >:
> > > >
> > > > > On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne
> > > > > wrote:
> > > > > > On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle > > >
> > > > > wrote:
> > > > > >>
> > > > > >>
> > > > > >> On 04/30/2014 02:59 PM, Thomas Mortagne wrote:
> > > > > >>> 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.
> > > > > >>
> > > > > >>
> > > > > >> 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_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 :
> > > > > >>>>>>
> > > > > >>>>>>> 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
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >> _______________________________________________
> > > > > >> devs mailing list
> > > > > >> [email protected]
> > > > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thomas Mortagne
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas Mortagne
> > > > > _______________________________________________
> > > > > devs mailing list
> > > > > [email protected]
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > > _______________________________________________
> > > > devs mailing list
> > > > [email protected]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > >
> > >
> > > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > > _______________________________________________
> > > 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
