Hi Varya
thanks for accepting my invite, after the nice chat we had, eating coconut and chatting about CSS on a terrace in London.
[For a series of lucky events, I was trying to contact her for the interview, while at the same time Daria Bogomolova and Konstantin Dzuin invited her in Badoo. A sign of destiny, probably.]
Thank you very much for this interview opportunity :-)
Can you tell a little bit more about you? I see that now you work at Zalando, right? And previously you worked at Yandex, where BEM was born, and you were one of the big contributors to the promotion of BEM.
Ok, about myself. I am Varya, originally from Russia. In there I have worked for Yandex for 5 years and I was part of BEM team.
We were solving the problems of sharing CSS and JavaScript components across a huge company with hundreds of projects.
Part of the findings were moved into open source, under the name BEM.
Lately, I continued focusing on modular web development. Bringing this practises into the working process was a part of my work for TMG (Amsterdam) and SC5 Online (Helsinki).
Currently I work for a German Zalando, but in Helsinki tech hub. In here, I also hope to develop modular frontend solutions.
Most of the people (actually me too, before doing some research for this project) thinks that BEM is simply for CSS, and in most of the cases that is just about naming conventions.
But from what I understand, it's more complex and involves much more than CSS. I see in the BEM documentation and the Yandex github repositories that there are BEM tools, there is BEMHTML, BEMJS and BEMJSON.
It's more a high-level methodological approach and at the same time a tooling stack/infrastructure to build modular UI components.
Also on the official BEM website, the methodology is just a part of the whole: there is also a toolbox, a platform, and a community too.
Can you explain a little bit more about how BEM was/is used at Yandex, and all this BEM-thingy? I mean, creating a front-end using BEMJSON was completely a surprise, for me!
Yes, all you said is correct.
But to explain it we should go back in the history a bit :-)
Yes please, do it. :)
As I remember it was back in 2008. At Yandex, we already had hundreds of projects which we wanted to be under the same brand style.
However, we supposed that delivering just CSS styles would not be enough. CSS matches with the HTML markup, and often in a component lifestyle this markup can be changed through refactorings or in the new versions of the components.
To deliver CSS-only library would have caused a lot of pain when switching from version to version for our in-house library customers. If you have to imagine this kind of pain, think about new versions of Bootstrap :-) And multiply it by 1000 due to the bigger size of the library and the amount of projects.
This is why from very beginning Yandex component libraries included the templating solution to produce HTML markup as well as CSS. By that time, it was XSL.
Soon after, we decided to offer the JavaScript functionality for the components as well. So that every component would consist of 3 parts: CSS, the needed markup (generated by templates) and the associated JavaScript.
The whole idea was a higher abstraction for a web interface. As a user sees the interface as a whole piece, a developer should consider it pretty similarly.
The customers of Yandex UI libraries described the web pages they wanted to get as XML files where instead of complex markup with attached CSS and JS, they just wrote <bem:this-awesome-component please="yes"/>.
The BEM tooling knew how to read this XML declaration and build proper HTML, with the needed CSS and JavaScript for it.
Before BEM became public, we made a huge shift from XML technologies to JavaScript and JSON, as it seemed to be the web's future.
But in principle it was similar. A library customer described the desired page as a JSON file, where the needed components were nested JSON objects.
Then, the tooling read this file, and applied the templates. This time it was JavaScript-based XJST (aka BEMHTML). As a result they got again HTML, attached CSS and built JavaScript.
Well, described this way it's a completely different perspective on BEM. Simply impressive.
And now it makes sense "1000 times Bootstrap" :)
So, BEM was essentially a whole system (not simply a framework or a naming strategy) to solve large-scale problems and deal with this kind of complexity. And I can only imagine the number of developers involved.
But how comes that this approach has widespread across the front-end world and was adopted (we will see in a moment how) by almost every developer and team as THE solution to all their CSS problems, when in most of the cases the projects and the complexity involved were probably infinitesimally lower than the ones faced in Yandex?
Was simply "the right thing with the right appeal at the right moment"? An easy solution for the problems emerging at the growth of CSS complexity? Or there was much more?
And why do you think people took only one part - essentially the CSS naming strategy, and the resulting better modularity - and left out all the rest? Was again a matter of "pick and choose a quick solution to a problem"?
In short, I think it was too complex to learn, while the average frontend problems were not as heavy as we have now.
One the other hand, the idea of "taking some parts of BEM" seemed completely OK. So, it looked logical that people grabbed the CSS part only. It was all they needed to solve their problems.
Also, this fact may be partly explained by the "cultural gap" phenomena.
The full stack of BEM technologies is in use outside Yandex as well. But all of these companies are Russian companies.
In the English-speaking community, BEM is known thanks to Harry Robert's first article on it. No wonder, it covered the CSS part.
We, the international community, are getting more global and close to each other. But still the range of knowledge and approaches might be different depending on the language spoken.
Actually, after realizing it, I started a side project of translating frontend articles INTO English. It would be nice to have all kind of information accessible for all the people.
The project is called Frontend Babel and is available here: http://frontendbabel.info/
From your personal perspective of course, how much do you think this factor of "hype" and "the cool new thing" (which is now becoming an important aspect of our job) impacted on the adoption of BEM?
And on the other side, I would love to make the same question to Harry, let's see if I can manage to interview him too :)
This "hype" was what made me suspicious about BEM, and ended up with me working on a project like "To BEM or not to BEM" in 2016, when it's now a de facto standard for CSS namespacing.
Do you mean "hype" from the company that created it or from all the passionate users of the community?
Well, here come in play the different perspectives you were mentioning above: at the very beginning there was not a community of BEM users, at least not here in London. Its diffusion was mainly due to articles and talks like Harry's or yours, and also at the London front end meetups I clearly remember that - at the very beginning - it was a thing mainly presented in talks than actually used. It was experimental, at that time :)
And then you saw it grow, but mainly because it was "cool", not because there were real case histories behind it.
Which is not bad, let's be clear.
Simply (and we go back to the "1000 times Bootstrap" and problems and complexity at “huge-scale”) there were teams of one or two people, working on a simple project (let's say a small company website), adopting BEM to solve problems that themselves were creating, in the way they were developing and structuring their CSS codebase.
And this lead to the idea (which still persists) that CSS has inherent problems, it's a faulty language.
I think that in many cases BEM was adopted because people was told that could solve a whole series of problems - which is true - but then the developers simply adopted the tool without trying to understand if those were the same problems they were facing.
The same developers that - me first, guilty as hell - took only the "useful" part of BEM without understanding that there was a whole world behind, that you described so clearly.
I don't know if there is a question in this, but do you see my point?
I have very little to say here because I approached BEM from another side. For me, it was a "problem => solution" path, not the "hype => solution".
Yes, true.
I also believe that the people making the presentations mostly shared the solutions which had helped them to solve their problems.
On the other hand, I admit that with BEM we did not have that huge BOOOOM! as we have now in the community with, let's say, React.
From this fact, I came to the conclusion that less people experienced the problems which BEM offered to solve.
What impresses me is that BEM - the Yandex system I mean - was absolutely a forerunner of the modern Atomic Design/Modular CSS approach that we see today.
We still don't have a stable and acknowledged and “standard” way of doing it, with React and CSS Modules (or Atomic CSS), and you were doing it two/three years ago.
Do you know if Yandex is still using it in this way? With BEMJSON and BEMTools?
As far as I know, Yandex is very happy with BEM now.
I guess the logic is the same as I use with my blog :-) Although I'm doing all the new projects with React, the blog is still running under BEM full stack. Because, what's working is working.
I've heard about different experiments like "Angular+BEM", than lately "React+BEM". But I never used them myself.
You wrote the first article that appeared in English on BEM, on Smashing Magazine, titled “A New Front-End Methodology: BEM”.
A few time later you gave a talk at Front Trends, titled “The thinking behind BEM”.
Since them you have always helped to promote the knowledge and the culture around BEM, last in time the project Frontend Babel.
So you can look in perspective at these articles and talks. There is something you would change, looking at them? Or something that when read today makes you smile, or makes you think you were wrong on something, or makes you feel surprised by how far all of your (and other people's) work has gone?
You compared BEM to React, well from my perspective, BEM is as famous as React, and it surely has a wider adoption!
Indeed, I would not write the same article and give the same presentation now. At least because nowadays we have different open source tools and technologies which did not exist by that time.
As I said, I personally do not use BEMtools and BEM JavaScript approach for the new projects anymore. I currently use React and Webpack to solve the same problems. This is because besides the tools' technical characteristics I also value their image in the community and the accessibility of information about them.
However, I did recently try to solve the same problem as BEM full stack had aimed to solve long ago.
I mean the problem of broken markup when switching the component library versions. BEM was an automated solution to it. If the markup is produced automatically, it won't be broken. In my recent projects, I tried less automated but more "help a human" solution.
Ahahaha “Help a human”. I love it!
I'm talking about building the code-reflecting styleguides and later using them for visual regression testing.
I had a blog post about it, published in the SC5 Online website: https://sc5.io/posts/visual-regression-testing/
Yes, I saw you are working a lot in this space.
So, the idea is that we do have some room for an error. The markup may get broken. But we also have a process and the tools to spot it very quickly, before the release.
This approach is less rocket science and mind-blowing as BEM. But I found it extremely easy to get into use.
From this and from BEM experience, I now think that sometimes the solution should not be very methodological and even very logical :-) It should just work.
Yes, one word that comes in my mind when I think to BEM (as described in theory) is “rigid”. When instead - and all the interviews I have done until now confirm it - people adopt a more “BEM-ish” way of using it, they mix it with helper classes, atomic classes, and a lot of "special cases” :)
You talked about the community, and clearly you do a lot for the community. Do you think it still exists the front-end community? Or is it more and more a matter of tribes? Angular vs React, “traditional” CSS vs “modern” CSS, web as a universal platform vs web as application platform, and so on. Where do you find the energy, the commitment and the enthusiasm to share your learnings, to write articles and do talks? And what do you see as response from the community?
I personally love frontend community, I've learned so much from it and got a lot of friends here.
I consider it quite solid. There are indeed "tribes" of different technologies lovers. But I don't see it that strict.
One person can belong to several tribes and the people also migrate :-)
Yes, migrate. Nice word, with a lot of deep meanings nowadays...
The passion which many developers have for some technologies may look confusing for the others. I also was that huge BEM fan, it was almost like a religion. With the new technologies the feelings are a little bit different. I guess I got older and wiser.
But this people, sometimes madly passionate about the technologies, they are the enthusiasts thanks to whom the frontend is developing and evolving so fast. I love this.
However, last time my motivation to the open source contribution was not this young frontend developer madness. It was a rational decision to give back something to the place from where I get so much. And it worked surprisingly well.
So, the main motivation is the people. Those which I have met and those which I will meet. I'm a fan of TDD (Twitter driven development), BTW.
Ah, I didn't know about this interpretation of TDD!
Talking about sharing and speaking, I know for sure - hello Marco! :) - that you will give a talk at the upcoming From the Front conference, in September.
Can you reveal what it will be about? Or is it still a secret?
It will cover the modular techniques in frontend as well. But this time, the ones which are simpler to adopt, I hope. I think you will soon learn more from the conference website and the social channels.
Wow, very interesting!
I'll let you go now. Thank you so much for your time, and for all the interesting things you have said. It's been a very interesting conversation.
Thank you as well. It's my first interview ever. I'm already excited to read it soon. :-)