Yeah, hoping to end up with one all-mighty solution is probably a not a healthy objective in this ever changing world of web development frameworks.
For JavaScript I believe we`ve made quite a good choice in integrating with RequireJS so that we can easily integrate whatever JS framework/library we need, on a per-page/per-applicatin basis. On the CSS side, I believe we are also on the right track with the introduction of the content type option in a SSX object, we just need to build upon that and allow extensions to push new content types there that get to be parsed with the right preprocessor (that is also provided by an extension). One of the lessons I`m confirming more and more in Software Development is that making choices for your users most often ends up badly and, what you really should do is to give options (on top of best effort defaults, of course) :) Sure, we can decide to use jQuery and/or LESS in (some of) our standard applications, but it should be trivial for other people or even for us to use some other collection of web development frameworks in XWiki. I believe that, if possible, that`s what we should strive for. Thanks, Eduard On Fri, Sep 18, 2015 at 3:04 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > Also remember that we didn't pick Sass because of some overlapping with > Velocity syntax. > > Thanks, > Caty > > On Fri, Sep 18, 2015 at 3:02 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > > > I don't know the amount of work needed, but it would be interesting to be > > able to support multiple preprocessors. Flamingo could remain on > BS3+Less, > > but we could create a new skin on BS4. > > Regarding Sass, this is personal, but I'd prefer to jump directly to > > PostCSS, than to go through a Sass skin version. > > > > Thanks, > > Caty > > > > On Fri, Sep 18, 2015 at 1:15 PM, [email protected] <[email protected]> > > wrote: > > > >> Hi Denis, > >> > >> On 18 Sep 2015 at 12:11:12, Denis Gervalle ([email protected](mailto: > >> [email protected])) wrote: > >> > >> > Hi Guillaume, > >> > > >> > I would be in favor to add SASS and not replace Less with SASS if > >> possible. > >> > Since the next one PostCSS is based on standard CSS, we would have > >> multiple > >> > possibilities PostCSS, LESS+PostCSS or SASS+PostCSS. > >> > Basically it means supporting one extended CSS language processor > >> followed > >> > by one or more standard CSS processors. > >> > > >> > Do you think that you could make your code generic enough to support > >> both > >> > SASS and LESS, and be prepare to append PostCSS to the overall > process ? > >> > Having this flexibility will allow backward compatibility and be open > to > >> > the future. > >> > I am not sure waiting is the way to go, we basically need more > >> flexibility. > >> > If you wait for something stable you risk to wait for ever. > >> > >> If you’re referring to my comment then you misread me :) > >> > >> I’ve never said to wait for something stable… I’ve said to wait for > >> people to provide converters between processors and specifically to make > >> Bootstrap work with more than just SASS. > >> > >> But overall you’re saying exactly what I was thinking (support several > >> options) which is good since it means we agree :) > >> > >> Thanks > >> -Vincent > >> > >> > Thanks, > >> > > >> > > >> > On Thu, Sep 17, 2015 at 8:01 PM, [email protected] > >> > wrote: > >> > > >> > > Hi Guillaume, > >> > > > >> > > On 17 Sep 2015 at 18:59:22, Guillaume Louis-Marie Delhumeau ( > >> > > [email protected](mailto:[email protected])) wrote: > >> > > > >> > > > Hello everyone. > >> > > > > >> > > > The front-end world is evolving really fast, and it's very hard to > >> pick > >> > > the > >> > > > good JavaScript framework, the good CSS preprocessor, or the good > >> CSS > >> > > > toolkit. It's so unpredictable that it has inspired a comic strip: > >> > > > > >> > > > >> > http://www.commitstrip.com/en/2015/09/16/how-to-choose-the-right-javascript-framework/ > >> > > > :) > >> > > > > >> > > > Last year, we have chosen to use Bootstrap for our new Flamingo > >> Skin. > >> > > > Quickly, I have discovered that we had to integrate a CSS > >> preprocessor to > >> > > > be able to customize it [1]. The natural choice was Less, since > >> Bootstrap > >> > > > and of lot themes of the web were using it. > >> > > > > >> > > > Now, the situation have changed. Bootstrap 4.0 will be released > >> soon [2]. > >> > > > It have been entirely rewritten and some retro-incompatibilities > >> have > >> > > been > >> > > > made. But the most breaking change is that they don't use Less > >> anymore, > >> > > but > >> > > > Sass. > >> > > > > >> > > > By the past, they use a less-to-sass converter so they were able > to > >> > > propose > >> > > > both versions of the framework. But now, I doubt the opposite > >> converter > >> > > > could be possible since Sass have more features than Less. > >> > > > > >> > > > Worse, it seems that Sass is becoming more popular than Less [3]. > >> > > > > >> > > > Note: the current Bootstrap version, 3.x, will be maintained > during > >> one > >> > > > year, so we have this time to adapt. > >> > > > > >> > > > If we want to upgrade to Bootstrap 4, we will need to integrate > the > >> Sass > >> > > > preprocessor. Fortunately, we can re-use a lot of the work that > >> I've done > >> > > > for Less (the cache mechanism, etc...) that I can modify to be > more > >> > > > generic. I don't have estimated the time it would take yet. > >> > > > > >> > > > If we want to upgrade Flamingo to Bootstrap 4, it will create some > >> css > >> > > > breakage (and the ability to use LESS in SSX will be loose). And > we > >> will > >> > > > have to convert our Less code to Sass. > >> > > > > >> > > > We could also decide to keep Bootstrap 3.x in Flamingo and use > >> Bootstrap > >> > > 4 > >> > > > for our next skin. > >> > > > >> > > Why couldn’t we use LESS in SSX since in the end it generates CSS? > >> > > > >> > > Note that even SASS may not last very long (see this fun tweet: > >> > > https://twitter.com/mdo/status/591364406816079873?lang=en). > >> > > > >> > > For example there’s postCSS now (and lots of others): > >> > > * https://twitter.com/jeremychone/status/636570198510735360 > >> > > * https://github.com/postcss/postcss > >> > > * "PostCSS can do the same work as preprocessors like Sass, Less, > and > >> > > Stylus. But PostCSS is modular, 3-30 times faster, and much more > >> powerful." > >> > > * Some slides: http://ai.github.io/about-postcss/en/ > >> > > > >> > > Our only real solution would be to be able to have XWiki work with > >> several > >> > > but I don’t know how hard it is to convert the bootstrap CSS files. > >> > > > >> > > See for example https://github.com/OEvgeny/bootstrap-postcss > >> > > > >> > > Since BS3 is pretty often used, I’m pretty sure people will develop > >> > > converters from LESS to SASS or others. > >> > > > >> > > So I think it’s important that we wait a bit :) We should research > the > >> > > topic though. > >> > > > >> > > Thanks > >> > > -Vincent > >> > > > >> > > > Thanks, > >> > > > > >> > > > [1]: > >> > > > > >> > > > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo#HImplementationusingLESSattheruntime28LESScompilercalledAFTERvelocityengine29 > >> > > > [2]: Bootstrap 4 announcement: > >> > > > http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/ > >> > > > [3]: The State of Front-End Tooling – 2015: > >> > > > > http://ashleynolan.co.uk/blog/frontend-tooling-survey-2015-results > >> > > > > >> > > > -- > >> > > > Guillaume Delhumeau ([email protected]) > >> > >> _______________________________________________ > >> 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
