Re: [xwiki-devs] [Proposal] Integrate LESS css in XWiki

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

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,

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

of it) and since we choose Bootstrap, it seems also quite natural to

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

much contribution to any of them, since both are mainly driven by one or two developers. LESS appears after SASS and have gained popularity,

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

improve over time as well. So, you have probably decoded my though from the above, I have the

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&gt; wrote: > Update: > > SASS have good performances because it does not always compute all the > sources. All imported files (using @import) are cached and not

> 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

> 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 > 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 <

> > > 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;gt;: > > >>>>> > > >>>>>> 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

> > 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 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,

> > 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&gt; wrote: > > >>>>>>>>> > > >>>>>>>>>> Hi guys. > > >>>>>>>>>> > > >>>>>>>>>> Since we did not have made a strong analysis on SASS, I

> > 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

> 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

> > 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

> > 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;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: > > >>>>>>>>>>> > > >>>>>> > >

> > >>>>>>>>>>> > > >>>>>>>>>>> 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

> 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

> > >>>>>> 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

to > > enable > > >>>>>>> it > > >>>>>>>>>>> for Skin Extensions. > > >>>>>>>>>>> > > >>>>>>>>>>> We also need to agree on the use of LESS instead of

> > have > > >>>>>> used > > >>>>>>>>>> LESS > > >>>>>>>>>>> on Flamingo because Bootstrap has originally been written > with > > it > > >>>>>>>>>> (although > > >>>>>>>>>>> an official SASS port exists), so this choice is not

> on a > > >>>>>> strong > > >>>>>>>>>>> analysis. Anyway, it looks quite simple to move from one

> 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 > > > > > > > > > > > > -- > > > 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 > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs