28 Apr
2014
28 Apr
'14
4:48 p.m.
Thanks,
2014-04-28 16:44 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
On the perfs:
- See also
http://brizzled.clapper.org/blog/2012/12/12/play-framework-less-vs-sass-rec…
- And about Nashorn (JDK8+):
http://houbie.blogspot.fr/2013/06/javascript-on-jvm-experimenting-with.html Seems
it doesn’t help over rhino, but maybe it’s better in Java8 final. Look at
Rhino (optimized), it takes about 1 to 1.5s to compile bootstrap after the
first 2 passes.
- Now, regarding your figures, are they averages or the whole time for 100
recompilations?
It's the whole time for 100 recompilations.
Thanks
-Vincent
On 28 Apr 2014 at 16:22:08, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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 <
gdelhumeau(a)xwiki.com>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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs