Hello Mark
thank you so much for accepting my invitation.
This interview somehow started months ago, when I approached you at Front Trends in Warsaw, to ask you more on what you just told in your talk about CSS Modules and CSS in JS: that in the era of web components, and in your daily work, BEM was not required anymore. Now it's clear to me why, but at the time it was something that suprised me a lot.
Since then I always wanted to get back in touch and continue the conversation, but I was unsure: I imagined you were super-busy, so every time I postponed to later in time.
But this evening I saw one of your tweets, that made me extremely curious:
“Too often we create linear histories of new approaches replacing old ones, ignoring context, tradeoffs and valid alternatives.”
I think I have interpreted it correctly, but can you explain a little bit more what you mean, what you are referring to?
I first want to stress that I'm as guilty as anyone when it comes to creating "linear histories". It's human nature for us to, after the fact, form a coherent narrative out of chaos, which is definitely what we're seeing with open source technology.
Sometimes we have an explosion of new ideas, but eventually the community settles on only a small number of them. Particularly amongst the broader community of those who aren't close to the technology, we want to know who the "winner" is, so we compress this timeline further into a highlights reel of sorts.
This process is especially tempting because it makes for great blog posts and presentations, but at the cost of deep historical accuracy. All the valid reasons why someone would pick an alternative approach, or hold off on migrating to the latest technology, are conveniently left out.
If you're experienced enough in the domain in question, you have the context to understand what's been left out and why, but everyone else is presented with an overly simplified overview of the space.
Ultimately, though, my tweet was as much a reminder to myself to try to avoid falling into this trap, but that's a very hard thing to do. Like most people, it's most likely that I'll continue doing this, but it's definitely worth thinking about.
I imagine you are referring (not only, of course, but firstly) to the recent war of words around CSS in JS and in general the questioning of the "separation of concerns" paradigm.
One of the latest episodes I have seen is this twitter thread, just to give an example: you clearly see two parts, two factions, and probably both parts have good reasons, but we tend to see only where the others are wrong.
That's why I started this project, to show how different people was using (or not using) BEM, how each one was interpreting the "strict rules" of BEM in their own way, adapting and sometimes bending them to their own needs.
And that's ok! As soon as the tools, methodologies, approaches you use can take you to the results you wanted to achieve, it's totally fine.
I think people often reject these new ideas so strongly because they feel like they're being left behind in the linear view of history.
Or, at least, that's what they feel they've been told.
Our industry isn't very good at saying "for your particular use case, what you're doing is totally fine", both in terms of our own work, and the work of others.
100% agree, I could not say it better!
In your talk at Front Trends I remember your slide saying “Documents vs. Web Apps”
I used to think that this was the reason, that at the end the two "worlds" would simply end up living together, coexisting on the same medium in two different formats, as you were saying.
But recently, also thanks to your tweets, I started to think that maybe it's not so simple, it's again a "linear" way of thinking for me.
And so I started to think that maybe what is happening is that the world of the CSS development is undergoing a transformation that the JS world has seen a few years ago.
Do you remember a few years ago when JS was not even considered a programming language, those using it not real programmers? And then the world of JS development was completely transformed by the appearance of web-based applications.
JS became a professional language, with its own dignity and business relevance.
And "standard" patterns and architectures started to appear, and developers somehow stopped to fight one against the other for the "best" JS framework to use.
Well, maybe that's what is happening to CSS too. Nowadays you have “CSS developer” as a specific role in a team (like me, for example). As a community we have started to discuss of CSS Architectures and how to use CSS in the specific context of web applications.
So maybe we are simply a too young community in that sense and we never had the necessary discussion about who we are and what we do.
What do you think? A too naive explanation?
It's interesting. I think once you're accustomed to the component mindset, scoping CSS to smaller parts of your page, you find yourself wanting to use these patterns everywhere, not just on complex sites. If I'm writing a web document, I'd much prefer to build up my own language with components. I think that given enough time, more of the web community will adjust, and the tooling will naturally adjust too.
Right now, though, there isn't much in the way of component-oriented tooling for simpler sites, but we're seeing movement in the space with projects like Gatsby that bring the world of components to static sites. Long term, I can see approaches like this becoming the norm.
Now, getting back to BEM: one of the main positive features of it, is that is very easy to pick up as Katia Utochkina told me in her recent interview, as others before her.
It's very easy to explain, to understand (at least in its basic implementation) and to start to use it, especially if you are a young developer like her.
In your talk at Front Trends, you mentioned “Increased authoring speed, less fear of change, maintainable by default, faster debugging” as main features of CSS Modules.
Now, what is your experience (if you had one, or know of) with the onboarding of junior developers in a team that uses CSS Modules, CSS-in-JS or Atomic CSS? How is the learning curve in this case? Can it be an obstacle in a wider adoption of these techniques?
One of the most exciting things about CSS Modules for me is that it takes the principles behind BEM, but makes it look and feel like regular global CSS.
When you look at it from a junior developer's perspective, it is completely familiar to them. The only difference is that they need to import their classes into a template, which isn't hard to teach at all.
The biggest issue is that it requires more advanced tooling to provide this workflow, but assuming you have the right expertise in your team to set this up, your less experienced developers should have no issues working in this environment.
Automating best practices like this might seem like merely a convenience layer for experienced BEM developers, but I think that its real value is the way that it enforces a more maintainable structure on your less experienced team members without them even realising it.
My next question was exactly on the "problem" of tooling :)
The dream of every front-end developer it's always been to be able to work so tightly with the designers to the point that they can work directly on the CSS, make changes autonomously to the code, and push the changes in production without the intervention of a developer.
But the layer of “tools” required to work on a codebase seems to cut out the designers from this process (you will certainly remember the “Designers should code” argument).
Recently the rise of the “design tokens” has opened new ways for the designers to intervene on the code, but it's not the same thing as writing some HTML or CSS, and is typically a solution for large projects.
On the other hand, I have seen your tweet recently in which you were explaining how the PRs to a style guide automatically were deploying a preview of a static site for testing.
This blew my mind and sparked my imagination about what actually a designer can do with the right amount of tools and automation.
I have seen you're a DesignOps Lead in SEEK, so you build bridges between the designers and the engineers.
What is your experience with the designers you work with? Do they interact with the code too, or do they work only with more traditional tools like Sketch (of course, with a modular/atomic approach) and then it's up to you convert these visual components in actual code?
Exactly. I think we're seeing an interesting convergence towards components for both developers and designers. With CSS methodologies like BEM and UI libraries like React, we're thinking very carefully about breaking our interfaces down into reusable pieces.
To a lesser degree, we're also seeing UI-specific design tools like Sketch pushing designers towards reusable symbols, solving the exact same problem that we face as developers.
There's a real opportunity here for engineering to be embedded with designers, creating living design systems that take the designers' concepts and accurately map them into technology that's readily usable by product teams.
In my case, my job is to get developers and designers speaking the same language. I want to break down the walls between disciplines. I want designers talking about components, and I want developers talking about type hierarchies. In my experience, designers usually don't interact with the code, but I think living style guides could prove to be a gateway for many designers who want to iterate on a design system, but don't want to deal with the complexities of full-blown application development.
Yes, true.
One last question, and then I'll let you go, I promise: recently I have seen more and more interest in a possible integration between a system of Design Tokens expressed in YAML, converted in JSON with a tool like Theo, and then imported directly in a system of UI components that use CSS-in-JS for styling. At this point imagine to connect also the style guide generation and the automatic deploying of a static website, like the one you were mentioning, and you have the perfect workflow. Makes a lot of sense for me.
Do you have any experience with (or have tested) this kind of pipeline, using Design Tokens I mean?
I haven't worked with them yet, mainly because my current work is very web focused.
The further along the living style guide path we get, the more we start to look towards including native applications in the process. Since the technology is so different, having some system of low level design tokens could become a critical way to keep design in sync across platforms.
That said, I'm personally more excited by approaches like react-primitives and react-native-web, leveraging them to build a cross-platform set of components, but of course the challenge there is whether you can align technology across multiple teams to this degree. I take a lot of inspiration from companies like Airbnb that work really hard to build a design system that works regardless of device, and this style of design really lends itself to the creation of a common set of components.
Now that mobile design patterns are becoming more acceptable on the web, this approach starts to make a lot more sense to me.
Any chance to see you in Europe again this year, at some conferences, talking about all these interesting things?
I am! Unfortunately, it hasn't been announced yet, so you'll have to stay tuned ;)
Cool! I hope to meet you there then, and if you come to London let me know: I owe you a beer!
Thank you for the interview.