Andrey: [00:00:00] we use it right now to create most of our application, which you use every day. But it was not created to do this. It was created to create, you know, a scientific paper which you like, share between your colleagues in university. And, um, it shows that front end is wild.
It was not created, you know, like, uh, by some idea, by some plan. It was created by, you know, the spirit of evolution, which, you know, changes the way every time something goes, uh, to another way. And so I like this spirit of, uh, front end, uh, architecture.
Andrew: Hello, welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my Co-host Justin is my Co-host Justin
Justin: Hey everyone, uh, I'm really, really excited for our guest today. We have Andrey Sitnik on, uh, Andrey works as an engineer at Evil Martians, which if you go back to episode 56, uh, we did an episode with them. Um, and you're such a, just a huge force in open [00:01:00] source. So it's incredibly exciting to have you on.
You've done tools like auto prefix, post CSS browser's list. I mean, it is, it is a long list. Um, so tremendous, tremendous honor for us to have you on. But before we get started, would you like to tell our guests a little bit more about yourself?
[00:01:17] Andrey's Background
Andrey: Thanks for nice introduction. Yeah. Um, so as you mentioned, I created a few tools which work with css, uh, also with C R D T. And right now my main point of interest is OKLCH because I really like how it works with the color. It's not because it's like a big, a huge topic, but since it's nice way. Uh, right now I live in Barcelona and like yep.
I work in at Evil Martians.
Justin: That's so cool. Um, so it, it's really hard to state like how big of an impact that you've had, especially in the web space and open source tooling. ~~Um, how did you, ~~how did you get started? Just like doing open source stuff, uh, was that, did that come out of Evil Martians or was that just something you [00:02:00] started before?
Andrey: No, I started, uh, as a developer, as a open source, uh, developer. Like it, I don't know, like it was, you know, inside my like way of living. Like, it's one, it was one of the reasons why I came to software developer, not because it has a lot of, uh, big salaries. It was like, you know, uh, late, uh, nineties, uh, beginning of 2000, which in Russia we don't have a lot of money.
But, um, it was like, uh, it was a magazine called The Hacker. It was a magazine about, you know, hacker culture. Not, you know, a criminal culture like in computer industry, but about the culture of, you know, um, using a tech to embrace yourself. Like similar to Defcon, like if you want to have the spirit go to Defcon conference, like the best one.
And as a result, the spirit that we should own, our systems that we should know, own our data, is become part of my personality. And it's result that, like I started [00:03:00] as. Being internet in as a, uh, administrator in Wikipedia. So open source, not only about the code, it's also about, uh, knowledge and many other things.
And so like open source was the way how I go to the commercial program, not opposite way.
Andrew: So did you, uh, did you go to school for computer science or did you just get into it outside of school?
Andrey: There was none, uh, of the school in the,
Andrew: Ah,
Andrey: in Russia at that moment. There was only, uh, schools, you know, about the algorithm and you know, all this, you know, university, computer science, rocket science stuff. Uh, but uh, yeah, I just read a specification like TCP specifications, CSS specifications, translation to Russian, to Russian.
Justin: That's a, that's an interesting path cuz it seems like, you know, especially for, there's a lot of people when they're getting started, like reading a specification for example, is a, can be a kind of a, a dense, dense thing to sort of like wrap your head around. So [00:04:00] that's a, that's definitely a, you uh, had a pretty high learning curve there, I'm sure.
Andrey: Yeah absolutely.
Andrew: Uh, do you remember the first open source tool you got started in? Uh, cuz that sounds like that was a pretty long time ago at this point,
Andrey: Oh yeah. Yeah.
Andrew: yeah.
Andrey: It was, uh, um, the tool for education through the internet, like as we have everything right now. It was like, uh, project like this, but it was, you know, a school project, but it was an open source. I had an account sourceforge, it was like a GitHub, but in nineties. So like, uh, I had a few projects there, like, uh, also it was, you know, um, We call it, we could call it like next js, but you know, in eighties, like when you like, don't have like a, it was a fast CGI system, which like serves static, uh, HTML without, uh, run, uh, runtime.
Things like, eh, no, it was a small and shitty project.
Justin: Fast. CGI used to be [00:05:00] all the rage.
Andrey: Yeah.
[00:05:02] Browserslist
Justin: about some of the like more recent, maybe more well known projects that you've worked on. So there's a whole birth of them. Uh, one that would be really interesting to talk about is browsers list. Um, so this has been, uh, a very important tool in the like polyfilIing space or translation space.
Uh, could you sort of explain what it is and what the motivation for creating it was?
Andrey: Uh, this project is not maybe a library, but of course this is a library. But the idea is that this is a config. So this is like a convention that we have a single place to describe our target browsers. So the browsers which we support as a project, um, the like initial, it was, it grew through, uh, from the autoprefixer.
So like, um, in Russia we have a very popular, we had a very popular browser called opera. It was technically Norwegian, but was [00:06:00] very popular in Russia. Much more popular than an internet explorer, like other tools. And, I like I felt at that moment that. All developers, they're creating a website for the American browsers.
And nobody cares about opera, but like it's very popular in some other countries. And we face this like unfair condition. And as a result, when I developed autoprefixer I thought that if, I will give users, options to select just a version of each browsers, edge, Chrome, firefox, people in United States will think only about browsers popular in United States.
And this like unfair condition will continue as a result. I thought about some, a way to describe a policy of the browsers which we support rather than versions. So for instance, like last two versions, or like more than 1% of popularity in my country, or like in my statistic of my site, or [00:07:00] like browsers which support, uh, esm uh, yes models for instance.
And this is a config. It's a config with a special, like high level curse where you can describe your policies about the browsers. It was created to be like ported to any, um, languages. For instance, we have a port to, uh, to rust, but right now the like, uh, JavaScript library is the main way to use it. And so it used in, uh, it used by autoprefixer by baby, baby present by, uh, post CSS present and many lin and small tools or, or also by like lighting CSS and other tools.
Andrew: Yeah, it's, it is really become like a defacto standard. I probably wouldn't have said that maybe like five years ago, but like now, it's like every single tool supports browser list out of the box.
Andrey: I hope so, because it'll make our world much better place.
Andrew: Yeah. I find it really interesting that it was created to support opera of all browsers. [00:08:00] Like I, if, if you would've asked me what browser it was to support, I would've guessed like Firefox or like maybe Safari, but that's, that's cool that it was opera.
Andrey: At that moment, Firefox was very big, big market, as fortunately, not right now, but like I really, I really hope that it'll grow its market place.
Andrew: So do you think that the, like, uh, like years ago, support for the various CSS properties was very like fragmented. There were many like Like browser specific, attributes that you had to have. But as time's gone on, things have really consolidated into like one set of rules and nothing like is prefixed at all anymore.
So do you think going forward, , a tool like browsers, li browser list will become less, less useful or will we kind of always need it around there to help us fill the gaps between the future and what we currently have?
Andrey: Um, I think that we always will need a browser list or some similar tool because it's not only about the [00:09:00] vendor prefixes and CSS for instance, or like even the polyfils. We always will need a polyfil, this is like how people will work, but um, we also need a single place for a new developer coming to our projects to go and to check what browsers do we support.
So this not only for tools, it's also for the people like, um, a single place.
Justin: Yeah, that's a really interesting point. Uh, we talk about this a lot when we talk about. Like type systems, right? It's like the type system is for correctness sake, but it's also sort of like developer documentation sort of. So this is an interesting thing because~~ I,~~ I've, you know, had a lot of jobs in the past where it's like, we had this question.
It's like, well, what browsers do we support? And, and having this configuration to say like, this is specifically the browsers we're targeting is a Yeah, it is, it is very valuable as a sort of like documentation too.
Andrey: Yeah. But Andrew, uh, writes a very interesting question about the vendor preface and css. Uh, the funny part when I just created, uh, autoprefixer, [00:10:00] like just a week, uh, before the chrome announced that they will not add any preferences in the blink engine And, you know, like I creating a tool like Autoprefixer is a tool which add a vendor prefixes to css, and I creating a tool which already that like, it'll be not like useless, uh, it'll be useless in, uh, just a few years.
And as the funny part, this is a project which like, I hope it'll die. I don't want to support it. I don't like, it's, we should be in the place when we don't need such tool. But unfortunately I still can't remove it from my production projects because we still have a few small properties which nobody remember.
And every time they create a problems for, front users, especially, you know, for, uh, browsers like, um, Samsung or like, um, uc, browsers very popular in Asia region. So as a result, we unfortunately still need auto pre fixer, but I agree that like at some point it should be dead.
Andrew: That's, that's fun to hear that you want your own tool to die.
Andrey: Yep. Yep.[00:11:00]
[00:11:00] Autoprefixer
Andrew: Uh, so, uh, before, before we move on to other tools, did auto prefixer or browser's list come first, or did you guys have like the foresight to go, oh, these are two separate tools and let's, let's build them separately?
Andrey: Initially it was, I think, uh, a rework prefixes. So like, it was a post CSS like tool, which called Rework. It was the idea, uh, from TJ Haverchuck. And so it was only a plugin for, uh, work. But I very, uh, quickly found that like, rework does not solve problems, which we need as a like, basement for autoprefixer development.
And I started, uh, autoprefixer as a tool. And then I understood like it was, it was during, uh, um, my conversations with um, uh, compass team. So they have the same prefixer feature, and so they, like, I found that why we have, uh, config only for auto prefixer. Why not also for the Compass, it was a project for SaaS world and as a result it was created.
[00:12:00] Like I just split this code from autoprefixer, just to be, so this code will be used by any other front end tool?
Justin: Yeah. So Compass was a ruby, it was like in the Ruby ecosystem, right? For, yeah. Yeah. nice.
Andrey: yeah, yeah. This is old.
Justin: talked until
Andrey: Okay. Boom.
[00:12:13] PostCSS
Justin: it's been a while. Yeah. That's cool. Blast of the past. Yeah. Cool. So, uh, yeah, let's, let's talk a little bit about post css. Um, post CSS is another one of those tools that's been hugely, uh, hugely influential in the ecosystem.
So, um, I mean, I, I think about, we were talking about Compass and SaaS. I mean, I think about like, you know, in 2010s, it's like mostly using like less and SaaS and stuff like that. That was like primary usage. And now pretty much every project that I use uses, like post CSS almost exclusively for a lot of the transformations.
So, um, let's talk a little bit about the origins of post css. Like what was your original goal for the project?
Andrey: Yeah, but like, uh, one small note, even if you don't use postcss, like, uh, obviously if you don't, uh, know that you're using it, you [00:13:00] very likely use it anyway because like, if you use Webpack, it's already a postcss so like, it's mostly another project. So initially it was only a framework to create a tool, like auto prefixer.
So initially it should not be like, uh, and, and develop like end users developers should not like, know about postcss, they should know about styling, uh, auto prefixer server pack. So it should be hidden. But I very quickly found that people afraid to add a new CSS processing tool to their project. And so initial idea was, so~~ I, I, I,~~ I need the fork of rework to do like much more complex stuff as a basement for the pre fixer.
But, uh, also it'll has some philosophy. I, I need, I like, I want to have a world when we as a community control css, like right now it's like there is a CSS working group and they do stuff, the browser do stuffs, but we as a developer have no way to [00:14:00] like, I don't know, test a new feature or like, you know, suggest a new idea.
We have it, but you know, it's not in how people think about the css. And so I want to like, encourage people to think about CSS as the tool that they own. And so encourage them to create a many protesting tool around css. So like, you know, be creative, be fun around css, or for instance, like create a poll of fields before we will implement this, this feature in browser.
So we will able to test it and, you know, fix some issues, some problems, develop an experience problems, uh, before it was, you know, frozen to the browser implementation. Like we can't change browser implementation because we can broke the, we can break the web. So as a result, it was, you know, I found that many people, they're afraid to add a new CSS tool to their projects because, you know, it's something new.
I don't want it, you know, it's very afraid I not be able to convince my [00:15:00] colleagues. And so this is why we put the post CSS in the first place. So like, uh, like, like a end user tool, because we like want to encourage people that, you know, you don't add a new tool, you just add a new plugin to your existencing tool.
So don't be afraid, you know, go crazy, do some, you know, crazy stuff with your css. Like start to write SVG directly, your css, and then we will write, uh, CSS a specification which like will allow it like officially. And so, like, this is the story of post css. So post CSS is a framework if like, for people who want to do some automated work with css.
Uh, find some issues, change one syntax to another, or like, you know, do some boring stuff like in lying images.
Andrew: Yeah, it's, it's, it's cool that you guys had that realization because like definitely at the time, like there was a bunch of tools that all did kind of the same [00:16:00] thing but didn't really plug together. And then to go like, no, we're gonna create one tool that kind of goes across the board and you can plug all these different things into, yeah, I can just, like, there's no way I would add like a whole new tool to be like, oh, let's try out some CSS variables before they exist.
But adding a plugin, no brainer.
Justin: It's really interesting because I feel like this is a lot of the stories that the, the trans, the trans pilers go through, right? So it's like they start off as like solving a very official problem. Like, you know, six to five, uh, before it was babble was just like, really is like, we want to compile this, you know, es six down to ES five or whatever, make it like more compatible.
And then it turned into, you know, what Babel is today more of a like rich plugin ecosystem where you can sort of, you can leverage all these things, but you can also do what you want and then, It seems like post CSS goes through that very, very similar story. And I think, you know, thinking about the tools of this sort of previous generation, a lot of what we had [00:17:00] were alternatives that compiled down to the target.
So, you know, we had sas, we had stylists, we had less, uh, just like in the JavaScript world, we had like coffee script and like, you know, pure script and a bunch of other options that compiled into JavaScript. So it is interesting to see that over time we've leaned more and more into like these compilers, these pluggable compilers for like integrating into the web.
So,
Andrey: It was also another interesting small revolution there. Uh, like all these tools, like, uh, postcss Baby or like MDX Rework, they was created on the idea of St. Transformations. So like, uh, we have a partial, which do nothing, just only a par to the, some sort of three of objects. And so every plugin just changes this three of objects.
And then we have a special tool which will serialize it back to the string and then create a source map, you know, like fix the spaces, et [00:18:00] cetera. And, um, so like, uh, process was, uh, part of this, you know, like, uh, A revolution, which was put to many people's mind. It was, you know, some strange feeling when a lot of people, uh, came to the same idea in the same moment and start to create the same tool, but for any different languages.
Like remark was created for the markdown, like the text was created even for text, or like html. So we have, like right now we have a bunch of st protesting tool, and I really like this. You know, it was fun to create all of them.
Andrew: Yeah. And it's fun to like learning it too. Like, uh, if you learn one, it's like you learn them all. Like they, they have slightly different, uh, syntaxes, but just getting the idea of like, oh, code becomes an A S t, I can manipulate that. A s t is so powerful.
Andrey: Yep. I, uh, I hope that maybe in some moment we will be, you know, use more, uh, like tools like, [00:19:00] uh, lis or like Closure Script because you know, in the languages, the whole program. It's just an st written on this program like, uh, structure. So you, you have the ist of your code written inside your program and you don't need a parcel to change something.
Can it? It's like crazy. It's very crazy idea.
Justin: Yeah, that's a cool idea. I think a another interesting point is about how all of these tools are the same. They also have some of the same problems that we see across the board. Some of the trade-offs that we make about giving users the ability to add plugins is, you know, how do we execute all of these plugins to transform this A T A S T, uh, performantly, uh, which, you know, depending on how many.
Plugins you have and like how many of these compilers that you sort of mesh together, especially when Webpack was like more heavily used, we'd see like longer and longer build times. Cause it was like going through, you know, loading all this code and sending everything to like, convert it to [00:20:00] an AST, transforming the AST over and over and over and over again, you know, and like finally spitting something out.
[00:20:05] Post-PostCSS
Justin: Um, so definitely the, the space seems to be changing. There's a lot of people leaning more into like native code, uh, than, than sort of ever before. Um, have you thought much about that in terms of post css? Maybe, um, like what modern version of post CSS might be look like or what the sort of next iteration of it might be?
Andrey: Uh, the important statement, uh, just immigrate to lighting css. It's just better post css. It's already written in rust. It's already have a much better architecture and, uh, like, uh, Devon to solved many problems, which we have, uh, part of the core, which we could not, you know, fix without broken picking changes.
So just go to lighting css. It's much better in every terms. Maybe, you know, just wait a little to create, um, system, like to put it inside your project if you have some, you know, complex situation or like [00:21:00] maybe continue to use post CSS as a tool for hacks and, you know, a new plugins, which will be hard to write in a rust language.
But, you know, this is the way. So, but, uh, it's very important to understand that as a performance. Uh, it came not from the. Uh, native language. For instance, there is a very interest project called CSS 3. It was, uh, written by, uh, Russian developer, and, um, it was written on JavaScript and it was about three or like five times faster than post css.
And the reason of it was because he work very carefully with the memory and the garbage collector never called during the Parson. And it was extremely good in performance. And as a result, like, um, it's, it was very good example, that optimization. It's not about, uh, native languages, it's not about the language at all.
It's about data structure. Or there is also another, uh, Crazy story. Like [00:22:00] initially, like in the moment when we, wrote post css SAAS was written in C++ and should be, 5 or 10 times faster because it's C++ everything is faster in C++. But, the, funny part that we was about two or three times faster, even the four in some moment than C++ version of the SaaS.
The reason was that we like was able to hack the compiler very quickly and to experiment with some funny parts. For instance, we separate tokenizers' and parser and do really Black magic , really like bad things, with tokenizer which nobody should even repeat or, try to read. It's like really black magic, but it increased performance dramastically And because we put all this black magic into the small part of our tool, visible, to put it to the black box and forget about it. yeah, we have, different parses for post css. For instance, you can parse SaaS code or like any other way to write your css, for instance, CSS and [00:23:00] js. It could be parsed by post css and, apply some changes for instance, like format, et cetera.
And the funny part was that, uh, when I need, uh, tokenize to tokenize SAAS languages, it just needed a few tiny changes. I just copy paste this like black magic token and do, you know, uh, changes in this file at like a patch patches because like token was written in so black magic ways that it was impossible to, you know, do like a proper programming when you like, extend to new languages because it was written very bad.
So I think like use lightnings and a good example, which like a good lesson, which like we found when we, uh, create like ecosystem of post css was that, you know, uh, before we have a tool which have all, which had all features built in. For instance saas. You have only this small amount of feature and no more. Or like we created post css says in [00:24:00] another way when you have nothing in the core and like everything which you want to do need to be added by, by a plugin, but we found that both this way up wrong and we need to know a third way, like in Buddhist ways, uh, of thinking we need a way when we have a small predefined list of the plugins.
Which, you know, like, uh, meet, uh, 90, 80% of the developers and if you don't need them, you need to disable them or enable some extra plugins. So this is, uh, like issue which we found in ecosystem of post css, but it was a moment when I don't really want to solve it. And I really like that. Uh, devon finally like, took that, like, took the flack of creating the best CSS processing tool and it will be finally free from, you know, maintaining as Post css.
OpenSource is not fun.
Andrew: I love your take on this. Like, I, I definitely am in the same boat of I want to maintain less and I just find it hilarious and awesome that like two of your biggest tools, you're like, [00:25:00] please let them die. There's
Andrey: Yeah,
Andrew: things.
Yeah. That's funny. We were gonna ask you about Lightning css. Uh, it seems like a really cool tool.
Justin: yeah. So Lightning CSS came out of parcel, right? It was, uh, Devin's like, I remember when he was like packaging that up and like trying to name it or whatever. And it's really awesome to see it sort of grow in its own. It's, it's a really cool project. Um, and to the performance point earlier, this is a conversation that we've had with several people. I think we talked a lot to Jared, the bun author about performance, and it was a very similar sort of thing. It's like performance is sort of language agnostic. Like you can write really unperforming code in any language, or you might perform it code in any language.
It's just like, you know, there's a lot of work that's went into like V8 in particular to make it really, really fast. Uh, it's just like you have to know how to, you know, really leverage that. So that's cool.
Andrey: We speak a lot about, you know, uh, It's tiny optimization, like, you know, [00:26:00] doing a four each loop, not from the zero to X, but from x to zero. You know, it's like tiny faster. But, and we, we have a lot of conversation about like this, like algorithmically perform performance about the algorithm, but in reality is, uh, 90% of the performance, uh, is coming from the data structure.
So I think we should talk more about data structure because this is the key about the performance.
Andrew: Yeah. And when you're a tool that's like super plugin based, like you're, you're only as slow as your slowest plugin. Like I was tweeting about es lin this week, and really I was tweeting about the plugins that I was using being slow and not the tool itself.
[00:26:39] Favorite Plugins
Andrew: Uh, before we move on from post css, uh, you've probably created a bunch of different plugins for post css. What's some of your favorite ones or like some of the weirdest ones that you've done?
Andrey: You know, the funny part that I created, not so many plugins,
Andrew: Oh,
Andrey: the like, uh, I, I prefer mostly, I prefer mostly a plugin for another, like people like of course my [00:27:00] two favorite and plugins, which I use everywhere is Stylin. The linter for css, like, yes link, but for css it's like really good. It's like helped me a lot of solving a small problem.
Or for instance, my favorite way is, you know, to sort a properties of CSS in pre-commit hooks. Of course, not manually. I, um, I heard about the company and like in office they have a list of the order of CSS properties and your pool because will not pass if you not sort them manually in this way. You know, this is a very bad, uh, Team, uh, team leading in this company, like, don't do this, but the, like in general, sorting, uh, um, a property is not by, you know, manually, but by the tool is very great thing because it'll speed up our readability.
And of course readability is the most important part because you will know when the property could be. And so, like, I used telling for this, but also for many other properties or for many others jobs and like, uh, [00:28:00] way to help me. And of course another project is, uh, post css preset and the poly fill created by Antonio Laguna and, um, Romania Manken.
And this is like really great polyfil set because they are really into understanding the polyfils, the CSS specification outside of like, um, CS working groups, maybe they are one of the best people who understand how new specifications works because they need to create a polyfils. And it's really, you know, um, a hard work.
So I think they should be like more presented in our, uh, community of developers. Um, and, um, but like my favorite and a little crazy postcss plugin called Post css easing Gradients. It's a tool like, you know, when you create a gradient, it go linearly. So like the speed of how you change the color, like start on some [00:29:00] consistent level and go like on this level until it ends the final color.
And unfortunately, this is not how the reality works. In our reality, we don't have, you know, a linear anything, like any movements. Of course it has eaing, you know, it start faster from the beginning and then slows, or like, it depends on the like, uh, nature of movings. So if you do animations like Google about, uh, transition easings.
Or like, uh, animations, easings, you can, or you can go to easings.net. Very good example, like easings, like increase, like improves animation a lot, but also it could improve the gradients because even the gradients, you know, like, uh, color, uh, on your, uh, uh, window, like, uh, when you do like, you know, a funny part of putal, you know, gradient of the cars, it doesn't, it doesn't work linearly.
It goes, you know, that in some easy ways and it looks much more better for our eyes because this is more natural way of [00:30:00] like doing things. So amazing plugin. And I think it's one of the, uh, most underestimated plugin. And we definitely should have like the, um, we should change the css. To do the same in browsers because this plugin was created in the, like plugin in the spirit of post css, because after the create, after he created this plugin, he create, uh, draft to change the CSS specification to add this feature because this is how postcss was created.
It was a tool to do, you know, completely crazy the stuff, understand that it's useful, and then put it to css.
Andrew: That's, that's super cool. I'm sure the gradients that of output were just these like blobs of giant css.
Andrey: It's about a 10 lines of, you know, manually adding, uh,
Andrew: Yeah.
Andrey: Top to a gradient. But it's, it's not so bad, but it's fun. It's fun to understand how it works and like
Andrew: Yeah, I was, uh, writing a gradient plugin for a, uh, open source tool that I [00:31:00] lightly manage called jimp. Uh, and I found the same thing. I made a linear gradient and it looked terrible, and then I, then I was like, okay, how can I use math to make this look better? And then I just made it a sine wave, and then like suddenly my, my gradient was beautiful because the sine wave, uh, transitioned the color a lot, a lot easier.
And then I tried to rotate it and my, my life got a lot harder.
Andrey: Oh yeah. This is why I like, uh, front end development, not because, you know, people pay a lot for front end and we have a lot of jobs, but because you know, when you are, uh, creating a front end, you're creating things which will be visible by, uh, users. And so you need to understand the psychology. You need to understand the business.
You need to understand, you know, you are touching every client of your website. Like any small details, like changes the way, how people will feel and like maybe be more happier. After, you know, they see like, you know, a snow [00:32:00] animation when you just don't put like a one Sprite and do animation, but, you know, put it two different and creates a, a parallax effect.
This is, you know, a way of like how I like to be a frontend developers not, you know, um, arguing about what JavaScript framework is about.
Andrew: Yeah. Yeah. I've described my job a lot of the times as I put boxes on screens and like that is truly what makes me happy is making PR pretty boxes on screens with details you might not notice.
Andrey: Yeah, yeah, yeah. On some, uh, I have, you know, a small icon of a bell in my application and, uh, the designer at a, you know, like suggest to add some animation but don't describe how it should works. And so I created a small bell, um, model, uh, from the paper to understand how, you know, the, uh, the small things in, in the bell will like, goes, depends on like, position of the bell because to understand the physics of the bell, like to make animation better and, you know, like it was a, a fun part of [00:33:00] my job.
Justin: Yeah, that's great. I, I, I agree. This such a fun thing with front end I think, is that if you do any traditional, like graphics development, it, it's hard. It's hard to get into, it's hard to be proficient at. Right. And you know, sometimes I feel like, you know, I definitely feel like the web wasn't made.
Initially for the things that we use it for, but it is like approachable enough that we can do so much with it. So it's like somebody can like write some html, you know, they, they can learn that in a few days and write like some basic html and build like a really basic website. And then you have this like sort of master curve where you can like build this really, really compelling experience over time.
And that is, that is nice.
Andrey: Yeah. This is another thing which I like from front end that, you know, we, we use it right now to create most of our application, which you use every day. But it was not created to do this. It was created to create, you know, a scientific paper which you like, share between your colleagues in university. And, um, it [00:34:00] shows that front end is wild.
It was not created, you know, like, uh, by some idea, by some plan. It was created by, you know, the spirit of evolution, which, you know, changes the way every time something goes, uh, to another way. And so I like this spirit of, uh, front end, uh, architecture.
Andrew: And post CSS echoes that. It started
out as one thing and ended up and another. Yeah.
Andrey: It was created to boost, uh, the evolution of css. At that moment, it was, um, not evolving so fast. Right now, I don't have any complaints. Like right now, CH CSS changed so dramatically that maybe a lot of developers, front end developers don't understand that modern CSS is completely different from CSS five years ago.
So right now we don't have any complaints, but, and the moment when css, when post CSS was created, CSS was on some sort of freezing stage and nothing changes there. And so like, it was created to boost evolution, you know, like
Andrew: Mm-hmm. And that's happened. [00:35:00] Like we have container queries now. We have grid, we have Subgrid, we have O K C L H, we have all these like, crazy new things.
Andrey: Yep,~~ ~~
Justin: ~~Hey, on that note, uh, Andrew, take the next section. I'm gonna go grab my remote from my AC and turn it on for a few minutes, so I don't like, I I, I'm starting to bake ~~
Andrew: ~~Yeah. I, ~~
Justin: ~~But yeah, ~~
Andrew: ~~see it. I can see it. ~~
Justin: I'll be right back.
Andrew: Uh,
Andrey: On service I in Miami and like we record a podcast with like, you know, Russian podcast studio. And it was the same thing, like I, um, turn on a AC every, you know, 30 minutes. We like shut down the recording, turn on for the 10 minutes and then continue again because it was very noisy and unfortunately, like it was impossible to even spent 30 minutes without it.
Andrew: yeah, LA Last year I just moved into this place during like the biggest heat wave San San Jose has ever had. It was like 113 degrees outside my house and we were recording an episode and I had no AC and I was just like dying in here the entire time.
Justin: So funny story. I have a uh, uh, a flipper zero. You got one too. Nice. Nice. Yeah, so I don't have, I, my, my AC has, uh, support for remote, but I lost the remote a long time ago, but the Flipper zero has like an AC remote, so I can just use this to turn on my ac
Andrew: ~~Nice. ~~
Andrey: ~~And how do you find, uh, codes which like, you know, you work with your receipt. Do you download it from ~~
Justin: No, it just came, it came stock, uh, it has a universal remote, uh, on it and it just like works. So,
Andrey: Oh, so some sort of
Justin: yeah, I, I think it spams a bunch of codes cuz it takes it, it takes it like three seconds to like, for it to actually transmit. So I think it's spamming a bunch of like AC on codes or whatever anyway.
Andrey: You can speed up it, you can like found like in the on forums you can find, uh, exact codes for your system and like do it
Justin: ~~Yeah, my, uh, my, this is a, a tangent, but my, uh, senior design project in college was building a universal remote control that hooked up to Android. Uh, it was like built with the raspberry pies, a little, little like puck that you could just stick in your room and control. Anyway, ~~
Andrey: Wow. It's cool. It's nice.
[00:35:08] OKLCH
Andrew: Okay. Back on to other nerdy subjects. Uh, so, uh, recently you've done a lot of work around the new color standard OKLCH. Uh, can you describe to our audience what that is and why you might wanna use it?
Andrey: Yep. So, um, to understand why you need to use it and why, and, and how it works, you, we need to understand what, what was changed. So right now we have two big changes in our, um, um, in our designs. Uh, the first one is that right now we don't yet click. We have so many applications. Which have so many screens that we can do like manually every design of every page, you know, choosing, uh, colors by eye by hand.
And right now we have a design system and design palettes where we must to describe, um, system behind the colors. And it, it's really important in developing because it could speed up [00:36:00] a design process like dramatically. Uh, but, and not also, uh, uh, like not only, um, speed up a process of design, but also reduce the conflict between designers.
Because, you know, if you choose a colors by your eye, like every D designers have a different vision and you will have a conflicts. But if you have a math behind all, all colors or maybe, you know, choose, uh, one or like three colors and creates a whole palette according to mass based on this accent colors, it like will be faster and reduce the conflicts.
But here a problem, we need a good math to do a colors. And, you know, colors like they are very tricky things. Uh, initially you think that this is, look, colors are similar to date formats or time formats. You think that this is very simple silk, you know, you know, just put, uh, hours and minutes into your database until you work, but then you find that like it will not work.
The system is very complex and [00:37:00] as a result, if we do, if you need some way to mathematically create your palette, we need a very advanced mathematic, which will work. Unfortunately, hsl, L G b, it doesn't work at all. You cannot create a palette based on hsl. You will create a very big problem in accessibility at least.
So please don't use HSL color model to do color transformation because it's like, it should not be used in this way. And OKLCH is as a format when like, which was created to be, you know, to have expected results. If you change, for instance, hue, you will change only hue in HSL for comparison. If you change a hue you will change a lightness as well.
So this is how, unfortunately it works. Um, so the first reason why we need okay, L C H or maybe a lab, if you know, uh, uh, L c H, like based on lab, is because it allows you to create a whole pallet [00:38:00] according to maas in right now, you can do it even in CSS because in new CSS we will have a way to change, uh, colors a little, uh, by a mask.
And so you can do a really great stuff. You know, for instance, you can define that the way how buttons works is that if you put a mouse on top of the bow, uh, of the button and create a hover color, Uh, the current color of button will in, will increase lightness by 10%. And you can define this mask in css, and then you can like, uh, resume your, uh, color to any color store red to green to blue, and this power color will calculate automatically inside your css.
And like, this is a really cool thing, but we also have another problem. Like I told that ma as colors are very strange things and we, like I said, developers don't understand how complex they are. And to be honest, we should go a little deeper into the colors because like we creating interface, like technically our job [00:39:00] is to put colors to your pixels.
So this is why a colors is like essential sense of your work. Um, but like the funny part of the colors, which maybe a lot of people don't understand, that our screens cannot, cannot render all colors, which you can see in our world. For instance, maybe like many of you like have this experience of you making a photo of sunset.
And then you like show this, uh, picture to your wife on your screen and she doesn't understand why you're so patient about the sunset. It's just, you know, a standard photo of like not creating any feelings. And one of the reasons why it works, because our screens can't render this red, which you saw on, on the beach, and unfortunately it, it goes from the like, uh, physics of our screens, from the pixels.
Like we have a green, red, and blue pixels and we like the, [00:40:00] uh, we can't render. More saturated color that our pixels produce. So like for instance, our pixels produce, I don't know, only 50% saturation of the red. And by mixing any colors, we, we cannot create a 60% of the saturation. But, uh, and so, so, so like, uh, any screens is different, but people create some sort of standard of what colors our screens will be able to produce.
And this standard was created in 90s, it called Srgb. But recently we have, uh, big new scientific research in the physics of producing the colors. And we created all it screens on many other technologies which could produce much more saturated colors. But the funny part, our CSS is limited to SRG B space.
And so our screens right now can render 25% more colors back. Um,
Talking about the numbers.~~ ~~Our [00:41:00] screens right now, SRG B, the standard colors is only 36% of the colors which could visible by our eyes. So only third of the colors could be rendered out in our screens. Right now we have like H d HDR colors, uh, P oh P three colors.
They, uh, it's about 25% more. It's about half of the colors visible by human eyes, but we can't use it in our css. And you know, it's, to be honest, this new colors is some sort of new retina. You can create completely new legend pages, or for instance, buy these new colors. You will be more free of creating a design system because you will have more options to choose. And here's a problem, uh, hacks. RGB hsl, all these formats are not suitable to create this HDR colors. And we have a new format and OKLCH in one of the format, which could [00:42:00] be used to create a HDR colors. So this is the reasons why OKLCH is a great thing, but also there is a third and my favorite one, it'll force you to speak with your designer on, you know, on the language of colors.
And, you know, it'll be very fun. You'll be, uh, more together and you will create a much better product because you will not, you know, this is not my job, you know, this is your job stuff. Uh, by going to the OKLCH world and then presenting this amazing things to the designer, you will be, you know, able to create a
Andrew: connection
Andrey: with, them.
Andrew: Do you know if you guys use, OKLCH on the Evil Martians homepage?
Andrey: Yeah, we using it to color transformations, like, uh, um, for instance, if you need to calculate what color you should use for text or for, um, Images, like, um, no. The contrast, the okays is very good format [00:43:00] because it has a very predictable lightness component. And so the mass is much more simple than in hsl.
Andrew: yeah, yeah, yeah. I can see it just by dragging the window from my, uh, external monitor to my Mac monitor. The color's just like up and brightness a
Andrey: Okay? Yep. Oh, for instance, versa. Uh, Versal website it use, okay. Uh, it use HDR colors as well, of course by using cocal CH color format.
Andrew: So OKLCH opens up 25% more color. What about the other 48%? Like once our screens in the far future are able to represent those, will OKLCH still be a color format that we can use for those new colors that don't yet exist on our screens?
Andrey: As an important note that we can use this, uh, 25% more colors only on hardware, which support new cars, which have this new physics. So, but it's all, uh, all Apple devices from 2016. So it's a lot of devices right now. [00:44:00] Um, yeah, the funny part that we still limited, it's only half of the colors right now.
There is another standard called Erect 2020. And this is a, um, standard, mostly used by, uh, screens, uh, uh, mon, um, a TV and the HD content, HDR content from the Netflix. Very likely that it'll be rendered in erect 2020 on your screen, so it's even more colors. It's about, it'll be about 60% colors, but right now our physics of producing colors is limited to erect 2020.
Like even finding a good, uh, screen for your laptop supporting 100% of rec 2020. I think it's impossible right now, or maybe it's only one or two devices on the market. But the OKLCH, it's a very interesting, very nice format because it, device independent, it could be used to produce any color visible or even invisible by our, I'm not sure about, you know, totally invisible, but still [00:45:00] like you can produce any visible colors.
Um, bio L c h, the only question is only about your screen will be will the screen be able to render it and it's open. Very interesting question. Like you can do, um, color protesting in know, L C H for instance. You can read, uh, increase the situation and go beyond the possibilities of your screens. But if you deploy this website, and I don't know, 10 years later, people will open this website with a new hardware which could render it.
You will have this, uh, better colors because like, okay, L c H is suitable for any devices.
Justin: Yeah, that's, that's really, that's really cool. I, I, one of the things that I, I really love about design systems in general is that it does, as you were saying, it creates a communication layer between design and engineering that makes it very, the relationship very explicit. And, uh, colors in particular are really a big part of this story.
And specifically, like understanding [00:46:00] color scales or understanding, um, one of the big things is just like saturation and really, really importantly, just like, Uh, your contrast of the background and the text and everything, you know, for accessibility and all that other stuff. So this has been, uh, something over the years is just like there, designers will usually come up with color scales and, and a lot of times you just get like a dump of like hex values of like, and the steps are not clear.
So just having, you know, having it very explicit what the steps are is, is a really, I think it's a, it's a huge, uh, improvement and also it helps like developers replicate this in other projects and like figure out how to, you know, how to make this more portable.
Andrey: Design system is not a buttons in your, you know, style, uh, storybook, uh, page design system is a system. And the best way to describe a system is the code. And [00:47:00] so the like, uh, in I ideal world design system should not only be in the heads of designers, it should be inside your css, like your front end code should share the same system which was created by designer.
This is the idea of like having a system. And this is a way why, uh, design system is so important because it increase the speed of communications between front end and designer teams. Because if you have a system as a designer, you don't need to explain every small pixel to the front end developer. You can explain like, you know, create a page and this, and front end developers will be able to create this page because, uh, they already have the system inside their mind or inside the cord.
Justin: Yeah, absolutely. Um, just to be aware of. Uh, so we have one other tool that we have highlighted here. The, the log log UX logux. Yeah. So we can talk about that, uh, or we can move on and sort of wrap up and then move to tool tips. Um, do we have a preference here?
Andrey: ~~there is very interesting, uh, part of the talk about logux. I will not focus focusing only about the ity, but I want to speak about the privacy first and the locally first. So if you have a 10 minutes, let's do it. It'll be very interesting for ~~
Justin: ~~Okay. ~~
Andrey: audience, I think.
Andrew: ~~Yeah, let's ~~
~~do the log questions. ~~
Justin: watch it off?
Andrew: Uh,
[00:47:41] Distributed Applications
Justin: ~~Okay. All right. Uh, ~~so, uh, probably the last tool we'll have time to cover today. Uh, you're working on this project called Logux. Uh, could you tell us a little bit more about what that project is and what your aims for that project are?
Andrey: Yeah, this is a project, this is a framework of client server communication, which use C R D T as a [00:48:00] basement. So technically this is a tool which will load a data from the server and allow you to change it with support of offline and conflict resolution, automatically conflict resolution if two people working on the same document at some moment.
But you know, this is, um, There is a lot of things which we are able to do it and it's not an idea behind this project. And you know, the funny part is idea. And I really like this project, working on this project because, you know, I came to the front end developer to, I came to software developers because I think that we can change the world. I really like, it's funny to think, to hear that like, software developing is out of the politics because, you know, open source was a politics, hacker movement was a politics, it was always a politics. And I like, uh, working on Logux right now because this is for me as a way to work on the politics because, uh, all the C R D T and like conflict resolutions, it's part of technologies, which right now a lot of [00:49:00] people experimenting about the idea which called locally first. Unfortunately, our like mm, silicon value, and all our companies in the software development, they create a world hostile to the users. We create a system where we don't own our data, and as a result, we have many problems with privacy. And, you know, uh, survivals on, for instance, you are not able to go from one social network to another.
Even, for instance, you have some censorships there or something. Um, it's especially very painful for me, like as a Russia Russian citizen because we have a censorship in Russian social media. And so we have right now a very important idea called Locally First. This is idea that creating a website, you're not creating, you know, a screen for your that server database.
Instead you creating a distributed system, your client code is the application is the whole product. [00:50:00] And your book, your servers is only a backup tools. So, uh, you are downloading all data, which you need from the servers to your client. Do everything locally and just synchronize the changes to the server.
And for instance, maybe people to peer if you want, but the idea that every machine is the node of your distributed systems. We can think that it's something overcomplicated that it's very hard to develop, but in reality it's even opposite. To be honest, the idea that our website is just, you know, a screen for our server database is a fake to be on, always.
To be honest, we. Always creating a distributed system, but not, uh, accepting this idea. We're creating a very bad distributed systems. You know, all these problems with infinite law. There's all this, you know, crazy stuff of query querying data and, you know, processing can right now, like when I press safe on the form, I could have a problem.
You know, like in New York, in [00:51:00] New York, we have a not stable internet connection in subway and our web is not created for these things and creating, uh, a system which will work in these scenarios, it's so hard if you are not start to think. That, uh, your website is just a node of distributed system. And so the good part of locally first, it's not even, uh, harder to create a system.
We just, you know, need to stop to think about big startups, Google, Facebook, and you know, all these, uh, companies. And, you know, to going back to our origin of software development, go back to the hackers, nature and hacker spirit and like locally first community is amazing just going there. I really like that they have, you know, spirit, that spirit.
Justin: Yeah, absolutely. I, I think this project's really so interesting because, um, well first, local, first software is, is hard. It's a hard problem. Um, you know, just trying to understand like CR DTS [00:52:00] is hard. I mean, these are, these are intense. Projects and, you know, getting all the architecture together for this is, um, is a challenge.
And, and I like this, you know, having it all packaged up into one thing. So, um, just briefly, what are the technology decisions that you've made for this project that you think, uh, is enabling or like, makes it easier for people to get started in this space? Um, why would, why should someone use it?
Andrey: my favorite idea is that, uh, you have a local database, sort of database on your system. To be honest, we have it, uh, on the modern front end anyway. For instance, like if you have Apollo client, you will have a cache. And to be honest, the cache is a database. But if you, from the beginning will think that this is a database, it become much more easier in, but in Logux
like there is a, a lot of CRDT projects, which think in the way of, uh, having a local database, for instance, Firebase, it's not crt, but you, you, you could create a [00:53:00] similar system or maybe many other system, but uh, in Logux we went a little different way. So we are thinking that you not have a database on a client, but instead you have a persistent source.
On your client side. So right now we are thinking in our front-end development about, you know, component first way. So whole logic is described in our component, and as a result, it's hard to test, it's hard to immigrate on other the script framework. But in logux we switch our perspective that your logic is described in your stores, in your state managers.
And so your database is your state manager. And as a result, all C R D T stuff is hidden inside stores, which you use as is from the NPM packages. And as a result, like your client site code becomes sometimes even simpler that you know, uh, doing, uh, a proper object request because like everything is packed inside, it's [00:54:00] hidden inside these stores.
But in contrast with database, um, a logo has, you know, onion structures and you can like remove this layer of, um, Smart, uh, stores and go directly to a lock, uh, event source model, which connected to the web socket and, you know, do another stuff around it. This is what I like, but to be honest, loggers is not the best tools.
There is plenty of them right now, and this is, I believe the revolution of front end is going in this place. And so, like, logux is only my way to say something, but is so many interesting cr DT databases right now. You know, just go there and try them. It's fun.
Justin: Yeah. That's awesome. We could probably do a whole episode of all that.
Andrew: Cool with that. Let's transition to tool tips.
Andrew: Okay, that wraps it up for tool tips this week. Uh, thanks for coming on, Andrey. This was a lot of fun. Uh, you're, uh, a titan in the space and, uh, it tickles me that you want all your [00:55:00] tools to die.
So, uh, for coming on.
Andrey: Thank for your inviting. You covered very good questions
Justin: Yeah. Yeah. It was such a pleasure to have you on. I, I do. I definitely hope that, uh, the web continues to progress in positive ways and the tools that we made to get around the limitations of the past are no longer necessary, and we can focus on cool, new things.