BEM - methodology for hanging crutches
I first learned about BEM 5 years ago. At that time, everyone hated IE6, waited for the opportunity to fully use CSS2 and safely forgot the tabular layout. At the time, it seemed that when IE6 disappeared, the life of the layout maker would be exciting and carefree. 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 particular problems with the development of popular browsers, the situation will become even worse.
Recently, I discovered that many existing projects have already implemented BEM, and some new projects require the typesetter to be developed on BEM. That is, professional developers are already facing the fact and have no choice. Once the situation is this way, let's try to sort it all out 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 charms of BEM are reduced to these indicators. If the programmer is long to talk about their importance, and then offer to buy an elephant, the transaction is likely to take place. To understand whether BEM improves something in this direction, you must first decide on what we will check for improvements. If you create a page with tables, as it was in the days of IE6, then there will definitely be improvements from switching to BEM from this typesetting. But to find projects that still suffer from tabular layout, now is not easy. We will look better at current practices that come from the HTML / CSS specification.
There are only one such practice. This is a semantic layout with separation of data structure and design. For many years, HTML developers themselves have developed a language, meaning this particular practice. The concept of separating the data structure and design contains one very important idea on the subject of maintainability. The HTML markup is created in such a way that any subsequent changes can be made by changing only the CSS code. This concept very elegantly solves all the tasks of maintainability. As a result, if BEM improves something in terms of maintainability, then it is clearly not in relation to semantic layout.
BEM made life easier for developers in Yandex
Many times I saw something like this phrase as a convincing argument in favor of BEM. Check the quality of life of developers in Yandex after the transition 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 of the Yandex projects, some of the practices of the table layout are still used. For example, in order to place a logo and a horizontal menu on one side of it, one of the developers of Yandex will issue one common table. It is not surprising that BEM improves life in Yandex, because BEM is only a tabular layout worse.
The problem is that this company has spread its struggle with the tables on the whole RuNet under the guise of some effective methodology. Now even new projects, the developers of which do not even know about the table layout, are forced to use this clumsy practice of dealing with tables. It is necessary to struggle with tabular imposition, if the problem somewhere else takes place. Just do not need to change some crutches for others. There are good ready-made practices that solve all the tasks of maintainability for a long time. And certainly it is not necessary to drive out with Habr all those who speak out against using the BEM methodology. If BEM were as beautiful as the authors describe, there would be no sracha.
What is the result
BEM is a tough and very clumsy set of rules that does not have any practical use if you do not take into account the problems of the outdated table layout. BEM disfigures the code and destroys everything beautiful in the layout process. Any contact with BEM is reminiscent of the senseless and tiresome hanging of crutches.
Before introducing BEM, you should think several 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 spread of govnokoda.
Recently, I discovered that many existing projects have already implemented BEM, and some new projects require the typesetter to be developed on BEM. That is, professional developers are already facing the fact and have no choice. Once the situation is this way, let's try to sort it all out 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 charms of BEM are reduced to these indicators. If the programmer is long to talk about their importance, and then offer to buy an elephant, the transaction is likely to take place. To understand whether BEM improves something in this direction, you must first decide on what we will check for improvements. If you create a page with tables, as it was in the days of IE6, then there will definitely be improvements from switching to BEM from this typesetting. But to find projects that still suffer from tabular layout, now is not easy. We will look better at current practices that come from the HTML / CSS specification.
There are only one such practice. This is a semantic layout with separation of data structure and design. For many years, HTML developers themselves have developed a language, meaning this particular practice. The concept of separating the data structure and design contains one very important idea on the subject of maintainability. The HTML markup is created in such a way that any subsequent changes can be made by changing only the CSS code. This concept very elegantly solves all the tasks of maintainability. As a result, if BEM improves something in terms of maintainability, then it is clearly not in relation to semantic layout.
BEM made life easier for developers in Yandex
Many times I saw something like this phrase as a convincing argument in favor of BEM. Check the quality of life of developers in Yandex after the transition 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 of the Yandex projects, some of the practices of the table layout are still used. For example, in order to place a logo and a horizontal menu on one side of it, one of the developers of Yandex will issue one common table. It is not surprising that BEM improves life in Yandex, because BEM is only a tabular layout worse.
The problem is that this company has spread its struggle with the tables on the whole RuNet under the guise of some effective methodology. Now even new projects, the developers of which do not even know about the table layout, are forced to use this clumsy practice of dealing with tables. It is necessary to struggle with tabular imposition, if the problem somewhere else takes place. Just do not need to change some crutches for others. There are good ready-made practices that solve all the tasks of maintainability for a long time. And certainly it is not necessary to drive out with Habr all those who speak out against using the BEM methodology. If BEM were as beautiful as the authors describe, there would be no sracha.
What is the result
BEM is a tough and very clumsy set of rules that does not have any practical use if you do not take into account the problems of the outdated table layout. BEM disfigures the code and destroys everything beautiful in the layout process. Any contact with BEM is reminiscent of the senseless and tiresome hanging of crutches.
Before introducing BEM, you should think several 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 spread of govnokoda.
Source: https://habr.com/ru/post/270075/
All Articles