BEM with a human face and backend integration

The layout of modern web-projects is difficult, time consuming and expensive. It would seem that with the transition of IE to automatic updates, HTML5, the end of support for Win XP, we all need to heal in a fairyland with a pony and a rainbow. Why did not it become easier?

• HTML5 and CSS3 gave the web the opportunity to create a UI that is almost as good as desktop applications. Nothing is given just like that, HTML, CSS and JS have become many times more. Previously, we had three files: styles.css , stupid-ie-must-die.css , scripts.js . Now the number of scripts, styles, downloadable fonts, images is measured in tens and hundreds. There was a need for minification, acceleration of rendering and organization of all this junk in the file system.
• Sites have gradually ceased to be a set of related hypertext pages and have become web-based applications. If earlier for many sites it was enough to create the “main” and “internal” pages, now everything is not so simple. The number of design layouts easily reaches tens and hundreds.
• We’ve all heard a lot about the Landing Page, a / b testing and a multiple increase in conversion for “just so”. Let's leave the question about the effectiveness of these techniques. Design began to redo often - this is a fact. It is known that making changes and supporting is much more expensive and more difficult than development.
• There are mobile devices and the need for responsive design. Testing has become harder and longer. The cycle of fixing bugs found during testing has become longer. Testing UI is almost not amenable to automation, with the growth of the functional time for regression testing is steadily increasing.
• The integration with the backend-code has become more complicated, there is a need to do this much more often.

All this makes you think about optimizing work with the frontend.

I want to:

• Reduce the time and the number of integration work (“stretching” of the layout on the server technology)
• Increase html, css and js reuse, reduce the amount of corresponding code
• Reduce time to modify existing code
• Reduce the number of errors in the modification, especially regression
• Learn how to create and impose responsive design effectively.

')

The simplest solution is to abandon server templating at all, switch to REST-API and SPA

pros

• The integration phase disappears altogether.
• The back and front are separated, each team is more mobile and they don’t have to use a common set of tools at all.
• Front end does not need to deploy server stack

Minuses

• SEO
• The need for a "fat client"
• Implicit code duplication: ViewModel on the client and DTO on the server

The cons are pretty serious. What are the options if the templates are on the server?

Frontedschik edits server templates

pros

• Do not "pull" backend

Minuses

• The front runner needs to hold two sets of tools and switch between them.
• It is difficult for the front-endman to use unfamiliar technology, all sorts of @using (Hml.BeginForm (// ... and <? Php $ form-> textbox ('name')
• Frontman may “break” the server code and not understand it
• Frontman doesn’t know backend coding standards
• The front-runner needs to deploy and configure the entire application, incl. DB and other dependencies

Front-end user edits his templates in pure html without server inserts (possibly with preprocessors) and sends to the backend

pros

• No need to duplicate a set of tools, each does his own job, in which he is a specialist
• Easy to configure environments
• The ability to simultaneously impose a lot of completely different layouts by different contractors

Minuses

• Duplication of work
• Need to edit a template in two places
• We did not reduce the cost of integration.

Front-end user uses server engine during layout and independently allocates layouts, blocks and patterns.

pros

• Integration costs are almost disappearing.
• The server and client use the same set of tools and programming language (this approach is especially attractive for node.js)
• Closer interaction between front and back commands is required to coordinate the "cutting" of patterns and blocks

Minuses

• Required tools, maybe they already exist, you may have to write (for php and asp.net this is done in a day or two)
• Tools may not be compatible with sass / less / stylus / other favorite preprocessors.
• Sharper learning curve for new employees
• The need for a clear written rules and style guide for creating templates, view models and the location of files in the file system
• Closer interaction between front and back commands is required to coordinate the “cutting” of patterns and blocks (yes, this is plus and minus)

I tried all the approaches described. My experience says that, depending on the type of project, other things being equal, the first and last options work best.

And here bam?

Perhaps BEM is one of the most holivore themes of our time, so I can't help but insert the picture below.



.



I tried to work with “BEM” and “semantic” layout and came to the conclusion that constant changes in requirements and modifications lead to the frequent need to change the markup and be tied to tag names and cascades in CSS - the idea is so-so.

What are bad cascades?

The idea of ​​"throwing out" from the "cascading" style pages cascade at first glance seems seditious, but:

• Most browsers handle right-to-left styles, and the rendering speed difference .some-block .some-element li> p a and .some-block__link can reach several times and should be considered.
• Cascades are very difficult to maintain and refine, it is difficult to create reusable components.
• Rejecting style IDs eliminates view constructs.
  
  

  #some-element p, #some-other-element p, #one-more-fucking-id p, .what-the-hell-class-name p.is-doing-here{ /*…*/ } 

  
  
  
• “Classic” CSS recommends, but does not dictate clear rules and regulations, respectively, Vasya may not like the way that Fedya is imposing and vice versa. BEM assumes a unified methodology, therefore Vasya and Fedya are doing everything the same way - according to the methodology. This not bad increases the bus factor on the project and reduces the search time for the required style.
  
  
• The concept of blocks, elements and especially modifiers is very well suited for responsive design, when you want to display different blocks / or display blocks / elements of different elements depending on the screen size.
• Block, element and modifier are successful terms for communication between different specialists. They are intuitive enough that not "non-techies" are not afraid of these words and at the same time are associated with certain techniques.
  
  
  
  These facts make me reckon with BEM and endure the ugly class names. However, even the BEM authors themselves insist that BEM is a methodology that can and should be “doped” for the needs of the project and the team. For this team need checklists.

My checklist

General requirements

1. Layout should be cross-browser and on the grid, correction of errors in indents in the design is allowed
2. Layout must be implemented by BEM-methodology
3. Layout must undergo w3c validation
4. Layout to meet the requirements of this checklist
5. Tables should only be used to present tabular data, nested tables are prohibited.

Forms

1. Forms must always be designed using the form tag, the tag must contain an action attribute
2. Buttons must be tagged as input or button.
3. For phones, you must use the input mask
4. Validation must be implemented

BEM

1. It is forbidden to use element id and tag names, except for the exceptions below, to set styles
2. Classes should be named as follows: some-block__ some-element_ some-modificator
3. It is forbidden to use inline-styles.
4. The names of the blocks and elements should correspond to their purpose and function, and not to how they are displayed.
   
   If the blocks perform different functions, but look the same, they should be arranged as one block with a neutral name, reflecting their similarity. No unnecessary duplication of code
5. It is necessary to use normalization for all tags that cannot have a class name (the cases are described below), the use of reset.css is not allowed. Using normalize.css is permissible, exactly like the normalization variant only for tags for which it is impossible to set a class
6. It is forbidden to use cascading styles with a depth of more than one element (for example, table td ), except for the following situation: depending on the block modifier applied, the child elements / blocks should be displayed differently. The cascade will be short, with dynamic switching of the java-script modifier, the implementation is much simpler and more efficient from the point of view of interaction with the DOM than in the case of modifying the styles of all child elements.
7. B-prefixes for blocks are not used
8. Global modifiers must be declared as a separate class, for example _uppercase . Underscore at the beginning indicates that it is a modifier, not a block. For adaptive layout, it is necessary to use the _desktop , _tablet and _phone global modifiers for the blocks that need to be displayed only on a specific device. It is preferable to use the mobile-first approach: from simple to complex
9. Styles should be applied to tags through the parent cascade in cases where it is impossible to control classes of elements, for example:
   
   
   • The content is entered by the user through a form on the website, is created dynamically or comes from other sources beyond our control.
   • Controls in the form: it is preferable to use the parent cascade, because the elements of the form can be created using the server code. Additional reformatting is required to preserve the styles of the elements. This is undesirable.

Formatting and file system

1. Using one large CSS file or JS file is not allowed, you must use an extensive file structure, namely:
2. Each block is located in its own folder, reusable blocks and main layouts are located in the shared folder.
3. The description of the block and all elements is located in one file called <BLOCK_NAME> .css . If the description of blocks and elements exceeds 600 lines, it is necessary to decompose it.
4. Class names and CSS rules are sorted alphabetically.
5. The modifier should override no more than 40% of styles, otherwise it is better to create a new block.
6. The block HTML template is in the same folder (server or client templating technology is used)
7. Layouts are separated from pages, all necessary pages are “cut” by separate files

Bundling, minification and build

1. All resources must be prepared for production and divided into bundles. Bundles should be grouped in such a way that their number is minimal, and the bundle weight does not exceed 250KB.
2. The use of server technology for splitting html layouts into layouts, pages and blocks is allowed and encouraged.
3. Delivery acceptance is made after the "assembly". The result is n html pages and an index.html file with links to all the folded pages. It is permissible to transfer the layout in the “source code”, with the attached bat / makefile and the “collector”, if the size of the “collector” does not exceed 10MB and can be guaranteed to be run on the OS of the receiving layout.
4. Links in css and js files must be absolute, otherwise there is a risk that they will not work correctly after minification

---

A selection of good materials on BEM:

• habrahabr.ru/company/yandex/blog/234905
• habrahabr.ru/post/171437
• ru.bem.info/method/history
• habrahabr.ru/post/203440

Just awesome getting started guide for new employees.

It is difficult to use as a checklist because of the scale of this document: habrahabr.ru/post/114256 . There is an abbreviated version, which is suitable as a checklist: github.com/delka/html5checklist .

BEM check

 s=document.createElement('script');s.src ="//2gis.imtqy.com/makeup/autoload/script.js";document.body.appendChild(s)