Usually the website development process is based on the assumption that design and
technical requirements will not change.
A designer, a front-end developer and a programmer work each in their field,
often without interfering each other:
- A designer creates a site design in the form of design layout
- Front-end developer create static HTML/CSS pages based on the design layout
Such an approach works well only in the case if the website design remains the same
all the time of his life and the changes only add more content.
But usually that is not happening. The website begins to live its own life being constantly
developed. The design of the pages is gradually changing, new pages and new blocks are
being added on them.
If the website source code is not following the defined structure, if its development
is not based on fixes rules, it gradually becomes more and more difficult to maintain.
The website code gets beyond the control of its developers.
In accord to BEM-methodology all the people taking part in the development of the website are
working with a single codebase and are using the same terms to communicate, the same language:
- Design of the website can change at any time, we must be ready for this
- HTML/CSS code is developing together with the design, ready to its changes
- Programmer and front-end developers are working together on the website codebase,
contributing to each other's code
The conditions of the methodology emergence
BEM-methodology was developed at Yandex
while working on a large number of web services, and is aimed to achieve following:
- Fast-to-develop, long-lived projects
It should be possible to develop and launch the first version of a website quickly with an
architecture that helps to maintain it in the long run.
- Team scalability
Adding new people to a product team should improve speed, not decrease it. We need to be
able to assign new members to a team without a steep learning curve.
Code should be well-structured for a project to remain maintainable over time and
- Code reuse
To maintain UI consistency and minimize development effort on typical interface
components, those components have to be easily reusable.
The source code should not have contextual dependency on the other code, it should be
easy to move that code to another place.
For years we kept looking for solutions to our problems, and at one point they became