On Mon, May 12, 2014 at 6:01 PM, [email protected] <[email protected]> wrote: > > > > > 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.
In the JDK but no the JRE and XWiki does not require 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
