About variables in CSS and abstractions in web programming
I bring to your attention the translation of an article from the blog of web-technology promoter Chris Koyera About Variables in Web Languages . In the article, the author raises the question of whether CSS really needs add-ons that make it harder to read, and the threshold of entry is higher when developers already have the opportunity to go up one level of abstraction .
Variables come in CSS . Already today there are concrete implementations, so they cannot be stopped now. In Firefox, they appeared in version 29, and in Chrome you can use them without prefixes in versions 29 and older, if you enable the Enable experimental Web Platform features checkbox in your settings (in the Russian language "Enable experimental features of the web platform"). .).
I have to say right away that one can argue as much as he wants about whether it is good or bad, but nothing can be changed. However, since I still want to discuss this topic, I will continue.
')
Recently, I did a presentation on abstractions in computational processes. History knows several key moments when we moved to a new level of abstraction. From the “ones and zeros” of machine code to assembler, from assembler to compilers, from compilers to their abstractions. In the end, we were able to create such high-level languages ​​like C ++ .
Browsers consist of parts, such as the rendering engine (rendering) and the JavaScript engine. They are written in C ++ . So, when we write in HTML , CSS or JavaScript , we climb one more level along the abstraction ladder. HTML , CSS and JavaScript do not replace lower level languages, they are above them and depend on these “layers”, which allow them to do their work as successfully as possible. HTML , CSS, and JavaScript are the languages ​​that we came up with to create what we wanted to see on the Web — interactive documents.
Time is ticking, and we want / expect / need the web platform to do more. New features are always added to browsers, but never removed from there². We admire these opportunities and try to fully use them. This makes creating web applications more difficult. But we do not like difficulties, because they cause inconvenience in work and reduce our effectiveness.
This has been going on for quite some time, so now we are taking a new step along the abstraction ladder. Abstraction is a natural enemy of complexity, so we use it to simplify writing code.
The most necessary abstraction for us on the web was to simplify working with HTML . It would be incredibly stupid to work on a website, each page of which would be stored as a complete HTML document, starting with
Abstraction in JavaScript is originally. The language has the appropriate tools - these are variables, cycles, functions, and so on.
The last web language that needed abstractions was CSS , and they came in the form of preprocessors. There are too many repetitions in CSS , and it almost does not provide tools for abstractions. And preprocessors give us what was so necessary, and this seriously helps us.
Another important point is the popularity of the web platform. It is the most successful platform in the history of computers. It creates more than any other. In other words, HTML , CSS and JavaScript are extremely successful. In many ways, this is due to the efforts of the advocates of web standards, but this is another story.
Why is a language like CSS so popular? Because it is very simple. Selectors and key-value pairs. And that's all. Yes, there is a mass of all kinds of pitfalls and subtleties. Yes, to become a real expert, it will take a lot of time. But at its core, this language is very simple. It will take you ten seconds to show a block of code to an unfamiliar person and explain how it works. That will be enough for him to understand.
I’m convinced that the secret of CSS success is that its syntax is easy to understand, learn and teach others. Yes, it is, for which to scold, but I think that at the initial moment of CSS development, the right decisions were made.
Like other languages, CSS has evolved over time. Like the entire web platform, it received new features. Jeremy Keith pointed out that with the advent of
As Jeremy says:
There is no guarantee that the CSS fragment necessarily has at least some meaning.
CSS (the language itself) goes further along the path of becoming a fully programmable one. If variables are convenient, the same goes for cycles, isn't it? One can imagine a future version of CSS , in which there are so many powerful features of a programming language, that it is no longer perceived as that simple, easy-to-understand and understandable language from which it originates. So, he is deprived of that simplicity, thanks to which it was so easy for a novice to approach him.
I most definitely am not an opponent of variables or any other concepts related to programming. I like them. They give me more opportunities as an author, simplify my work and allow me to do more. This is what all (good) layers of abstraction do. So why not leave these concepts just a layer of abstraction instead of changing the basic principles of the language?
Jeremy's word:
Let me in the spirit of cross-blogging, again answer Jeremy.
He compares Sass and Haml and says that Sass is good and Haml is bad. I agree with him for the most part. I worked a little with Haml and never felt the particular benefits of working with him. Every day I work with Sass , and his impressions are completely opposite. There are two points here.
Here the context is important - “after a certain time”. When the moment comes, in which we take the next step up the abstraction ladder, there are always several languages ​​that argue among themselves over who will take their place in history. Developers are trying to beat each other (as we see on the CSS preprocessor market now), and over time a “winner” is revealed, who owns the main “market share”, if this term is used here.
The winner is the same “good”, since he confirmed his superiority in practice. The losers (probably) were not so good abstractions.
The second point is that I divide abstractions into “primary” and “secondary”. Perhaps the chosen terms are not very successful, but I mean that there is an abstraction that provides authors with the most important and significant benefits for them - this is a primary abstraction, and there are abstractions that add only some details - these are secondary abstractions .
As I said above, the primary abstraction in HTML is templates and content storage in data stores. Haml is a secondary abstraction, due to which some developers get a more convenient syntax of the language - this is an amateur. CoffeeScript is a secondary abstraction for embedded abstraction tools in JavaScript .
Sass (or whoever becomes the winner over time) is the primary abstraction for CSS .
Original: About Variables in CSS and Abstractions in Web Languages
Notes:
1 - I know perfectly well that it is now customary to write “browsers”, but when I first became acquainted with this word, there was still no Russian “canonical” version, and there was often writing through “o”, including in specialized literature. Since then, I write it the only way. Sorry if it hurt your feelings.
2 - In the comments to the original post, Chris is told that this is not entirely true.
UPD: Thanks for the suggestions for editing the makc9I .
Variables come in CSS . Already today there are concrete implementations, so they cannot be stopped now. In Firefox, they appeared in version 29, and in Chrome you can use them without prefixes in versions 29 and older, if you enable the Enable experimental Web Platform features checkbox in your settings (in the Russian language "Enable experimental features of the web platform"). .).
I have to say right away that one can argue as much as he wants about whether it is good or bad, but nothing can be changed. However, since I still want to discuss this topic, I will continue.
')
Prehistory
Recently, I did a presentation on abstractions in computational processes. History knows several key moments when we moved to a new level of abstraction. From the “ones and zeros” of machine code to assembler, from assembler to compilers, from compilers to their abstractions. In the end, we were able to create such high-level languages ​​like C ++ .
Browsers consist of parts, such as the rendering engine (rendering) and the JavaScript engine. They are written in C ++ . So, when we write in HTML , CSS or JavaScript , we climb one more level along the abstraction ladder. HTML , CSS and JavaScript do not replace lower level languages, they are above them and depend on these “layers”, which allow them to do their work as successfully as possible. HTML , CSS, and JavaScript are the languages ​​that we came up with to create what we wanted to see on the Web — interactive documents.
Time is ticking, and we want / expect / need the web platform to do more. New features are always added to browsers, but never removed from there². We admire these opportunities and try to fully use them. This makes creating web applications more difficult. But we do not like difficulties, because they cause inconvenience in work and reduce our effectiveness.
This has been going on for quite some time, so now we are taking a new step along the abstraction ladder. Abstraction is a natural enemy of complexity, so we use it to simplify writing code.
The most necessary abstraction for us on the web was to simplify working with HTML . It would be incredibly stupid to work on a website, each page of which would be stored as a complete HTML document, starting with
<!DOCTYPE html> and ending, which would have to be edited directly. Now no one does. The final HTML documents are composed of templates and content fragments.Abstraction in JavaScript is originally. The language has the appropriate tools - these are variables, cycles, functions, and so on.
The last web language that needed abstractions was CSS , and they came in the form of preprocessors. There are too many repetitions in CSS , and it almost does not provide tools for abstractions. And preprocessors give us what was so necessary, and this seriously helps us.
Popularity
Another important point is the popularity of the web platform. It is the most successful platform in the history of computers. It creates more than any other. In other words, HTML , CSS and JavaScript are extremely successful. In many ways, this is due to the efforts of the advocates of web standards, but this is another story.
Why is a language like CSS so popular? Because it is very simple. Selectors and key-value pairs. And that's all. Yes, there is a mass of all kinds of pitfalls and subtleties. Yes, to become a real expert, it will take a lot of time. But at its core, this language is very simple. It will take you ten seconds to show a block of code to an unfamiliar person and explain how it works. That will be enough for him to understand.
h1 { color: red; } I’m convinced that the secret of CSS success is that its syntax is easy to understand, learn and teach others. Yes, it is, for which to scold, but I think that at the initial moment of CSS development, the right decisions were made.
Language complication
Like other languages, CSS has evolved over time. Like the entire web platform, it received new features. Jeremy Keith pointed out that with the advent of
@keyframes in CSS there has been a major shift. For the first time, it is possible to write CSS in such a way that it will not make sense at all and may not work until another CSS block appears. /* ... */ .animate { animation: my-animation 0.2s; } /* ... , */ @keyframes my-animation { to { color: red; } } As Jeremy says:
Hence, CSS variables (or arbitrary properties) are not the first crack in the wall of principles on which CSS rests. If I use my other metaphor, he got up on the slippery slope with the appearance of @keyframes (and also, perhaps, @ font-face).
There is no guarantee that the CSS fragment necessarily has at least some meaning.
CSS (the language itself) goes further along the path of becoming a fully programmable one. If variables are convenient, the same goes for cycles, isn't it? One can imagine a future version of CSS , in which there are so many powerful features of a programming language, that it is no longer perceived as that simple, easy-to-understand and understandable language from which it originates. So, he is deprived of that simplicity, thanks to which it was so easy for a novice to approach him.
Abstraction layer
I most definitely am not an opponent of variables or any other concepts related to programming. I like them. They give me more opportunities as an author, simplify my work and allow me to do more. This is what all (good) layers of abstraction do. So why not leave these concepts just a layer of abstraction instead of changing the basic principles of the language?
Jeremy's word:
Thanks to preprocessors such as Sass , we have both sheep and wolves are fed.
Not all abstractions are equally useful.
Let me in the spirit of cross-blogging, again answer Jeremy.
... not every abstraction is good.
He compares Sass and Haml and says that Sass is good and Haml is bad. I agree with him for the most part. I worked a little with Haml and never felt the particular benefits of working with him. Every day I work with Sass , and his impressions are completely opposite. There are two points here.
Chris claims that abstraction is, by definition, “good.”
Here the context is important - “after a certain time”. When the moment comes, in which we take the next step up the abstraction ladder, there are always several languages ​​that argue among themselves over who will take their place in history. Developers are trying to beat each other (as we see on the CSS preprocessor market now), and over time a “winner” is revealed, who owns the main “market share”, if this term is used here.
The winner is the same “good”, since he confirmed his superiority in practice. The losers (probably) were not so good abstractions.
The second point is that I divide abstractions into “primary” and “secondary”. Perhaps the chosen terms are not very successful, but I mean that there is an abstraction that provides authors with the most important and significant benefits for them - this is a primary abstraction, and there are abstractions that add only some details - these are secondary abstractions .
As I said above, the primary abstraction in HTML is templates and content storage in data stores. Haml is a secondary abstraction, due to which some developers get a more convenient syntax of the language - this is an amateur. CoffeeScript is a secondary abstraction for embedded abstraction tools in JavaScript .
Sass (or whoever becomes the winner over time) is the primary abstraction for CSS .
Original: About Variables in CSS and Abstractions in Web Languages
Notes:
1 - I know perfectly well that it is now customary to write “browsers”, but when I first became acquainted with this word, there was still no Russian “canonical” version, and there was often writing through “o”, including in specialized literature. Since then, I write it the only way. Sorry if it hurt your feelings.
2 - In the comments to the original post, Chris is told that this is not entirely true.
UPD: Thanks for the suggestions for editing the makc9I .
Source: https://habr.com/ru/post/206956/
All Articles