[xwiki-devs] Future of Flamingo, Bootstrap and Less in XWiki
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-... :) 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. Thanks, [1]: http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo#HImple... [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]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
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-... :)
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#HImple... [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])
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. Thanks, On Thu, Sep 17, 2015 at 8:01 PM, [email protected] <[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-...
:)
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#HImple...
[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
-- Denis Gervalle SOFTEC sa - CEO
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-...
:)
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#HImple...
[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])
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-...
:)
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#HImple...
[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
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-...
:)
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#HImple...
[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
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-...
:)
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#HImple...
[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
Hi all and thanks for your feedbacks. I fully agree on the fact that having multiple css preprocessors is a good thing. I didn't want to propose to replace LESS by SASS (except for the writing of the new skin) and I think we could have both. The only thing that would not work anymore, is the ability to use the bootstrap functions in a SSX object using LESS. It's obvious since Bootstrap is not written with less anymore, but in my opinion, it was the main strength of our solution. Also, every extension that was using bootstrap features in a SSX would be broken. Regarding the tweet that Vincent have posted, I think it shows how superficial is the consideration for retro-compatibility in the bootstrap's team. They haven't switched to Sass because Sass is better or Less is not sufficient for they needs, but just because they wanted to change! So now, every projects that want to upgrade have to rewrite everything in Sass, and the next time, it will be PostCSS! Since we love creating software for the long-term, it's a very bad point. Guillaume
participants (5)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
vincent＠massol.net