Styling in Mendix Just Became LESS Work

Skip navigation

Styling in Mendix Just Became LESS Work

Styling in Mendix Just Became LESS Work by Simon Black

In my previous article, I wrote about the adoption of the Bootstrap framework and how Mendix utilizes this framework to make styling quicker and easier. Another shift in the marketplace in the web design area is the adoption of CSS pre-processors. CSS pre-processors are an extension of CSS that combines the functionality of CSS with programmability and logic. Using a CSS pre-processor allows you to use functionality such as variables, logic and functions—common functionality for most programming languages but something not found in CSS. For example, below is some CSS code compared to LESS pre-processor.


The two most popular CSS pre-processors are LESS and SASS. The main difference between the two is that the LESS compiler runs on top of JavaScript and SASS on top of Ruby. I won’t go into the advantages and disadvantages in this article, but the majority of their functionality and overall advantages are the same.

So what does this mean for my Mendix applications and how can I use it?

That’s what I exactly wanted to find out by using the Bootswatch module I mentioned in my previous article as a testing ground for CSS pre-processing. Bootstrap supports both SASS and LESS, but the provider of the Bootswatch library had decided to create their themes using the LESS library. This is why I decided to use LESS for the upgrade of the Mendix Bootswatch module.

While exploring the Bootswatch source code, which is available on GitHub, I learned some more about the structure of LESS. LESS encourages you to split up your files into two types of LESS files: variables and functionality. The reason they have a variables file is so that you can change all the available variables that are used in other LESS files in one location rather than having to go into each LESS file itself and change them. This means that creating a new design is as easy as changing these variables and compiling the LESS code. For example, say the primary color for your business is blue. Changing the primary color variable will update all references to this variable in the CSS. This variable could be used in 10 different places;  using LESS, this one change can update all references when compiled to CSS, whereas with CSS you had to change each of these references manually.


Another advantage to using LESS is that you can make use of the many functions that are available out of the box. These functions allow you to add logic to your CSS. Some of the many functions include being able to perform calculations, update colors by percentages of another color and string functions. Below shows some of the possibilities to add logic:


Bootstrap comes out the box with various LESS files, which create the necessary CSS for each of the available Bootstrap components. These separate files are then imported using import statements in one main LESS file so that all the necessary LESS files are compiled into an overall CSS file. Bootstrap, where possible, has used parameters in its LESS files, so creating new themes just requires changing your variables file. One of the disadvantages of using a CSS pre-processor is that they have to be compiled into CSS.

Compiling can be done by the client browser to aid development, but it is often encouraged to compile into CSS before releasing to production. This is because having to process the themes on the server or client side could cause delays that impact  user experience. At first, this concept of compiling can seem a bit daunting for non-technical users. However, while building this module, I tried to reduce the complexity of the process and make it as easy as possible to build new custom Mendix themes.

There are several popular GUI compilers around which make compiling LESS as easy as pointing and clicking. Because Bootswatch supported Grunt (JavaScript task runner), I decided to follow the help guide on the Bootswatch website and use Node JS server and Grunt JavaScript file to compile my themes. This made it as easy as typing Grunt swatch and all 16 themes were compiled into CSS for me.


This was great but I soon realized that this Grunt file could help solve a number of issues I had been having recently around maintaining multiple themes. Having 16 different themes all with different CSS files and structures meant that if I wanted to make a change to all the themes I would have to copy this change to all of the different themes’ CSS files, zip up all the files again and place them in my theme folder. So what I did was alter this Grunt.js file to create the correct file structure and zip the files for me.

Now, when I run the command grunt swatch, it will go through each of the themes I have specified in the file, compile the LESS to CSS, place the CSS in the ui/theme-{themeName} folder, copy any font folders needed and zip each of the files up into a separate theme. I then added an extra line to enable me to package up all the themes into one, which I use to demonstrate the themes in the module. Creating new themes is now as easy as changing a couple of variables and compiling the theme to get my new Mendix-compatible zipped theme.

In order to gain more traction and feedback on the module, I decided to make the module truly open source by publishing it to Github: You can also find a guide here on how to set up the necessary components needed in order to build your custom themes in the read me file. Please take a look at the module on the Mendix  App Store or now on Github.

I am interested to hear about people’s experiences using CSS pre-processors and the module.

Author Info

Simon Black