Buttons are never too many

About half a year ago I read the article “Why is it worth using preprocessors”. In it, the author describes the advantages of preprocessors using an example of the implementation of custom buttons. The article turned out to be informative and very interesting. The author cited various preprocessors as examples and explained why he stopped at Sass. At the expense of the color of pencils and taste, I have no right to argue, each has its own views. But even then, it seemed to me unfair descriptions that Less is not powerful enough. Even then I wanted to do something similar, to embody the author’s idea in other preprocessor languages ​​(Less, Stylus). At the time of reading the article there wasn’t anything to do. And recently, this weekend, I remembered this article and decided to implement the author’s idea - only using Less. I didn’t see the point of doing anything new, so I decided to help the author in the development of the project, made a fork from his repository,

Less or Sass or Stylus or something else there?

It all depends on the features of your project and on your needs. If you are not familiar with any of the above preprocessor languages, it's time to start getting acquainted. Not only will you discover a lot of new and interesting things, you will also get a good level up. In our projects we use Less. And you know, for two years with a ponytail, I never once thought that Less is deprived of functionality, speed, or something else there. Yes, in the first implementations it was damp and required serious improvements, but at the moment it is very functional and you can implement a lot of your ideas on it, you just need to read the documentation and combine the features that this preprocessing language offers us. Often I hear that preprocessors are hard, they only make it difficult to write code, to use them you need additional tools.

Preprocessor Benefits

Variables, mixins, imports, nesting, and more. It was not for nothing that I called the first variables, mixins, imports and nesting - they make up most of the code, all the other features of a particular preprocessing language complement them. This fun four allows us to easily implement the DRY principle , make code support simpler and easier, and get rid of excess copy-paste.

Variables

I can’t imagine how now, in the realities of the rapid development of the Front End, you can live without variables. Those who say that variables are not needed, they only interfere, clutter up the code - they blatantly liewrong. A simple example: you need to change the link color from red to blue in four files in four places. The task is simple, but what if there are not two files, but twenty-two, and you need to change not in four places, but, say, on every fifth line of each file. And then it begins: open all twenty-two files, search for the desired color, change, save, check the work. Error, come on again. And if there was a file with variables, everything would be much simpler - open this file, change only one line, save, profit. The result is obvious. And the work is less and the percentage of errors is much less (I would say that it tends to zero). A simple example of a variable file that I used: _variables.less

In it, we store the names of brands ( @ brands-name ), colors ( @ brands-color ) that correspond to these brands, and the total number of elements in the list ( @ brands-count ).

Mixins

Admixtures, mixins - already one name tells us that we can take several pieces of code and put them under one name. Moreover, inside you can specify class names, use the parent selector, specify local variables, set conditions, and much more. The most obvious plus - once written, many times we use throughout the project. Mixins are very similar to functions in programming languages. They can be created both with parameters and without parameters , with conditions , used as functions that return the results of their work. Once I had the task of implementing product tags in the form of tags with text with long shadows. Shadows could be of different sizes and colors. The number of tags, their color could also vary. After a little thought, after reading the official documentation, I came to this option . If we had not used Less or any other preprocessor, then in pure CSS such a solution would have taken up a lot of lines of code, the name of each class would have to be written with pens, each step of the shadow should be specified explicitly. Of course, I love difficult tasks, but not to such an extent. This example can be implemented not only in Less, but also in other preprocessor languages.

Imports

In standard CSS, all @ import rules should go at the very beginning of the file, with the exception of @ сharset, if any ( @ import rule ). Preprocessors add their own features for this directive. In particular, for Less it doesn't matter what part of the file @ imrort will be. If you @imрort “filename”do not specify an extension after , then by default the file with the extension will be imported .less. It is also possible to import php and css files . Other options are available for @ imrort rules . The obvious benefit when using the @ imrort directives is the organization of files within the project and their subsequent use. As we did with the files of mixins and variables, and then they were imported into other files and reused.An example .

Nesting

This is both an advantage and a disadvantage. I will explain why the disadvantage. Many fragile minds begin to completely repeat their DOM tree, forgetting that at the output we get very slow and heavily supported code. We have our own Style guide on the project, which describes a lot of interesting things, including what the maximum permissible level of nesting can be. In order not to give rise to topics for discussion, I can only say that you need to be extremely careful with nesting, otherwise you can come to the situation that in order to redefine a particular style, you will need to resort to services !important, which is fraught with consequences. Also worth mentioning is the parent selector. It opens before us unprecedented opportunities that in pure CSS were not available to us. Only, again, I repeat, use it with caution, only when you 100% understand the logic of its work. An example .

What else

All the advantages that preprocessors give us, and in particular Less - this is not the whole list. In fact - yummy is enough. And this applies not only to Less. Therefore, read the manuals, practice, combine several features into one and you will see how powerful and functional preprocessors are.

Thanks for attention.
If there are any inaccuracies in the text of the article - write in a personal.