Skin 10.x: Frameworks Support
Ecaterina Moraru (Valica)Description
Switching from Bootstrap 3 to Bootstrap 4
We are using the Bootstrap framework for our Flamingo Skin since Sept 2014. Bootstrap 4.0 launched in Jan 2018 after more than 2 years of active development (since Aug 2015). It's declared as a "major rewrite of the entire project", but some of the top changes that are affecting us are the break in backwards compatibility by having lots of variables and classes removed and deprecated, the switch from LESS preprocessor to Sass, the change of the Grid system to Flexbox, etc.
Comparison with other Frameworks
Before deciding on switching between the two version, I've investigated if there isn't a new framework that was launched meanwhile that could replace Bootstrap. I've analysed 15 of the most popular front-end frameworks and you can see a summary in the spreadsheet.
I've compare on Google Trends how Bootstrap compares to top 5 frameworks according the GitHub Stars (Bootstrap, Semantic UI, Material-UI, Materialize, Foundation) for 1 and 5 years period. I've kept Foundation in the comparison since IMO you will find the most articles that offers it as a Bootstrap alternative. Also I've compare Bootstrap with one of the recent frameworks launched (Bulma), with one framework that support both Less and Sass (UIKit) and with a framework that support multiple layout techniques (Susy).
Bootstrap remains (according to the number of GitHub Stars and Google Trends) the most popular framework for the past 1-5 years. It has over 1000 contributors and over 17000 commits.
Backwards compatibility
Apparently there are no few frameworks that are concerned about backwards compatibility. Maybe because they are intended for small, rapid projects or maybe because some like to do complete UI redesigns. Unfortunately this is not ideal for a platform like our own that needs to support extensions and interface customisations from our users.
If we look at their migration documentation there are 24 occurrences of the word "removed", 27 occurrences of the word "dropped", 20 occurrences of "added", 15 occurrences of "no longer", etc.
LESS to Sass switch
LESS took a perceived big hit when Bootstrap framework announced they will be using Sass for their 4 version (Aug 2015). Although LESS is looking still strong in terms of GitHub Stars, it's kind of hard to have some clean numbers since there are various repositories and various implementations of the compilers (C++, Java, Ruby, JS, etc.)
| Preprocessor | Latest Version | Latest Version Release | GitHub Stars Apr 2018 |
|---|---|---|---|
| LESS | 2.7.2 | Apr 2018 | 15,500 |
| Sass | 3.5.6 | Mar 2018 | 11,279 |
We had these comparison discussions also in the past and we decided on LESS mainly because of Sass's variables conflict with Velocity variables (and because Bootstrap / Bootswatch were using it primary). Guillaume also benchmarked the performance.
One concerning thing is that from the 15 analysed frameworks only 18% are using LESS while 62% are using Sass. 2 frameworks (Skeleton and UIKit) are still providing both preprocessors, but they are in the top 10.
Where are we using LESS?
What are we using LESS for?
There is not really a question of removing LESS from XWiki. We don't know how it extensively it was used by our users, but the question remains if we should also support / integrate Sass, if we consider Sass just because of Bootstrap and how many features can be replaced with native CSS.
Grid based on Flexbox
General considerations
I've compared these frameworks based on layout techniques and pre-processor, but another thing to consider is that each framework comes also with its suite of components. These can be considered by some that bloat the size of dependencies, but on the other hand provide very fast iterations on interface, since they come pre-styled and sometimes also with JavaScript interactions.
