 Okay, so we're going to start now with the next talk from Varavara Stepanova, from Yandex, which is Russia's biggest web search engine. It's a bit of a shift in pace and topic from the last three talks. This talk is maintainable front-end development with BEM, a block element modification. This is a technique for writing scalable CSS or building scalable high-performance sites, which are not just scalable in terms of your users, but also in terms of maintenance. So to ensure that if you have lots of developers working on your website, you have a common way of changing things in one place, making sure that people understand what's going on at different parts of your code. So Varavara leaves the front-end team of developers there. Some of them are here with us today. So there's Vladimir and Vladimir. They've made it easy for us. And they'd be happy to take any questions that you have later on today. Just catch any of them through the day. There is a speaker's meeting room just to the left of the registration desk if you want to meet anybody. Have a chat one-on-one with them. So just, sorry, there's also a meet-up on Sunday. More details from, yeah. At 2 p.m. at CAEA's office, we have a meet-up with Benjamin and Varavara about Blockpad and BEM on Sunday. If you want more details about a meet-up, there's one on Sunday, just you could raise your hand. People will catch you. So just another thing, BEM is completely open-source and it's on GitHub, so you can take a look there. Hello. Just thank you for kindly introducing me. I'm Varavara and my talk is Maintainable Front-end Development with BEM. Actually it's my first talk in English with such a large audience, so I appreciate a lot to meet a refresh for accepting me as a speaker and of course you for coming. So, well, let's start. This is me with a friend. I'm a front-end developer working for Yandex, which is the largest internet company in Russia. We began as a search engine back in 1997. And now we enjoy the major share of the local market. We provide search service for web, image, video, and many associated services such as web mail, web maps, marketplace, as well as mobile applications. And next 30 minutes, I'll be first talking about the usual development cycle and what are the problems it brings, then about our solution for these problems, which is BEM, and how it changes development workflow. And then some recent things we'll be working on. So let's start with describing how things happen usually. You all know that when you need an interface to be done, you first go to a designer to prepare a PSD image of this web interface. And then this image can proceed to a markup guy to be sliced into HTML and CSS. Sometimes you need help of JavaScript Ninja to equip this HTML dummy with some magic. And then when dummy is ready, it goes to a server-side guide to be implemented into a functioning website. And these are separated stages, and every stage takes some time. Well, you can see clocks here, and sometimes marked red and some marked green. Why? This is because the work done at every stage cannot be fully reused at the next stage. So I marked red at the time this is just wasting. And this is why I call this process lossful. The problems are that when every stage begins, you need to decompose web interface mentally in your head and detach independent pieces of this web interface. This is what HTML-CSS guy does, then gets a solid piece of PSD image. This is what JavaScript guy also does, and server-side program as well. And even if they all are one person, again, these are different roles, and that cause difficulties. So and also, if you need some changes in your web interface after you already started developing it, you almost always need to start from providing these changes on your PSD image and then go through development cycle again, unless you allow your designer to make changes into a functioning website, but that happens not always. The worst thing is that when returning to provide some maintenance work on your web interface, when you come back, you cannot reuse your own work of decomposing web interface done at previous iteration. So facing these problems, we at Yandex, as veterans on front-end development, came to our own solution for these problems. And now these solutions are united under the need-to-la BEM, which I'm going to present now. Actually, BEM is a whole world on its own, and it's methodological recommendations on how to develop modular web in CSS, JavaScript, templating, and actually any technology. It's some file structure recommendations for a project. It's a bunch of reusable code libraries. It's many helpful tools and optimizes for production code and even its own template engine. But I'm going just to quickly introduce what's the main theme of BEM. I know BEM was already introduced to you last year in the Prem in Commerce presentation, but just to refresh your memory, BEM stands for block element modifier. And these are three main terms of BEM, which I'm going to use when explaining. First is block, and this is an independent component. And actually every page consists of these independent components blocks. As for HTML, block can be represented as a DOM node, which you can see in the slide. Within blocks, sometimes you can find elements, and this may clear picture of what elements are. This is a tablet pane block with two type elements and one panel element. And actually, maybe this is much more... Also block is a DOM node within... An element is a DOM node within its block. And for even better explanation, I found the picture. Well, you know, these pieces make no sense on their own, these are elements, but just put them together and you end up with something useful. And the last term is a modifier that is a property to provide changes on a block or an element. So as you can see, already familiar tablet pane block can be modified with a blue theme or with a direction modifier. That's all just three terms to describe any web interface. In these terms, we at Yandex realized three of our desired wishes, which are in the slide. How that happened? First thing was problems when you need changes in your layout, in your web interface after development was already started. Next, a product manager comes to you and asks you to move one block from the left side of the page to the right side of the same page. And due to your architectural solution, that might be not possible. What people usually do, they tame managers and they train them out of doing this, out of asking such things. But there is another way. We can come up with an architectural solution allowing us to do such things. And this architectural solution is independent CSS blocks. I mean that a block can be fit into any place on the page so that it won't be affected by its parent blocks and at the same time it won't affect children blocks. To do this, you need just to follow some rules when developing CSS, which are first, a block should be named and I recommend to use CSS classes, not IDs, but CSS classes for that. Because you know, IDs must be unique within a page. And we cannot predict if the block, our current block, will be repeated in the page in the future or not. And also, please avoid tech selectors. This is to ensure that a block won't affect its children. And the last recommendation is avoiding cascade. Actually, I see it sounds a bit provocative, a recommendation on avoiding cascade when using cascade in style sheets. So I'm going to explain. Well, I believe that cascade is a very, very good feature of CSS because it allows us to express dependencies between entities naturally. Cascade says that one thing does depend on the other thing. But the problem is that people usually use cascade not to express dependency, but to code some similar things that look similar. And that causes many problems because the interface changes, you need to break this connection between cascading entities. And actually, people do something like this or even worse. They add even more connection into their system and that turns code into spaghetti. So this is why avoiding cascade helps keep your code nice and neat. And what's more, it helps improving rendering performance. Actually, I know that this information may be not new for you because I've seen a link shared in a Facebook group of Bangalore brand and developers. And the link explained the stuff. But for those of you who need some proofs, I placed the link in the slide. And you can check out and see how avoiding cascade helps with rendering. So that's all, the idea of independent CSS blocks. And now who uses this? Of course, this is ours, Yandex. You can see link in the slide. This is for those who would like to have a deeper dive into this stuff. This is my previous presentation given in Riga, Latvia. I turned it into a very well-illustrated text. And actually, now it's an article. And it explains at length what to do for implementing independent CSS blocks and why. Also at GitHub, guys faced the same problems in CSS. And they came up with very similar solution which you can learn from the link again in the slide. This is their slide from presentation where they explained their solution. Then I'd like to introduce you in the CSS framework by Harry Roberts. This is a guy from United Kingdom. And it uses BAM principles to develop his framework. And also he published a lot of articles with explanations. And of course, I can't help mentioning very famous object-oriented CSS and smart frameworks which are also modular solutions in CSS. It's actually a very fashionable item. And now to the next wish is as many programmers, maybe all programmers, would like to avoid copy-paste when developing. And actually, you can use an obvious way to achieve this. Just detach blocks into separate CSS file. And so you won't repeat similar pieces of code. With such detaching, you can have a bunch of blocks in your project. And then you can use these CSS pieces to build up your CSS for pages using an input keyword. Now that makes it possible to share code with friends, emailing, or even better, you can use version control system to store your blocks and share with everywhere. This is how libraries or blocks can be linked to a project, to several projects actually from a library's repository. But again, when doing this, we can face a new problem because services, websites, they are not the same. They are a bit different. Even services of one company are a bit different. And so we need somehow to provide changes from service to service, somehow tune blocks from the library. And this is where I need to introduce you the first term, I promised the last, which is block level. Every bunch, every group of block is a block level, and the library itself is block level. But the same service can have its own block level and somehow tune blocks from the library. Let's see how that can happen. You can see that code from the library is linked to the project, and the project itself has some code. And then you can see that library can provide header block, red-colored. And at service, you can redefine block from the library and make it green-colored. And of course, when building pages, you need to take blocks from all the levels so that browser can merge to your implementations and show your service in an appropriate way. I agree that it's not a very good idea to do some such bundling manually. And so I'd recommend to use some automation tools like make, rake, grant, and whatever. As for us at Yandex, we used Gnomec file for such building. But now we came up with our own solution. It's JavaScript-based to run under Node.js, providing command-line interface, and hosted on GitHub. Well, the solution called BEMTools, and it's for many things and also for building pages from blocks. And the third wish is unified semantic. You can see a block here with some dynamic functionality. And you know that that's not enough just to provide CSS, just to link CSS to your page to make this block function. You need JavaScript as well. And those of you who use Bootstrap know that first you go to one place to get CSS. And then you go to another place to get JavaScript. The other solution called Components by TJ Hoverchuk knows that components need both CSS and JavaScript. And so do we at BEMT. We scale modular idea from CSS to JavaScript. And with that idea, you can detach JavaScript logic into pieces and then into blocks and then place JavaScript describing of block near its CSS describing. And it's very useful to place it under block folder, as you can see in the slide. And actually, even better, we can scale this solution a little bit more. And we can use pictures for representing blocks and we can use templating solutions for them and actually any technology that you need. For example, you can use two templating solutions if you need one-for-one service and another one-for-service with a different platform. This is what we used to use at Yandex. You can provide documentation for every entity on your library. And that makes no changes in the sharing scheme because you still have your library linked to projects. So just these three ideas, they brought us to new development workflow. And what's behind this workflow is very simple. It's a very famous idea, divide and conquer. Very famous phrase from history, politics, even from computer science. Only needs something difficult to be done, just divide it into small pieces and go. So do we when developing web interfaces, we first divide the break web interfaces into independent blocks and then we can implement them separately. And each of them can has its own development cycle. With such an idea, you can benefit. And benefits are first a single language for developers of different majors. So your designer, your JavaScript guy, your server side guy, they operate the same terms and that very helps with communication. Then you can get independent blocks which can be easily added to the page. Very easy moved within a page and easily removed. Also, you keep your code very maintainable and that makes no problems if you need to come back to your web interface in a year or two and provide some changes. And what every developer loves to do, you need constant factory code because blocks are independent and there are very weak connections between blocks. This is why we can change one block and be sure that nothing will be broken in the other side of the page. So this is actually why I love them. And also behind the methodology, there are very nice helpers. And the idea of these helpers coming is that I believe that we humans do not like what robots like. But very often when programming, people usually try to please robots, try to make them happier. And this is why we are developing code for browser, to browser work faster, more efficient. But I believe that things shouldn't be done this way. We humans should code for our pleasure. We should code in a very semantic way and understandable for other people. And this is the robots' responsibility to somehow amplify this code and turn it into a very efficient one. So this is why BAM Team produces many helpful tools. The first one is BAM Tools, which I already introduced to you before. Then you can also be interested in Borschick. This is a tool to flatten CSS and JavaScript. Coming back to the last example, as you know, it's not a very good idea to supply a browser with a long list of CSS imports because every import causes an HTTP request and takes time. So for production, you can use Borschick and inline content from these CSS files into a long CSS sheet. And the same for JavaScript. You can flatten JavaScript as well. The next instance, too, is CSSO, which is optimized unlike others. It's very clever. And again, coming back to a previous example, when we tuned CSS at the next level, here CSSO can help to prepare code for production and remove redundant CSS code. And actually, it can do much more, but I just don't have time to explain at length. But you can explore yourself with the link, these tools and many other. And now about recent things we've been working on in BAM World. Well, yeah, this slide was added yesterday. I'm very happy to share with you a link to a Smashing magazine article about how BAM evolved through time and technological changes. This article was published yesterday, especially from Meta Refresh. So again, for those of you who would like to have a deeper dive and better understanding, you can check the article. It's extremely long, but it very well explains what were the problems we faced and why we came up with such a solution. And so things, which are under development now, well, we at Yandex now have common library or our internal library of blocks that provides over 100 of interface components. And what we just decided that this is too many, and we decided to have several block libraries for different kinds of services. Again, we still have common library, but also libraries for search services, library for map services, and so on. It works because with BAM you can link to a project as many libraries as you like. And so here you can see a project using common library and search library and maps library at the same time. And also tuning all these libraries at its level. But to make it function, to make it workable, we need, for every library, we need to provide a website with documentation and examples of every block, how to use it. And also the team developing such a library must follow workflow, which is they must provide change logs from version to version. And it's a very good idea to use unit tests when developing a library. Before, we did it without thinking how to share this solution. But since we have many libraries now, we started to develop a special tool that helps to generate documentation for a library. And actually, this is in progress, but it's the link to its repository. It already has some description, and you can check it out. Well, that's all. Now what you can do with all this stuff. First, you can follow recommendations and use a modular idea when developing any technology, any programming language. It might be CSS, JavaScript, templates, or whatever. And also you can follow file structure recommendations, if you like them. For building, you can use your own tool or just pick up BAM tools, which open source and absolutely free. You can participate in the project, as I already said, and as Jack kindly said also. And why I'm here. I know that there is a lot of IT companies here, and I guess that you also need some distributive solution for web interface. And so you can borrow our experience and implement your own libraries of blogs. They can be either closed source and house libraries, or even better open source library. If such libraries happen, I'll be very, very gladful to share them in Twitter, or when presenting in the future. So, for further information, you can go to our official BAM.info website. There are articles, tools, and explanations there. Now thank you very much, and I'll be happy to answer your questions. Just one announcement with your questions. Be loud and clear. Speak into the microphone please. It's much easier for everybody in the cameras to catch it as well. Shall I go? Hello. Okay. Vincent Hardy from Adobe. Hi. Hi. Vincent Hardy from Adobe. Have a question. Do you participate in standards like web components, or trying to influence the future of standards in that space? I know that there is some work on web components. We checked them, but we just don't know how to explain, but we're just waiting for them to evolve to see if they suit us or not. Okay. That would be wonderful because you have a lot of experience who would be great input to the people working on that. Sorry? Since you have a lot of experience who would be great input for the standard people to know what you found and that might do the way to influence what's coming out of those efforts too. Thank you very much. Hi. My name is Brigitte Schwert. I've been a practitioner of BEM for the past one year, and I like OECSs, and I also read SMACs. My question is not about a technology. It's more about your perspective. You are a UI lead at Yendex, right? So how do you inculcate some sort of enthusiasm or a discipline to new people coming in to practice such good practice or best practices like OECSs and follow SMACs, discipline, or even BEM for that matter? So how do you train them? How do you give them the idea? How do you give them the enthusiasm? Could we please repeat? Okay. You are a UI lead, right? So lots of people work under you. When new people come in, right, CSS is a very broad thing. Everybody just stops writing. It's like a double-edged sword. You can either swing it the right way or the left way. So how do you inculcate or how do you help new people to practice these best practices like OECSs, SMACs, discipline, or even BEM for that matter? So how do you train them? How do you make them happy that this is the right way to do it? Because in CSS you can do it everything in a wrong way and still never realize that that's the wrong way. So is the question about how we teach new people in the team? Yeah, you can answer that. It will solve it all. Actually, in Russia, BEM is very popular and sometimes there is no need to teach. But this is because we, BEM team, take part in many conferences and provide many content in Russian. As for people who are not familiar with BEM, when they come to the team, actually the benefits of BEM become very clear to them, then we face our problems at Yandex. And so they just open documentation site. We have our in-house library very well documented. They just open the site and learn from it. Mac questions? Yeah. Yeah, I have some questions on Twitter. Woodstarp gives a robust and maintainable framework for the company with BEM. Actually, we cannot compare it because Woodstarp, as you said, Woodstarp is a framework and BEM is a methodology how to build your own framework. So you can build Woodstarp with BEM. And for an example, you can again go to a website and there you can find library code Woodstarp BL. This is Woodstarp components implemented according to BEM principles. And I'd like to be clear that BEM is not a solution for fast development web interface. It's a solution for managing your team work and for development maintainable web interface. And it does take time to develop much more than just using Woodstarp. I have a question. So how does BEM, I mean, what's the right way to version your blocks in the sense that let's say I have a header block today, which is a bit loud. So I have a header block. So today it's a blue color header. And tomorrow I change this to a green color header, for instance. Now team A is using the old legacy header block, which is blue in color. And team B has a green color header, for instance. So would BEM tell me to write a new block completely different? And or does it actually have versioning in place for this kind of a problem? Hello. Thank you for the question. We also, BEM is not just a methodology. We have special tools to develop with BEM. And they provide us possibility to just start development server, which check the libraries changed and your local changes and build the final runtime together. So when library developers change something, you just can refresh your page in the browser. And if you didn't freeze on the revision of the library, you will get new code without any troubles. And it's not just for CSS. It also will work for JavaScript or even templates. Again, a question from Twitter. Modular CSS is making markup and painting heavy. How to strike the balance? I guess this question was answered before I presented optimizing tools. And this is the idea of programming I introduced. We develop not to please browsers, but to make it easier to code for ourselves. And this is the next step to optimize code to make it not so heavy and much more efficient. Did answer? Hello. Hi. I just wanted to ask, you have a tool, Bosch Check, that flatten CSS. Do you have a similar tool for JS, for JavaScript? It's the same tool. How do you deal with namespace, collisions and things like that? Again, please. So in JavaScript, it's a little more complicated because you can have the same function name in different blocks and things, correct? Let me try to answer. Actually, Bosch Check is a universal tool that could flatten everything that is a text file. So for example, CSS and JavaScript is some sort of APIs or plugins for it. So actually, it doesn't resolve some namespaces or just flattening the files. So we're trying to write our blocks, so there's no garbage in some global spacing. So our blocks are usually clustered with some sort of closure function. So you basically put it inside a module? Yep. So do you use anything like RequireJS or any standards around modularization of JavaScript? We don't need this because we use Bosch Check and as for developing, we use a special command provided by BAM tools called BAM server and it flattens when you're developing. You can change file and then refresh a page and it immediately flattened all what you need. So this BAM server, you'll be running on your machine so you can check to see if there are any collisions or things like that. Yes. Okay, cool. Thank you. Hi. Hi. So I wanted to ask you, when you started off your talk, you mentioned about the old process where you make Photoshop and then HTML, CSS and everything, right? How does this change that part of the initial part? What does the designer who works on Photoshop have to do differently to adapt to this process or does it not matter to them at all? So if these roles are united in one person, yeah, I know that happens very often but again, these are different roles and when switching from stage to stage, when changing your role, you again have some losses and with BAM, it's easier to keep focused on the components themselves and not on the technologies because with BAM, interface components, blocks, they are primary and the technologies which are used for implementation, they are secondary. Hi. How easy or difficult is to use other people's code, like other libraries with BAM? A bit loud. How difficult is it to use other people's libraries or code with BAM because they are not going to use similar standard as yours? Well, for the new developer who is just trying to learn BAM, it would be a bit harder but when you will learn how to manage with it, each new library will be just yet another level of blocks. So in comparison, for example, with Bootstrap, you need to find CSS JavaScript and maybe some images for any component you get from there. With BAM, you need just to take block definition and BAM tools will find CSS and JavaScript for it and build it to your website without any troubles for you. I think that if you have any further questions, I'm going to ask you to chat with both Vladimir and Vara Vara. Actually, we'll be at Meetup on Sunday and Vladimir, the first one, will have his workshop about how to write JavaScript on BAM and also after that we'll have a long question answer section about BAM and you can prepare your questions in advance and then ask there. Also, I'd like to advertise a bit. We have some nice stickers which we can share with you. I'm going to leave them at the tea table and you can pick up. Speaking of tea, it's lunchtime. So lunch is downstairs, make a U-turn, it's on your right-hand side. Just make sure that you're back here sharp at 2.15, we'll start the next session which is Akash's, sharp at 2.15. Thank you very much. Thank you.