Zero-Styling Development: Utopia or the Future of Frontend?

Hi, my name is Mateusz Jagodziński, I'm here with the Workflow Builder team where I'm a principal developer, and I'm very excited to be here. So the topic of today's talk will be the Zero Styling Development, Utopia of the Future of Front-end. All right, this might be a big word, but what we will talk about is styling. What are problems with it? What we've encountered in our use case, and how we decided to solve it, which is the zero styling approach.

First question for an audience. Who worked with Figma styles, having to manually implement them into the code? All right, I see some hands. All right, who thinks it's tedious? Okay, who thinks it's error-prone? Yeah. So, as we see, there are some problems with this approach of styling. Designers prefer the beautiful designs, but, you know, even if they don't apply to logic changes, just styling changes, that still can take a lot of development time.

Transferring those styles manually is error-prone, so we often can make mistakes, do this border radius slightly differently and then designers are angry at us. And of course, restyling some component libraries can be painful if they're not adapted to this property. So, let me talk a bit about our use case. So, as we've built Workflow Builder, which is a white-labeled product as such as DK, these issues became very apparent. In our use case, doing changes that are not to the logic but to the styling, adapting the tool for new clients, just changing its branding, slightly adjusting looks was something we did very often.

So, when we designed the Workflow Builder and our underlying component library overflow on top of which it is built, we decided to take this zero-styling approach and tackle some of these problems. So, let me talk to you about what is this approach. So, first of all, it starts with the design, with the design team. We do our designs in Figma. I'm sure many of you are familiar with it. And yeah, the approach we've took is from the start. When designing the components, the designers are not using any values directly. Everything is built on top of set of primitives and numerals that are created to store the actual values and then the values for styles in the components are actually created using tokens that reference those numerals and primitives. It is important to keep everything in this library in that way but it will help us at the later stage.

The next step, I think the most important one, is the automation. So, with Figma, with two plugins like Token Exporter, you can export those tokens and styles and create a simple JSON files out of them. We have an automated script that can turn this into the actual CSS bundle that is being used in the project. So, with a proper setup like on GitHub pipeline, we can make this completely automatic and actually to generate new styles, a designer can do it, right? To get the CSS bundle and get it into the code. It's not even needed for developers' work there. And yeah, then the final step, of course, in the code. When you implement the components instead of writing the CSS, you're referencing those CSS variables from the bundle generated. So, yeah. One important thing to add here is that the, in our components library, the styles import is completely separate from the build of the application so it's entirely possible to, you know, just replace the CSS bundle and restyling the same version of the components.

So, to sum this up, this zero styling has three steps. First one is using the design tokens of the design phase. Another one is creating this automation that enables the designers to actually generate the CSS and update it into the code. And of course, when implementing, we always use those CSS variables. So, what does it allow us to do? Well, it makes ease of, it makes changes of styling in the app much easier, especially for cases like we have where, you know, very often it's no logic changes but just making sure that the workflow builder setup is now following the company branding of the tool that's being used. No errors on style transferring, right? If it's all done by the design team and you reference the token, you can never misspell that one property or paste in the wrong number. And design team can do the changes without the dev team, which is really important.