BEM - crutch hanging methodology
I first learned about BEM about 5 years ago. At that time, everyone hated IE6, waited for the opportunity to fully use CSS2, and safely forgot the table layout. At that time, it seemed that when IE6 disappeared, the layout designer’s life would become exciting and carefree. That IE6 was the main cause of crutches in the layout. Who would have thought that in the days of HTML5 and CSS3, when there are no special problems with the development of popular browsers, the situation will become even worse.
Recently, I found that many existing projects have already implemented BEM, and some new projects require the developer to compile BEM. That is, professional developers are already faced with a fact and have no choice. Once the situation is this way, let's try to put everything on the shelves without advertising and embellishment.
Maintainability and code reuse
Very important indicators for any development, known to us mainly by programming languages. The whole essence and delights of BEM are reduced precisely to these indicators. If a programmer talks for a long time about their importance, and then offers to buy an elephant, the deal is likely to take place. To understand whether BEM improves something in this direction, we must first decide on what we will check for improvements. If you make up the page with tables, as it was in the days of IE6, then there will definitely be improvements from switching to BEM from this layout. But finding projects that still suffer from tabular layouts is now not easy. Let's take a look at the best practices that come from the HTML / CSS specification.
There are only one such practice. This is a semantic layout with a separation of data structure and design. For many years, the developers of HTML itself have developed the language, implying this particular practice. The concept of separation of data structure and design contains one very important idea on the topic of maintainability. HTML markup is created so that any subsequent changes can be made by changing only the CSS code. This concept very elegantly solves all the problems of maintenance. As a result, if BEM improves something in terms of maintainability, it is clearly not in relation to semantic layout.
BEM made life easier for developers on Yandex
Many times I saw something like this phrase as a convincing argument in favor of BEM. Checking the quality of life of developers in Yandex after switching to BEM will not be easy. But you can see the code of their projects. So, this is very similar to the truth. Indeed, in the layout of some Yandex projects, some table layout practices are still used. For example, in order to position the logo and the horizontal menu on the side of it, one of the Yandex developers presents one common table. It is not surprising that BEM improves life in Yandex, because worse than BEM is only table layout.
The problem is that this company spread its struggle with tables around the Internet under the guise of some effective methodology. Now even new projects, the developers of which do not even know about table layout, are forced to use this clumsy practice of combating tables. It is necessary to deal with table layout if the problem still takes place somewhere. Just do not change one crutch to another. There are good ready-made practices that have long solved all the problems of maintenance. And certainly you should not expel from Habr anyone who speaks out against the use of the BEM methodology. If BEM were as beautiful as the authors describe, there would be no srach.
What is the result
BEM is a tough and very clumsy set of rules that does not bear any practical benefit, if you do not take into account the problems of an obsolete table layout. BEM disfigures the code and destroys everything beautiful that is in the process of layout. Any contact with BEM resembles the meaningless and tedious hanging of crutches.
Before you implement BEM, you should think a few times, read the HTML / CSS specification, and study other practices. Only after a real understanding of the practical utility of different practices and the differences between them can a decision be made in favor of using BEM, but it is better to think again at this point. Otherwise, you can become a victim of aggressive marketing and an accomplice in the distribution of shit.
Recently, I found that many existing projects have already implemented BEM, and some new projects require the developer to compile BEM. That is, professional developers are already faced with a fact and have no choice. Once the situation is this way, let's try to put everything on the shelves without advertising and embellishment.
Maintainability and code reuse
Very important indicators for any development, known to us mainly by programming languages. The whole essence and delights of BEM are reduced precisely to these indicators. If a programmer talks for a long time about their importance, and then offers to buy an elephant, the deal is likely to take place. To understand whether BEM improves something in this direction, we must first decide on what we will check for improvements. If you make up the page with tables, as it was in the days of IE6, then there will definitely be improvements from switching to BEM from this layout. But finding projects that still suffer from tabular layouts is now not easy. Let's take a look at the best practices that come from the HTML / CSS specification.
There are only one such practice. This is a semantic layout with a separation of data structure and design. For many years, the developers of HTML itself have developed the language, implying this particular practice. The concept of separation of data structure and design contains one very important idea on the topic of maintainability. HTML markup is created so that any subsequent changes can be made by changing only the CSS code. This concept very elegantly solves all the problems of maintenance. As a result, if BEM improves something in terms of maintainability, it is clearly not in relation to semantic layout.
BEM made life easier for developers on Yandex
Many times I saw something like this phrase as a convincing argument in favor of BEM. Checking the quality of life of developers in Yandex after switching to BEM will not be easy. But you can see the code of their projects. So, this is very similar to the truth. Indeed, in the layout of some Yandex projects, some table layout practices are still used. For example, in order to position the logo and the horizontal menu on the side of it, one of the Yandex developers presents one common table. It is not surprising that BEM improves life in Yandex, because worse than BEM is only table layout.
The problem is that this company spread its struggle with tables around the Internet under the guise of some effective methodology. Now even new projects, the developers of which do not even know about table layout, are forced to use this clumsy practice of combating tables. It is necessary to deal with table layout if the problem still takes place somewhere. Just do not change one crutch to another. There are good ready-made practices that have long solved all the problems of maintenance. And certainly you should not expel from Habr anyone who speaks out against the use of the BEM methodology. If BEM were as beautiful as the authors describe, there would be no srach.
What is the result
BEM is a tough and very clumsy set of rules that does not bear any practical benefit, if you do not take into account the problems of an obsolete table layout. BEM disfigures the code and destroys everything beautiful that is in the process of layout. Any contact with BEM resembles the meaningless and tedious hanging of crutches.
Before you implement BEM, you should think a few times, read the HTML / CSS specification, and study other practices. Only after a real understanding of the practical utility of different practices and the differences between them can a decision be made in favor of using BEM, but it is better to think again at this point. Otherwise, you can become a victim of aggressive marketing and an accomplice in the distribution of shit.