Proposal: Moving away from LESS

Development
,
1

Hello!

Context

XWiki and LESS

LESS is the CSS preprocessor used in Bootstrap 3. LESS computation is quite a large overhead and takes quite a toll on XWiki’s overall performance. LESS scripts have to be recompiled for every context change. For example, all the cache for LESS has to be recalculated on every small ColorTheme change. This makes it really difficult to provide user-based UI customizations (we don’t want to process every LESS for the context of each user…). CSS variables are evaluated at runtime, which would make implementation of such a feature way less costly.

LESS vs CSS nowadays

LESS was adopted in Bootstrap and XWiki because it provided powerful tools to extend CSS: nesting, variables, functions and mixins. In the past few years, CSS has improved at a quick rate, and now it supports nesting and variables. Note that mixins are not in yet, but can be implemented with a clever use of CSS variables (this blog post is a bit old but shows a PoC :slight_smile: ). The main point of difference nowadays is functions:

  • color operations are possible in CSS with the recent CSS color relative syntax. Given a couple months for widespread support of all features, there should be no issue migrating every LESS color function to some CSS relative colors.
  • The ways to implement logical functions in CSS nowadays is hackish. However, from what I could see, we do not use such functions extensively in XWiki. As far as I know, a move from our LESS code base to CSS would be possible.

Note that logical functions and mixins might end up in CSS in the matter of a few years. There’s an ongoing discussion about it in the CSS Working Group.

XWiki’s recent evolutions

Up until recently, XWiki used on the latest bootstrap 3 release as its design system, which comes in with LESS. Recently, we included a Bootstrap 3 in our source code on xwiki-platform. Having this code as a part of xwiki-platform means that we are not tied with LESS anymore. Moving away from LESS is now a choice we can make.
Of course if it happens, this move wouldn’t happen in one go, we’d need to make sure to keep backward compatibility with LESS scripts for some time.

Proposal

Main point

Move away from LESS.
I propose to be the one responsible for progress on this topic.

Details

Here’s a plan for this transition away from LESS, discussed mostly with @MichaelHamann so far. This is a long term idea of where the process will end up at. We’ll probably have further discussions for details of each step of the process to refine our strategy about this move.

  1. Introduce CSS variables equivalents for all the LESS variables we use in the Flamingo skin (at least every single one from the color themes) – note that with the baseline 2024 for CSS @property, we could have typing on our CSS variables, and fallback values, which would IMO make the styles that much more robust.
  2. Start converting some .less script from our codebase to .css relying on those new variables. Note that from my experience, most LESS scripts are LESS and not CSS only because we needed some variables from the color themes. 1. provides an alternative for this and I’d expect the migration of most of those to be straightforward. This step will also be a good test to see what issues can arise when migrating from LESS to CSS.
  3. Deprecate the use of new LESS and LESS variables
  4. Propose either: a migrator app to convert all custom LESS SSX on the user instance OR a XWiki standard script that will propose to do this conversion to users when they update a LESS. (the best solution isn’t clear for me yet~)
  5. Migrate the public extensions to use only LESS
  6. (Eventually, if we don’t come across code that CANNOT be migrated) Drop support for LESS in XWiki completely: most of it has already been converted to CSS at this point.

Note that I do not expect step 6 to be coming soon at all.
If I’m in charge of the progress of this transition plan I’ll probably need some help from other devs at some points (especially for item 4.).

Explanation

Pros

  • Performance.
  • Being able to use the latest CSS tech (supported by our supported browsers ofc) without conflicts with LESS
  • Reduced tech debt. LESS is an overlay to CSS that is hardly worth its implementation today. Removing a level of abstraction will make our frontend easier to understand and customize.
  • The LESS project is not as active as it was, it could become an even bigger liability on the long term.
  • Will be able to remove from the codebase workarounds implemented because of LESS limitations.
  • Robustness of style with CSS advanced properties.

Cons

  • Backward compatibility challenges, we don’t want to break any customization
  • Until it gets added in CSS (if it ever gets added - good chance IMO but no guarantee), logical functions and mixins are going to be more difficult or even hackish to implement.
  • Need to customize heavily the branch of Bootstrap 3 we manage on xwiki-platform. This means that there would be no going back to using a standard bootstrap3.

Conclusion

Do you agree with the idea of moving away from LESS?
Do you think we should eventually completely remove our support of LESS? What do you think of the strategy proposed to reach deprecation? Is there any step I missed? Do you anticipate some complications I failed to identify? Is there any item you wish to discuss in further detail?

Thank you in advance for your feedback! I hope we can agree on a plan on this subject and progress towards making our frontend easier to understand and extend :slight_smile:

Lucas C.

1 Like
2

Lot of stuff to read, but I already love the title :slight_smile:

The situation is actually quite worst than that for the XWiki Standard runtime since, on Java side (skin extensions for example), we are currently using an 8 years old version of the dead less4j.

Big +1.

Looks quite complete already to me. The important thing is to start converting stuff. Discovering and adding non-LESS versions of stuff we need to do this converstion and eventually the XWiki less framework will reach a legacy state naturally. More detailed discussions will inevitably come in a case by case basis whatever you put in that proposal, anyway :slight_smile:

1 Like
3

Definitely +1

Seems ok to me.

You probably know this, but one big complication will be moving away from the grid system from LESS to CSS Grid or Flex. I was looking at how the main sidebars are laid out in flamingo and I noticed a heavy focus on LESS mixins (.make-md-columns). The main template needs an upgrade anyway, but it will be probably a lot of work.

1 Like
4

Sorry, I forgot to answer before. From what I remember, this grid system is handled by Bootstrap. Personally I’d want to move away from it too, but it’s not the same discussion (and the benefits are not as great :wink: ). As far as I understand, it will be as easy as migrating any other mixin used in bootstrap. I think this grid system from Bootstrap works on CSS float + positioning hacks, so it’s all pretty much just native CSS.

I did a quick search on https://lesscss.org/ and it doesn’t seem like LESS itself has any function about a grid system.

Thanks for your feedback!

1 Like
5

Since noone seems opposed to the main idea of this proposition, I’ll continue along with it. I’ll create a design page and jira tickets to track the progress of the different steps (brainstorming, proposals and implementations).
I’m closing this topic since the proposal aspect is dealt with. Feel free to add any idea you have on the overall subject here (brainstorming, even if a bit late, will still be relevant :slight_smile: ).

1 Like