PostCSS. Future after Sass and Less

Andrey Sitnik ( Iskin , Evil Martians )

In 2013, Holowaychuk announced its Rework project in the article "Modular CSS preprocessing with Revork" ( http://tjholowaychuk.tumblr.com/post/44267035203/modular-css-preprocessing-with-rework ).

Just then, I was looking for some kind of tool to make an auto prefixer. When I read this article, I was amazed, because it was a truly revolutionary approach, it changed everything. And so the first versions of the autoprefixer were based on Rework. But unfortunately, Rework was the Proof Of Concept, it was the first generation to prove that it works at all. Therefore, we forged it hard, lured away all the developers, made a small revolution and made PostCSS.
')
PostCSS is the second generation modular processor.

So what is PostCSS?

PostCSS is a modular preprocessor with a very simple core. The core consists of two things:

1. A parser that accepts a CSS string as input and outputs a tree of javascript objects to the output. AST (abstract syntax tree).
2. Strigyfire, which he does the opposite thing - he receives that abstract tree as objects at the entrance, and gives the output a new CSS. By default, the PostCSS kernel is very convenient, very useful, but it does nothing. It parses your CSS, and then turns it back into a string and turns it so that bytes are saved to bytes, even whitespace characters.

All the magic is in these plugins.

What is a plugin? A plugin is a javascript function that accepts AST as input, goes through some of its nodes, searches for something, changes something, adds something, and returns the modified tree. The following plugin goes to the modified tree ... It turns out the chain. And at the end - the magic stripfire that takes this modified tree, saves it to a new line, and generates code cards, sorsmaps. Generates new or updates old ones.

As Torvalds said, “show me the code,” because we are all programmers, code is important.



What does this look like? PostCSS is an NP-library, we ship it from NP. Next, we create an instance, create a processor object, and pass those plugins that were in the last step and that's it. We take and run this CSS through this processor. And we get the result using promise.

Example plugin:



In preprocessors it is impossible to make a polyfil for a unit of measure. Let's write it on PostCSS. A plugin is a function that accepts CSS as input, a tree of objects that will be in a CSS variable. Further, this tree has such magic functions - so that it is convenient for you to program, there is an iterator on all properties, inside, it is recursive. And we take and pass through all the properties. This is, by the way, notice ES6. We iterate over all properties, look for the value of rem in the properties and replace it with pixels. We close parentheses, because unfortunately, we don’t have CoffeeScript. This is all the code you need to write to make such a basic polyfill for rem.

What is the difference?



You always need to know who to beat and who not, i.e. we must have exact criteria, where is the preprocessor, where is the postprocessor. The preprocessor is monolithic, all functions are built into the kernel, all variables, impurities are all there inside, the whole syntax. And the second thing is that you have the code right in the template, you have a full programming language.

In PostCSS, everything is in the form of plug-ins, the kernel does nothing. And the second point is that you have the code and styles separately, it turns out that you have code in the normal javascript programming language, and CSS is separate in CSS.

Why is this so important? Because these plugins implement the magical thing - evolution.



You get some crazy idea, and your friends laugh at you. You take and implement it as a plug-in, for example, some new optimization method, and publish it. Unfortunately, they continue to laugh at you, because haters are gonna hate, but at least some people understand this, start using it, testing it. They do it, they are recruited more, and those who laugh at you are dismissed. After some time, it turns out that most users use your plugin. Not because the idea is beautiful, but because it really works in practice. And when we have popularity, we can come to the W3C and either write them a draft or ask someone else to make a specification. Because the specification, when we do not have any real practical application, there is no practice, no one knows whether it works or not, no one will. But if you have popularity, you write the specification and go to a new circle, new humiliations, a new plug-in, etc.

It was a theory. Modern science says a very correct thing - theory means nothing without practice. If the idea really works, we will have a real bottom line, we will have something. If PostCSS works, then it will be better than the preprocessor, then we will have something alive, something that can be touched. Let's see if it is.



The first. Of course, there are variables in PostCSS, it is not difficult, there is nesting, it is also not difficult, with an ampersand, as everyone likes, because BEM itself is an impurity, the syntax is slightly different, but the same. But what is the important point? All this is done in the form of plug-ins. And variables, and nesting, and impurities. For example, there are two plug-ins for variables, one plug-in implements the good old Sass-style, and the other implements the W3C syntax, css custom properties.



The second important point is that it is incredibly small. For example, nesting is 60 lines of plain javascript code. You can take it and fix it, but if I refuse to take it, you can take it and fork it. This is absolutely not a problem, you can make another nesting in a day.



PostCSS is not about doing Sass work modularly, because this is not so cool. Modularity is not modularity, who cares? The main question: is it possible to do more, is it possible to make some completely new magic? And here autoprefixer is the main example, i.e. you just write plain CSS, and auto prefixer yourself. He has a database Can I Use, he himself finds those properties that need prefixes right now, adds them, at the same time doing all the complicated magic.



A more interesting example is cssnext.

In Javascript, you can now use the Javascript, which is not yet in browsers, the future. And you have a compiler that compiles it into the current one. It would be cool to do it all in CSS. For example, we have CSS 4, there are a lot of new tasty things. For example, you can declare your additional selector, custom, your personal and use it. And for this we have cssnext.

Cssnext is a transpiler. You are writing CSS 4 right now, and it is compiled into CSS 3. This is about the question of what cannot be done in Sass. In addition to custom selectors, for example, you have a standardized function for working with color, including any convenient abbreviations. Right now, you can come and add.

But now there will be a terrible story.



China, a huge market, a lot of money, all things, but there is going on - horror! There is still popular E7, the 8th and even the 6th. This is terrible, but I want money. Therefore, the Chinese company Alibaba wrote plug-in cssgrace. It's like cssnext, just the opposite. It does not make good the average, but it, on the contrary, makes the middle code bad. It goes through your CSS and finds those properties that will not work in your E, and replaces them with hacks. It's a bit like impurities, but why is it cool, and why is it important that it is impossible on Sass? Because with impurities you need to remember where you need to write impurities, you must remember that opacity is not supported. And here you just write and do not think about it, but the Chinese think for you, a billion Chinese.



In addition, all the magic with properties, and you can do magic with selectors. There is a terrible hack, it would be cool to say that if we have four elements in the parent, then let us make a width of 25%, and if five, then 20. And this can be done right now. Hack creepy, you will not write manually, but with the help of this plug-in or PostCSS, it adds you an additional selector.



Or another thing. Above everything was about how to write code, and this is about how to make code so that your site loads faster.

There are sprites, and there is besidzh 3 encoding inline images, and they have their pros and cons. That would be cool to combine them. When you inline, your CSS grows, and it turns out that when a user visits the site, until he downloads the inline images in the CSS, he will not see anything at all - this is bad. It would be cool if the design first loaded, and then the pictures. And for this there is a magic plug-in data-packer. It goes through your CSS, finds all the images inline and puts them into a separate file. Therefore, he discovers that two selectors use the same picture, and combines these selectors.

As a result, when a user visits the site, he quickly loads a small CSS design, and then a long CSS with pictures is convenient. Those. add one plugin, and right now your site is getting faster.



An interesting moment. Who supports IE9? And who supports people who have color blindness? The problem is that people who do not see the color, 5%, and IE users old - less. And it is very important to maintain. And you need to understand that this is not black and white vision. All these jokes about the traffic lights are not about color blindness. For example, a healthy person sees this (left), and a person with color blindness sees that (right). You see that the button is worse noticeable.

This needs to be tested, and it is easy to test using PostCSS. There is a plugin. During development, you, for example, make an ordinary build and add a plugin to another build. This plugin goes through all the colors of your CSS and replaces them with the colors that people see with different types of color blindness. Of course, there are more convenient tools, but we understand that if you do not use more convenient tools, it means that they do not suit you. But with this, you can check the site for people with color blindness using these simple tools.



Here's another interesting point - PostCSS can be used not only to change your CSS, but also to check it. For example, Twitter uses PostCSS for its linter, its BEM. This is not a very cool linter, because it is as simple as all the linter you may already be using. But there is a cool linter - doiuse:



It works like two prefixers, only it hits you with a ruler. It stores the Can I Use database, goes over your CSS and finds that for example: “Dude, you told me that you want to support IE, and user selected is not supported by IE, you are sure that you should write it ? This is a very convenient thing.



This is my favorite plugin. This is what Wikipedia looks like in Hebrew. Why? Because Jews and Arabs write the other way. This is a very old letter. But the fact is that (you never wondered why the future is right there - right?) The future is right, because we write from left to right. And if we write the other way, then the future in our head will be on the left. And so the progress bar for Jews and Arabs should go the other way. And this concerns not only the progress of the bar, but in general, writing affects the perception of space.



And what will happen if ISIS takes you into slavery and forces you to impose sites on them? You will not support two versions of styles. One for the western audience, and the other for the Arabic. And so the guy from Jordan (he, it seems, is not in ISIS, thank God) wrote a plugin through which you run CSS, and he replaces left with right, right with left ... And he generates such a thing himself. Those. the entrance to the usual Wikipedia, and the exit Wikipedia mirrored. This is my favorite plugin that shows what is impossible on Sass.



Now I have told only about those plugins that are now completely impossible on Sass'e to shock you. In fact, we have a lot of different plugins, which are sometimes more useful, they just do not look so cool. You can go to our github and see all the plugins, there are a lot of interesting things, a lot of all sorts of synthetic sugar, optimization, language extension, support for old browsers and support for future browsers.



There is a very difficult question. I showed things that PostCSS can do that are not possible on Sass. PostCSS can do much more. This is an incredible, more powerful tool, but the question arises: can a more powerful tool be faster? Because libsass did an incredible thing with C optimization, they are very fast. Is it possible to outdo the result of libsass? And the answer is yes.



This is a prime example of why modular architecture is so cool, so important. Because modular architecture is very easy to optimize. We have a lot of small modules. We can understand that this module is slowing down in us, we can take it and optimize it. And therefore PostCSS is written in Javascript - 4 times faster libsass, written in C ++. This is about the question of when backender will tell you that “let's write everything in C now, this is faster,” then no, this is not faster.

Once again: what are the advantages of PostCSS, why is it better than Sass?

1. PostCSS is much faster. Those. even if you are satisfied with the speed of libsass using PostCSS, you can do more things, you can do some more complex optimization. This is a huge space.
2. The second thing is modularity, you can take and fork a project, you can use different ideas.
3. And the third thing is the most important thing, that PostCSS is more than Sass. On PostCSS you can do any feature that Sass has, but with Sass you cannot make most of the features that PostCSS has.

But I lied to you. The title of the report said that PostCSS is the future after Sass. Actually, this is the present. We already have more than half a million downloads per month from Can I Use. Huge audience. Therefore, if you are worried about production, do not be afraid, we really check PostCSS on a huge audience. PostCSS is used by very large companies.



Paul Irish said that PostCSS auto prefixer is used by Google. Taobao is the largest online store in China, it does not just use PostCSS, different plugins, it writes them. Wordpress uses two plugins. Rtl css autoprefixer for Arabic version. And Twitter is not just using PostCSS, they at some point picked up and thrown out Less. They use only postprocessors. Only this method of approach.



In addition, PostCSS is becoming a trend. For example, A List Apart wrote an interesting article about postprocessors, about how PostCSS postprocessors save us from the dark side of CSS processors ( http://alistapart.com/column/what-will-save-us-from-the-dark- side-of-pre-processors ).



Or, for example, a defector in our camp, Ben Frain, author of the book Sass and Compass for Designers, wrote an article about how he parted with Sass and switched to PostCSS ( http://benfrain.com/breaking-up-with-sass- postcss ).



But the coolest tweet is the ultimate, Bootsstrap. They wrote that they were so inspired by CSSnext that they liked it so much that Bootstrap 5 would most likely be on PostCSS ( https://twitter.com/mdo/status/591364406816079873 ). Now he is at Less, then he will be at Sass, and they are going to throw out Sass and switch to PostCSS.

Those. What do I want you to do when you came home this weekend?



First point: if you are doing some interesting tool for processing CSS, consider using PostCSS. PostCSS is much better than Regexp, because Regexp is dangerous - they change code cards and so on. things.

The second point is the preprocessors. For example, another defector to our camp - the developer of Grid, an impurity for the realization of the lost grid, who made Makeev on a very interesting web standards twitter - he switched to postprocessors, he liked it so much, why? Because before it was necessary to support three versions - one for Stylus, one for Less, the other for Sass. It was very tedious. And then he understood: why do this? It just takes as an auto prefixer. He picked up PostCSS, and Sass users, Less users, etc. can use it.



If you are making websites, making a tool and not using PostCSS, add an autoprefixer right now. This is very important, why? Because Google recommends the only tool for working with prefixes. This is only PostCSS, all other elements are much worse, there are many reasons why.



Third moment. If you are already using PostCSS, for example, for autoprefixer, look at other plugins. I advise you to start with cssnext, because it is really cool, this is an opportunity to write on CSS 4 now. In addition, look at the list of plugins, it seems to me that it will be pleasant.



And the fourth moment. If you are starting a new project, I do not recommend throwing out Sass right now, because PostCSS can work well after Sass. Why throw it out? If you are starting a new project, think about why you need to make variables, nesting, and impurities on preprocessors. PostCSS also has this, if you are using an auto-fixer, why do you need to parse the file twice? Simply add variables, nesting, admixtures in PostCSS in front of your autoprefixer.

Because IT is not about programming, IT is not about code. Because, in an amicable way, ICQ could be done in a telegram. Why is IT now? Because we are now in the time when we cannot solve the tasks facing us. All the tasks that we solve more difficult than is placed in our mind. This is the idea of ​​IT. IT is a struggle with complexity. And what is simpler - two tools or one? For me, so alone.

Contacts

" Iskin
» Vkontakte
» Evil martians

This report is a transcript of one of the best speeches at the conference of front-end developers FrontendConf . We have already opened preparations for 2017, and by subscribing to the conference mailing list you will receive 8 of the best reports from last year.

The most difficult section of the upcoming HighLoad ++ conference is the Frontend Performance . The frontend has become big, this is already full-fledged software with its own architecture, models and data (and not just an interface, as it was before). It is in this section that we study it in this section.

Here are some of the planned reports:

• Industrial site acceleration / Nikolay Macievsky (Ayri.rf);
• Your hero images need you: Save the day with HTTP2 image loading / Tobias Baldauf (Akamai Technologies);
• The Accelerated Mobile Pages (AMP) Project: What lies ahead? / Paul Bakaus (Google);
  We exceed the speed limits with Angular 2 / Alexey Okhrimenko (IPONWEB);
  Instant Loading: Building offline-first Progressive Web Apps / Alex Russell (Google);