This is the last interview of this project.
For this reason I have invited Michele Bertoli ("Mee-keh-leh", as he likes to tell at the beginning of his talks). He is a dear friend of mine, we are from the same city in Italy, Brescia, and he's been a front-end developer for a long time. I absolutely trust his opinions and even more his "instinct"; this means that we are quite used to discussing methodologies, techniques, new ideas and approaches to our work.
It was during one of those discussions (whilst enjoying street food for lunch in Hoxton Square) that we ended up debating if BEM was a good choice or not. I was trying to convince him that BEM was not "needed", that there were other ways to solve the problems it was supposed to solve, while he was explaining me how it made things a lot easier for him and how it was natural to read and understand its syntax after a while.
In some way this interview is a follow up to that discussion, and the final thoughts for this project.
Thanks for accepting my invite to close this series of interviews about BEM.
Now, I won't ask what you think of that discussion and of BEM in general, I'll come back to it in a moment.
First of all, thank you very much for inviting me. It's a pleasure and an honour to be part of this project. I miss our inspirational lunches in Shoreditch so much by the way.
I've been recently asked to define myself, and I came out with: "Front End Engineer with a passion for beautiful UIs" which for me means that I know about big-O notation, but I love writing HTML and CSS.
Anyway, you were right about BEM :)
Well, I don't think I was "right": I was in principle, but in the practice of everyday life I was wrong (and that's what is important, that's the reality of our work). At least this is what my experience in the last year (and this series of interviews) has taught me.
OK, let's talk about BEM then, and this "to BEM or not to BEM" thing. I know that you have been an eager reader of the interviews.
What did you get out of them? What are the "lessons" you have learned, the conclusions you think we can take?
Let me explain a little bit more :) You were right saying that BEM was the wrong (unneeded?) solution to the problem. On the other hand, it became the de facto standard, and I find myself comfortable every time I approach a codebase that uses it.
It is widely adopted and (often) well-understood by developers with different skill sets, which is the biggest win of BEM. I loved this series of interviews since the beginning because it is #forreal.
The key points that emerged from almost all the posts, and contributed to change my mind about the topic, are:
1 - Pragmatism. You interviewed some of the most skilled people in our industry, and from what they say, avoiding unnecessary formalism is one of the keys to their success.
2 - "I use BEM but...". I guess this is a universal opinion. Everyone uses BEM? Nope. Does everyone use their own version of BEM? Exactly. Maybe this is the reason of its diffusion. You can adopt it as a "standard", you can easily adapt it to the needs of your project/team, and you can still call it BEM.
3 - Mixing solutions. Using more than one technique seems the way to go. Using BEM with Atomic, and with other approaches, is something that sounds weird if we tend to be strict. Reading this blog, it seems the way to go if you want to ship code.
4 - Components. Last but not least, I believe this is the central point. Developers adopted BEM because it helped them reasoning about blocks (components?) and elements (components?). Now that we have components, BEM is not needed anymore. In my opinion, this closes the circle.
“Now that we have components, BEM is not needed anymore”. I am pretty sure a lot of people will jump on the chair reading this.
Personally I agree with you, but only if you slightly change the concept: “If you use components, you don't need BEM anymore” where components here is used in the broadest definition as possible (there are many ways to create "web components", each one with its own pros/cons).
Regarding web components and CSS "componentization", nowadays there are many ways to do it especially using Modern™ solutions (you are the expert, probably you can name dozens of them). In your opinion, which one of them has good chances to become in the future a "de facto standard" like it happened with BEM?
I agree: *if you use* components :) And, to quote Adam Onishi: (with components) "[...] a lot of what the BEM CSS technique brings to styling will be redundant". Your question is really interesting, and the answer is not trivial at all.
In my repository, I count more than 45 packages. Someone thinks we are all crazy, I strongly believe it's awesome how in our industry (thanks to the open source) we can create and share experimental solutions to common problems. In this way, we inspire each other and move forward at a very fast pace. Most of the CSSinJS techniques are React-related because React popularised the concept of components and brought a new model of separation of concerns (did you see this?), but the majority can be applied to any library or framework.
My favourite one is CSS Modules, mostly because it's a non-solution. You need Webpack to make it work, but its behaviour can be easily reproduced with Scoped CSS or Shadow DOM. I like it because it made me write CSS again, without caring so much about naming conventions, complex Sass mixin or variables.
Components are small and focused, their CSS are simple and easy to maintain. That's it. I believe CSS Modules (and the concept of "scoped" styles) is here to stay.
If you want to go a step further, and you compose components with a functional approach, there are the Styled Components. I think Styled Components opened the way to a whole new world. The authors, Glen Maddern (co-creator of the CSS Modules) and Max Stoiber, really pushed the concept of components to the max. Why create class names that match 1-to-1 your elements, when you can use components? It's still at the early stage, but I feel that's the right direction for the future of styling.
I agree with you, if today I were to bet on anything, it would be CSS Modules :)
But getting back to what you just said, if you need Webpack or other special tools (in most of the cases) how much is the solution actually influenced by the tooling stack and its evolution? Are you sure we are trying to find "solutions to common problems", or aren't we just trying to find the strangest way to avoid writing CSS at all, leveraging the fact that our tools are "programmable" and so we can take any syntax or declaration of sort and convert it to CSS in output?
Also, regarding this shift from building web-pages to building web-applications, have you seen this tweet by Sebastian Markbåge?
Clearly the web is forking, but do you think the web should "concede defeat" to native applications, like PPK suggested? In my experience, even in my daily job, I think it's the opposite: the web, especially mobile, is growing stronger and stronger every day, while the native apps ecosystem (apart from the big players) looks like it's struggling.
Today we are used to pre-processors, but the first time I saw one I thought: what kind of sorcery is this? That's not real CSS, and you lose control over the bundle? Why should I add a build step to my workflow? Gulp or Grunt? We could split and import partials, create mixins, extend classes. Pre-processors completely changed the way we used to approach CSS, but since they didn't touch the other "concerns" they have been accepted.
Sebastian's post is awesome, and I agree when he says that the future of the web is "very interesting". The web is forking, and I couldn't be more excited. PPK is on point saying that websites are often over-engineered, and they sometimes offer a bad UX (e.g. scroll hijacking) but I don't believe the web should "concede defeat".
My personal feeling is that the web has a bright future and when the platform (as a whole) will be good enough, we should rethink the role of native applications instead. I recently attended a talk by Jack Archibald) that blew my mind about how browsers are evolving and how many possibilities we are going to have in the near future.
Mmm, not sure if I agree with you on the first part of your comment, about pre-processors: of course they introduced new methods of writing CSS, but it was still the same game at the end.
But I want to move on, so it's probably matter for a new discussion at lunchtime. I want to come back to what you said above about the "experimental solutions". I totally get the exploration and inspiration and moving the web forward.
But then these experimental solutions end up in real production code, in real business products. They enter in the "master" codebase of a company, not only in personal side projects.
I don't have problem with that, as soon as a company is aware of the risks and possible downsides of adopting emerging technologies, that sometimes are mastered only by a few people, if not in some cases by the one developer inside the company that wants to try something new, cool and Modern™ and doesn't care (or realise) that then this code will need to be maintained and updated, possibly for a few years to come.
Which at the end is what a lot of "old school" developers contest: that these approaches and techniques are not sustainable in the long term, they are throwaway methodologies that will be replaced by the next cycle of hype.
What do you think?
Wow, this is a fascinating topic. Several times I have found myself in a position where I could choose between the shiny new technology, or staying safe. I believe that having a high level of seniority :) helped with that, but (as you said) it's always a risky decision for the company.
I guess it also highly depends on the industry. For example, when I used to work in creative agencies on short-term projects (e.g. marketing campaigns) I was asked to choose the latest crazy cool stuff. Then I moved to startups where projects are potentially (and hopefully) long-terms, but you still bet every single day on the future of the product.
I firmly believe there should always be a reason for investing in experimental solutions, and that reason should not be that someone tweeted about it.
To accurately answer your question, I would like to share my personal experience (which is the essence of this project). At YPlan, my previous company, I was leading the front-end team, and we have been asked to create a "framework" which we could use to build new UIs quickly. We were developing a new Portal for our partners, and we used to work iteratively, doing a lot of user testing.
For that reason, we wanted to be able to create and destroy interfaces without wasting time and iterate fast. Our primary product was built with React and Sass+BEM. We decided (of course :)) to keep React, but we wanted to take a step further on the componentization and avoid following a naming convention.
The natural solution was CSS Modules. I believe that moving to CSS Modules doesn't require to be brave because, with a simple command, you can extract the CSS (tweaking the class names as you wish).
The "crazy" part was when we decided to try the Atomic CSS. I heard (at FEL) that, with Atomic CSS, you could prototype UIs quickly and that was exactly our goal. On the other hand, we didn't want to pollute the markup with tens of classes. That's why we decided to use CSS Modules to compose our Atomic classes inside the CSS.
How did we know that was a good solution? How could we make sure we weren't creating a technical debt? The first step we took has been building a prototype to see if the solution could work and it was flexible enough to cover all the cases. At that point, the most important thing was for everyone in the team to agree. We shared the demo with the rest of the company, and people were impressed with the speed at which we could create and destroy interfaces (keeping the size of the CSS under control).
When everyone was on board, the second thing I learned is to fail fast. Go and build the most sophisticated interface and see how it goes, don't wait for the experimental solution to pollute your codebase. Timeout has now acquired the startup and lot of new developers are going to work on the codebase.
My ex-colleague Lucas had to do the handover but since we documented all the decisions with blog posts and presentations he didn't have any problems.
To recap, the key points are: - bet on experimental solutions only if they solve a real problem - get everyone on board and document your decisions - fail fast and prepare a backup plan. It worked very well for us :)
Now, let me be the devil's advocate here, because you were too good in your answer :)
Recently I have started to ask myself if all this "code quality", and clean codebase, and refactoring to reduce the technical debt are just myths, or illusions.
What I have seen are two kind of projects: those that once created and deployed are left there untouched forever, and those that are then maintained day by day, month by month, accumulating workarounds and patches and "we'll fix later", and a whole team dreaming of a future moment in which there will be time to do things properly.
But this time never comes because the company collapses (see VisualDNA), gets acquired (see Yplan) or decides to completely re-design the product, and at that point the old codebase is simply ditched and a new clean "master" branch sees the light, just to end up in the same situation a few months later.
So all this principles of maintainability, future-proof code, technical choices that can span years of life cycle of a product, are just a gimmick?
In the end if our code is throwaway, why should we bother to write clean code? Or to fight against the technical debt? Or to imagine architectures and introduce methodologies and care about the code?
Why, in that sense, is Sass+BEM a better choice compared to CSSinJS, if both are intended to never be touched again or be replaced in a few months? (I remember reading somewhere that typically there is a complete redesign/refactoring of a project every 12-16 months, and that resonates a lot with my experience)
I can confirm I've only seen those two kind of projects in my career, too. I always thought I would find the long-lived well-architectured codebase sooner or later. Maybe in my next experience :)
However, to me, the technical debt doesn't only apply to the long term (years). How quick is it to change the code you wrote this morning? That's why, for example, I prefer to use a tool like CSS Modules that scopes the class names for me rather than a methodology, such as BEM, that makes me overthink and spend time on non-so-important things.
I like to focus on building features and creating value for the users; that's it. My goal is writing code that is easy to delete.
Reading the interviews, and you also noticed it, one thing stands out: everyone tends to pick and choose (and adapt/customise) different parts from different methodologies. BEM + OOCSS + Atomic, BEM + Helpers + OOCSS, etc.
Is it the same with Modern™ CSS? For example you have mixed CSS Modules and Atomic. In general do you see people use different approaches and mix them together? Or instead there are clear technical choices, where one exclude the other?
And this also leads to a second question, related to being "strict" or "loose" in how you use these methodologies: everyone does BEM-ish, people use BEM but with "exceptions" and "special cases".
All the naming conventions and CSS methodologies rely on a strong self-discipline of the developers (especially in a team with a shared codebase).
Is it the same for the CSSinJS, CSS Modules and so on? Or does the confines of components allow developers to choose their own syntax flavour without concern of other developers?
Yes, not being strict and mixing methodologies was one of the most surprising things I learned reading these interviews.
I always felt guilty when I couldn't follow the rules for some reasons, and hearing that strong skilled people are doing that made me feel better :)
In the CSSinJS world, we talk more about technologies than methodologies. For example mixing Atomic and CSS Modules is more similar to mixing Atomic and Sass, rather than Atomic and BEM.
In general, I can see people choosing one library and sticking to it. A typical pattern is creating a layer between components and the styling library in a way that components are not aware of it, and it can be replaced easily. For safety, I guess. The fact that CSSinJS are libraries, also means that usually there are no rules or conventions to follows.
As you said, with these solutions styles tend to be small and focused and there's no need for creating complex architectures. This is one of the reasons I believe regular CSS are not the perfect fit for components while locally scoped classes or "inline styles" (co-locating styles within the components) work better.
If you split the components in the right way, you end up having a few styling rules for each one of them and the maintainability is not a problem anymore.
Additionally, most of the solutions generate the class names for you using unique hashes which mean that you can use whatever naming convention you prefer.
For example, you can call a button just "button" :)
That's why I so much like the idea of CSS Modules. You can do the same with BEM or even only with a correct name-spacing, but I have realised (sometimes the hard way) that this doesn't work well when there is more than one developer involved in a project, or at least if not all the members of the team follow the same rules ;)
Now, in the last few months there's been a mounting war between two schools of thought: one that says that CSSinJS is breaking the paradigm of "separation of concerns" and this will take us back one decade; the other one that says that the "C" (cascading) in CSS is a curse and CSS doesn't work at scale.
This debate is getting more and more intense, fiery and harsh every day. I don't know if you feel you're on one side, and if you've been affected by this "war" being one of the CSSinJS representatives.
What do you think about it?
At the beginning of my talks, I always say that Inline Styles (and React) have been communicated in a very strong way. They announced it like "Hey, this is the new cool thing - forget what you learned in the last 15 years" and this doesn't help.
I gave a talk called "Unlearn Everything" where I tried to introduce this mental change, which I experienced myself when I started. At the end of my talks I also say "Most importantly: have fun!" because the attendees tend to get angry whenever the golden rules of web development are put into discussion.
If you think about it, it's awesome how we put so much passion into our job, but it is also counterproductive. We should understand that we are all trying to improve our industry. There's not an absolute right way of doing stuff on the web, and everyone should aim for the local maximum within their teams and projects.
Unfortunately, we can't do too much to fix it I guess. Apart from creating more blogs like this :)
2017 will be a great year for you: developer at Facebook, speaker at React Amsterdam, author of a new book on React. Can you tell us more about your new adventures?
It looks like all the decisions (conscious and unconscious) I made in my entire career are converging into a wonderful 2017.
Joining Facebook is a dream to me, I still can't believe it's true. As a Front End Engineer in love with React, I couldn't be more excited to be part of one of the companies that are pushing the best open source code, and creating one of the best communities ever around their tools. Having the opportunity to work with smart people on a platform that is changing people's lives is the best I can think of in terms of career.
Talking at the React Amsterdam and, more generally, travelling to talk about the things I'm passionate about and meet new people, is fantastic. We should never forget how lucky we are with our job.
Last but not least, my book "React Design Patterns and Best Practices" is going to be published in a few weeks.
I'll do my best to deserve all the excellent opportunities that are happening in my life. I'll keep on putting passion in my job, giving back to the community and I'll never forget the first time I met you and the WEBdeBS people. That single moment changed my life forever.
Well, you certainly deserve all this success :) and never forget, you changed my life too.
I think we can close the interview here. You are the living example that one can choose to follow the mainstream, let's say to use BEM, or to take a different path, let's say not to use BEM, and doing so come up with new solutions and "rules", that maybe in the future will become the new best practices that everyone will follow.
What remains is the excitement, the passion and the desire of people like you to always move the web forward and keep the front-end development one step ahead.
Thank you, Michele.
And that's it, this series of interviews ends here.
I hope you enjoyed reading them as much as I did doing them. And again, one final “Thank you!” to all the interviewees for their time.