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) <[email protected]>: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
