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 <[email protected]> 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 <[email protected]>: > > > > > On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne > > > <[email protected]> wrote: > > > > On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle <[email protected]> > > > 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 <[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 > > > >>> > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> 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
