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