The Changelog: Software Development, Open Source - Functional CSS and Tachyons (Interview)

Episode Date: November 10, 2017

Adam Morse joined the show to talk about Functional CSS and his project Tachyons - a CSS Toolkit that lets you quickly build and design new UI without writing CSS. We talk about Scalable CSS, the difference between "Atomic", "OOCSS", "BEM" and others, semantic class names, and where we go from here.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Auth0. Auth0 makes authentication easy. We love building things that are fun, and let's face it, authentication isn't fun. Authentication is a pain.

It can take hours to implement, and even after you have your authentication in place, you have to keep your code secure, up to date. It's a mess. Auth0 makes it easy and fast to implement real-world authentication and authorization architectures into your apps and APIs. You can allow your users to log in however you want, regular username and password, Facebook, Twitter, enterprise identity providers like AD and Office 365.

Or let them log in without passwords, just like Slack or WhatsApp. Get started. Grab the Auth0 SDK for your platform. Add a few lines of code to your project. This can be a mobile app, a website, or even an API. They all need authentication. Head to auth0.io slash the changelog. That's the number zero in auth0, not the word. No credit card is required.

Sign up for auth0 and get the free plan or try the enterprise plan for 21 days. Once again, auth0.io slash the changelog. Again, the number zero in auth0, not the word zero. And tell them the change I'll send you. You're listening to the ChangeLog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of ChangeLog. On this episode, we've talked with Adam Morris about functional CSS and his project, Tachyonz, a CSS toolkit that lets you quickly build and design new UI without having to write CSS. We talk about scalable CSS, the difference between Atomic, OOCSS, BEM, and others, semantic class names, performance, and where we go from here.

So we're here today to talk about functional CSS. I don't know what you guys normally write. Mine's usually dysfunctional CSS, and that's my lame attempt at an intro joke. But functional CSS, a different way of writing CSS than maybe some folks are used to, definitely was new to me when I first heard about it. But a thing that's been gaining steam. And we're joined by Adam Morse, who has written a lot about functional CSS and has a framework called Tachyons. And Adam, let's just start with maybe you telling us what functional CSS means to you. I was under the impression we wouldn't be doing hard-hitting questions. I don't know if I ever thought about that. Tell us what it means to somebody else.

Yeah. No, for sure. Yeah, I feel like, I think John Gold is the one who coined that phrase. Maybe not. I remember hearing it from him for the first time. I had largely viewed tachyons as kind of, I don't know if they want credit at all, but it's really for me just smashing together Nicole Sullivan's work and Nicholas Gallagher's work and kind of like pushing that as far to the extreme as I could. Yeah, so functional CSS for me, I don't know. I mean, I guess it's all semantic. But for me,

it really just is okay, you it has one function, and you understand the context of that thing. And it's always the same. So it's reliable and predictable in my world. Okay. So in 2016, you wrote a post, Scalable CSS. I believe you had taken a job at, I think it was Salesforce. Correct me if I'm wrong there, but a large company with a lot of, I don't know what you call it, active CSS or legacy, a big project with a lot of CSS written.

And you were going through the CSS there. You wrote this post, which a lot of people have referred back to when they talk about is functional CSS the way to go? It sounds like it was very convincing. And it's a nice post. We'll add that into the show notes. But tell us about that situation, what you found when you were tasked with either adding to or improving a large css code base and why that led you to kind of continue down the functional path um well yeah i think a lot of things happened

at the same time and i don't know if my memory is good enough uh or if i'm smart enough to kind of know the causality and the correlations and where to separate them. But I was testing a lot of things at the time, and I was very against what was known as object-oriented CSS. When I first started seeing code examples, I thought it was just an anti-pattern in relation to everything I'd been taught up to that point and so it was also about this time that I saw a talk by Christopher Joseph who was working on top coat at Adobe and they had commit graphs for components that showed if the rendering speed was improving uh with each commit which blew my mind i was like this is how i want to work right like when you make a code change you get this instant feedback loop on if you made the component paint faster or not wow um this i mean this like just melted my brain so i asked him out for coffee and uh he sat and chatted with me and illuminated me on all these different ways you could test CSS performance.

And so I got set up with Telemetry, which was inside the Chromium build. And it's just this testing suite where you can test a wide variety of JavaScript and CSS things. idea of javascript and css things javascript at the time was not of my wheel set or interest but i was interested in learning more things about css performance and so i set out to write the mic drop blog post on why object-oriented css was awful yeah and i just came up with all these code examples and they just painted faster than my examples that i thought were optimized for how css should be written wow so uh i was like ah like in the process of running this blog post against something that something changed your mind well i so i don't know if it changed my mind yet. It taught me that it painted faster, but that's only like one concern when you're authoring CSS, right? I was interested in the pure what paints the fastest.

That was of interest to me for a variety of reasons. And so I was convinced on that front. I mean, I had a lot of compelling data that said it was significantly faster. That's a good start at least. Yeah, for sure. And over that time, I was also working a lot with Brent Jackson, goes by Jackson Black. And he was really pushing me on design system values and kind of having cohesive measurement units in a way that was a bit deeper than I had been pushed before on that front. We were exploring a lot of different systems and patterns there and kind of like testing them at various scales. And so that was kind of also informing some of the work that went into Tachyons. But what happened was I just looked at file sizes of all these websites and it was just massive amounts of CSS.

And so I decided to put what I viewed as like an unreasonable amount of the CSS spec into a single file just to see how large it was. And so that was what I was using to do a lot of these performance tests. And I then just started to build websites with it to run these tests and have data. And then just started to pare it down of what I wasn't using, and that kind of ended up becoming Tachyons.

Very interesting. A few things grabbed me from that post that you wrote. I'll kind of paraphrase them back to you. Just want your current thoughts on them. Not necessarily asking you to remember everything that you wrote back then because it's been a year and a half. But one of the things that you said is that you found, whether in that particular project or holistically over time,

is that cascading in CSS, cascading is the thing that's really the problem. When we talk about scale, not necessarily performance, but we talk about scaling across humans, like how many people can work on this. You said that, and then another thing you said is that unlike other types of code with CSS, you're more likely to find the most recent code towards the bottom of the file,

which I had never thought of, but resonated with me immediately. It's kind of additive, right? We just keep adding. We don't necessarily refactor or delete very often. Start with cascading is the problem. I think maybe that's just

maybe we just inherently all think that that's probably true, but what do you find specifically is the problem with the cascading? What's funny about that though, Jared, in this question, is that that's the whole point of CSS. It's the first word in the acronym, cascading style sheets. For the cascade to be the bad thing, we're essentially saying the core principle of CSS is wrong, but I'm interested as well as Adam's answer. I just wanted to put that out there, because that is the first word in the acronym.

It's a feature. Yeah. So the first off, I'm not very good at writing. So we'll put that out there. Second, I should probably rewrite parts of it. So I think that, you know, in my experience, there's a big difference between things that I like and then trying to scale something out. And so a lot of that blog post is kind of, again, against necessarily like how I like to work. But I found when you work with like hundreds of people who oftentimes you're not even ever going to meet, it's really hard to get every single person to understand the intricacies of a deep cascade.

And so what happens is they don't reason about it and then things are just broken. And that's what you ship to your users. And then you have less usable software. And that makes me sad. So I've found that the cascade's great. I think that teams I've've found, have much increased velocity when it's a really shallow Cascade. And because you can't get rid of it, even Tachyons has Cascade in there.

A lot of people don't realize it, but you still have the Cascade at your fingertips. So it's not something that I'm against or trying to get rid of, but I've found that by flattening it or making it more shallow, it's a lot easier for beginners. It's more accessible for them to design and write code, which I've found is something that I aim for. The easier I can make it to onboard new people and make the entire process easier for people to get their hands on, that's a win for me. It's interesting. I found a similar analog between the cascade in CSS and classical inheritance in an object hierarchy

where the deeper nested that inheritance becomes, you have leaky abstractions and you have unintended consequences, which is really the problem with the cascade is, oh, I just wanted to change this thing. I didn't realize or I never knew it would change this other thing further down. And so a lot of people, even inside talking about how should you model your objects in your program, they will throw out inheritance altogether as a tool that should be used.

And that's really hard also because you have to use composability, which is a good thing to use. But in the extreme, it's actually less efficient to do code reuse that way. And so I found actually just having a very shallow inheritance hierarchy in programming is very fitting and kind of kind of the best of the both worlds. So it's just interesting that you say you can't get rid of the cascade completely. Well, because first of all, it's encoded into the browser, so it's going to happen. But if you just keep it shallow and kind of thoughtful without getting too deep,

then you save yourself a lot of trouble. So what's a good shallowness, like depth? Like, is it three layers, two layers, one trouble so what's a good shallowness like depth like is it three layers two layers one layer what's a good shallow versus deep i mean i think that's a contextual i mean for me um tachyons is the representation i don't know how many layers you'd call it uh one or two um but i think you know whatever is successful for a team of people they all know their strengths i've definitely definitely worked with teams where everybody who touched front-end code was a CSS expert. And so I didn't really ever think about code architecture at all

because everything that we tried to do was easy to get done. When that's not a reality, that's when you take a look at, okay, what's tripping us up? What are people spending time on that they shouldn't spend time on? Um, so I don't really think that there's, you know, 10 layers can, or, uh, 10, uh, yeah, layers deep is fine to me if that's manageable for you. Um, the larger the team I work with generally, like shallower I want it, maybe one or two. You almost even make it component or module specific, which is a growing trend these days too. I've seen something recently with Webpack where I can't recall what it was. We were going to include it in ChangeLog Weekly, but for some reason it either made it in there

and I'm lying or it didn't and I wish it did. But I recall it being something like where in this vein here where with tachyons and functional css where you want modules to be modules and and there is you kind of throw away the cascade you know you kind of throw maybe you use it within that module or that that component but that's about it and even webpack goes one step further and makes the class names for you where you don't even have to think about that where it's it's just if you're a listener out there you know what i'm talking about send us a link or remind us what we read out there because it was very interesting and

now i kind of wish i had it right here right now to put in the show notes and i don't i'm sorry but that's that's what it is what do you know about that adam is that does that ring a bell for you do you know what we're talking about um that doesn't ring a bell for me in terms of something i read recently but the trend is definitely there and i think uh the other part of these things is that the way javascript is working now um there are a lot of frameworks where even using something like tachyons, it's still... You can still localize it at the component level. And it'll manipulate the class names and hash them out so that there are no collisions

and only inject the CSS that you're using. So there's so many different options, even regardless of how your actual CSS architecture is, of how that gets included and encapsulated into a component. Should we be specific too that this conversation seems to be not for your general run-of-the-mill MyBlog website. This seems to be more for, as you say, Adam, teams, you know, scaling CSS, scaling a design team. Does this matter or should this even apply to, say, a smaller website that, you know, is run by maybe

one or two people at the most that, you know, doesn't have what a application on the web might or a web app or progressive web app or something very more complex very more it's probably not the best way to say it but you know no no lots more um no very complex that's a fair question um so obviously i'm biased i mean i built tachyons for me uh and the people that i was working with uh to solve the problems that i could see but it's interesting to get feedback on how people use it, because it's definitely had unintended consequences, both in my development workflow, and I think for others. I think even for smaller websites, for a lot of people, especially designers,

there's a language that's fairly quick to grok, and it allows them to just design in the browser in a pretty fluid manner. And it doesn't matter if they're just building a single component or an entire site, whether it's a page or a few pages of just like static. It could be a Jekyll build. It could just be, you know, vanilla HTML. Is that a phrase, vanilla HTML? Now it is. I think it is, yeah. Is that a phrase? Vanilla HTML? Um, now it is. Can I, can I coin that? Um,

yeah. So I, I'm always surprised at how people enjoy using it. Um, I don't think it's the best for, uh, styling like content management stuff. I think there you kind of need to use unqualified selectors, uh, or unqualified elements in your selectors and kind of style things by traversing the DOM. Right. And that has a bunch of pros to do it that way. Some people can affect the markup that they're trying to generate and have a lot of control over their CMS. So maybe it does make sense to use it there. But, you know, sometimes like people will try to use it in a way and I'm like, oh, yeah, it's like not the best for styling blogs. I would definitely be the first in line to

say that. So, yeah, it's always kind of pleasantly surprising, like what people like to do with it. I know that Credit Karma was one of the first larger companies to use it in terms of like how many page views they have. Uh, and they've told me that they've had a lot of success being able to, uh, test multiple designs in parallel, um, and, uh, really do a lot of like rapid changes to the UI. Um, and that was what I set out to do was be able to iterate through thought as quickly as possible. Um, and you know, for me, Tachyons was an implementation of that mental model. Let's talk about tachyons, where it fits into the landscape. So some people can have a frame

of reference with regards to like, what it is as a thing, we mentioned, it's a framework, a tool for doing this style of building, you know, components on the web. People may be familiar with a bootstrap or a foundation, or maybe semantic UI. Does tachyons fit into that category of a framework or is it working at a different level than those? I don't know. I think that those are definitely more complex in regards to they offer a JavaScript layer and

kind of interactivity of the components that tachyons does not have. But I also know that some people just use the CSS bootstrap and none of the JavaScript and just use the visual styles. I think that they're similar, but definitely different. I think, you know, tachyons is a little less out of the box in regards to having fully baked components as a part of the CSS. But that was my long term vision with creating the component library that's a part of the website was kind of creating that in a different model. And so it's not maybe out of the box in regards to you have components in the same way of just attaching the classes. I guess it's the same, but to me it's just like I wanted to give people the ability to cut and paste HTML examples

or maybe React components or Vue components and be able to use those and just have composition of Tachyon's classes already put together. Surely there are drawbacks or downsides on any argumentation around how you should be doing things on the web, especially with CSS probably. Well, anything that goes on in the web. I was trying to limit that, but probably all things are debatable online.

There are probably people that say this is not the right way to do it um this is worse than the object oriented style i'm not very well familiar with like oocss but it sounds like it would be kind of like this where like everything's componentized um then there's also like bim and then there's kind of like the traditional what i usually do which is like just start throwing like styles out there until BEM, and then there's the traditional, what I usually do, which is just start throwing styles out there until it looks okay, and then hope you never have to edit it again. That's very common, by the way. Just hope it doesn't grow big enough.

Which is why the new CSS is at the bottom. That's right, you just keep adding it until you're done. And you never remove it because you're like, the two CSS classes walk into one bar and a bar store in another falls over. That's right. That's quoted by Thomas Fox. That's my favorite.

That's my absolute favorite CSS joke. That's a good one. And with me, since I do client work, so I have different projects through the years, oftentimes what I'll have is a client come back, everything's fine, but they just want one thing tweaked or changed or added. And I have to go back to CSS that I wrote a few years ago or somebody else wrote under my hire and determine how was I doing hiding and showing elements back then and how was I doing these things.

And usually I'm just like, well, I'm just going to throw a bang important at the bottom and be done with it. So that doesn't scale but what are some of the the people who say functional css is you know suboptimal for reasons x y and z what are usually the people the downsides that people quote or that you found as you've gone about using it surely it's not a panacea or a silver bullet no definitely not um i try to drown out the haters uh it's you know it's depressing um i think you know a huge you know one of the first things is like it bloats your html um or that it's not semantic um and that uh yeah a lot of people just say it's bad and don't really qualify

it which totally get I mean that's literally what I first thought I almost wouldn't trust anybody who did like it at first glance right I'd be like what's wrong with this person yeah I'm the biggest fan of the people who are

skeptical of it at first. And I honestly, my favorite thing is to screenshot people who are like, this is awful, and then use it for two days. And then they're like, I've never worked faster. And you're like, Yep. This episode is brought to you by DigitalOcean, who just launched Spaces, a beautifully simple object storage service that's designed for those who want a simple way

to store and serve a vast amount of data, such as hosting website assets, storing user-generated content like images and large media files, archiving backups in the cloud, and storing logs. Just like you're using S3, you can use DigitalOcean Spaces. And in fact, you can use S3 and DigitalOcean Spaces at the same time, so you don't have a single point of failure. This is a standalone service. and DigitalOcean Spaces at the same time so you don't have a single point of failure. This is a standalone service, no droplet is needed, and pricing is extremely competitive. To make it easy to try for both new and existing DigitalOcean customers,

you can get started today with a free two-month trial of Spaces by going to do.co.changelog. And by TopTow. TopTow is the best place to work as a freelancer or hire the top three percent of freelance talent out there for developers, designers, and finance experts. In this segment, I talk with Josh Chapman, a freelance finance consultant at TopTow, about the work he does and how TopTow helps him legitimize being a freelancer. Take a listen. Yeah, in my arena within TopTal, I specialize in everything from market research to business plan creation, to pitch decks, to financial modeling, valuation.

And then that leads very naturally into fundraising strategy, capital raising strategy, investor outreach, closing a deal, deal negotiation, how to value the company, how to negotiate that. And all those skill sets that I have continued to hone over on the TopTal side are ones that I actually deploy every single day in my own company. Freelancing can sometimes be seen as not legitimate or subpar work. Now, I would argue that when you work with a company like TopTal, they put so much

vetting into not only the companies that you work with, but also the talent that you work with, which I'm on the talent side, that it adds a level of legitimacy that isn't seen across other platforms. And that for me, as the talent side, is incredibly fruitful and awesome to be a part of, right? I enjoy the clients. I enjoy the other talent that I get to talk to. I enjoy the TopTal team. And that creates an overall positive experience, not only for TopTal, but for me as the talent and for the client as the company on the other side. And that is really not seen or is the experience across other platforms in the freelance market. So if you're looking to freelance or you're looking to gain access to a network of top

industry experts in development, design, or finance, head to toptal.com. That's T-O-P-T-A-L.com and tell them Adam from the Change Law sent you. For those wanting a more personal introduction, email me, adam at changelog.com. What's familiar is like what's great right like the morning practice or something where you're like oh this is uh i understand it i feel empowered yeah i think that uh different people like to work different ways and i think that that's okay um so let's take a couple of those arguments though so you said one thing is it's not semantic. Yep. Which it definitely is not. What you're doing is when you're putting together a component,

you're adding a bunch of classes to HTML that basically compose how that thing looks or how it works. And so you might have a, like, just even with the people who are familiar with CSS frameworks have done all these things like for you with your grid, it's FL and then the class W-100, W-3rd, W-25. These are not things that computers can derive semantic meaning out. But regular class names aren't either though, right? Tell me more, tell me more. Like what meaning does a computer derive from news-title?

It's a title of a news... I don't know. I'm not a computer. I think it's more or less computer. Maybe I'm off on this, but it's like speaking to the developer so that when you come back to it if you wrote that component oh it's you know i can define meaning as a developer from a from a class or a module based on some naming whereas things are a bit more obscure when you just use w dash whatever yeah i think that's a good point i think we have two stratas here we have the one where it's like the semantic folks with regards to microformats and all that.

That argument around what I think Adam Morris, Adam the guest Adam, was referring to, where it's like, is the computer, is Google or whoever the bot's using in a site actually deriving, meaning that they're then applying in a useful way to your HTML? And I was kind of playing devil's advocate and saying maybe they do, but I don't think we've seen tangible benefits from that. But then the other one, so on the other side of that is like semantic meaning for humans. And I think that one that you just mentioned, Adam Stack, I guess hold more weight with me. What do you think?

Yeah, so I think Nicholas Gallagher wrote what I think is the best piece about CSS architecture. And he's got a great quote where I don't have it in front of me, but he defines what semantic means. And so generally when people say it's not semantic, what they really mean, the semantics of this class name isn't derived from the content because to be semantic is just to have meaning. And, you know, BG dash blue has meaning to a lot of people, uh, even before they've ever heard of tachyons, they'll look at BG dash blue and know that it's going to set the background to blue. And that's a pretty powerful concept for some type of people. A lot of designers can instantly grok the class names without looking at the definitions. And they'll even guess the presence of a class name without having read it. And I think that that's when I get the most excited, when I can watch that happen in real time,

because I've never worked in a CSS framework where that was true. Nobody could just guess that the title, news dash title was in the CSS file, and they couldn't guess what it will make the element look like. And so a lot of people, when they're designing in the browser,

care less about the content semantics because those can change. And oftentimes, you actually want different content fed into the exact same design. So that model starts to break down in regards to how do you reuse these things when the content that's going to be pumped into them is of a different type? Do you just keep adding the class names every time you need to declare a new type of content to be pumped into a module or a component? I think for some people in their workflow or their architecture, it makes more sense to segment out to visually semantic classes, but I don't think that they're not semantic at all i've actually that resonates

with me in my experience when i've come to people who are using uh this style or a framework that i'm not familiar with it just takes a little bit of initiation and you can oftentimes even though it's brief and you're like does that mean fluid width 100 and it's like yeah it does and so it is less semantic in terms of i guess less verbose or explicit but ultimately as like a level-headed developer who's trying to like do a thing i'm going to figure out what these things mean pretty pretty easily and it falls into a framework once i understand the framework i can then transfer that knowledge to the next project and so on and once you get past the the training wheels of any framework regardless if it's bootstrap the you know the old hat bootstrap or something newer and edgier like tachyons like

you've got some sort of learning curve that you've got to get over and i think this debate of like semantics is sort of a moot point because at some point it's going to be semantic to someone so your point adam worse like is totally spot on because you know once you learn the naming schema of of tachyons for example to to do background colors like bg dash dark dash red or you know all these different color schemes you've got here like once you learn that principle uh you can sort of know, then guess your way into them or begin to anticipate because you've got at least some of the things done, but you're going to have to take some time to learn, you know, a lot of the stuff like fluid with like Jared was just saying, but I'm curious. So is, is Tachyon's advocating to rather than write a bunch of styles,

add a bunch of classes to HTML objects. Is that the way going forward for this? So, well, I'm not very into the word advocate because I don't really bestow my findings on how other people should work. Let's rephrase this. How should someone use this yeah uh again i mean i think you know some people say like i love mixing certain parts

of tachyons uh into components and then having these like more mixing it with these more monolithic component classes um and they kind of mix and match to suit their needs and they find a lot of success with that uh that never worked for me but that doesn't make me think that it's bad uh for me i mean now uh i am trying to uh abstract it out even more and yeah just have these kind of saved components where i'm not rewriting the same things over and over and over again. Because that's what I was doing even with Tachyon. So you stop writing the same CSS over and over again, but now you're writing the same HTML over and over and over again. But I think that for me, I found a lot of success in just, yeah, I could build almost anything

with a pretty small set of classes by just composing them onto HTML elements. And it was for custom animations and interactive stuff that I would have to write a lot of CSS. And it saved me a lot of time, and it also made the pages paint about as quickly as they could. So it seemed like a win-win for me. I got into it as a performance experiment and it turned out to really affect my dev velocity in a way that I did not anticipate at all. And then it started to affect some of my teammates' dev velocity in a way I didn't anticipate. So that was all unexpected and not really what I set out to do. But I don't know if I'd recommend doing anything I've ever done with code.

So yeah, it's definitely not something I'd advocate for. But I think more people have had success with it than I anticipated. You know, four years ago, five years ago, when I started this, I guess it was four years ago, most everybody said it was the worst idea ever. And so now it's very weird to even have a few people be like, oh, I really like your thing.

And you're like, wait, what? That's very odd. Yeah. So Adam, you mentioned before about certain people who've used tachyons and had an experience. You started this thing four years ago. And at that time, people thought you were a little crazy for doing it. And over these years, the trend has gone the way of tachyons, essentially. The people that have used this, at least based on tachyons.io, Daniel Eden, Ian Storm-Taylor, a favorite of mine, just because Wilson is so smart and had one of the most prolific talks at a conference, at the Build, like at least five years back, Wilson minor.

It's like, these are not unknown or uninfluential designers. These are really, really influential. People have said phenomenal things. Let's not leave off Dustin Senos. So like, these are people that have given you quotes.

I'm assuming you've got the rights to, to say they said these things. So having, having known who they are and their influence in the design space, continue on that path of who's used it and how they feel about it. Yeah, well, I don't really want to speak for them, but I will say that it was definitely a surprise when each one kind of privately chatted with me about using it and asked me questions

about it. Um, uh, sometimes I could tell they were experimenting and weren't sure how they felt about it at first. Um, but yeah, I mean, to have them say even anything like remotely kind or, uh, uh, not, uh, super critical was, uh, really nice. Um, and they, uh, it spurred a lot of like really interesting conversations with, uh, a few of them. Um, so yeah, I have to say like a number of them are people that I really look up to. So, um, the, yeah, I don't know how accurately I can speak about their experiences. Um, but, uh, it definitely made me really excited. Well, can I share a couple from the site? I't want to say dance because dance is a daniel edens is essentially a short love story um but so we'll leave that one to the audience to go to tackyons.io and check it out scroll to the bottom where the page begins to

turn green and you'll see what i'm talking about but um ian storm taylor said tacky's has seriously blown my mind. Making landing pages responsive now is somehow actually fun. Question mark, exclamation point, co-founder of segment IO. So they're doing landing pages pretty often. I'm sure at segment to bring in new people to understand what they do and whatnot. But I mean, that's not a, Oh, it's pretty awesome. You know, it's, it's very, it's blown my mind. Yeah, I think, I hope he doesn't mind me sharing this story. I believe, I hope this isn't incorrect,

but I believe he was actually working on a political site in the fall and he needed to put a landing page together for it. And then he had asked his front-end developer at Segment, like, how do we do stuff here? And the front end developer was like, use this thing that's based off tachyons. And so he looked into it. And I think at first he was like, this doesn't look right at all. And then started playing around with it. And I was like, okay, I think I see what's going on here. And was just able to get done what he was trying to get done pretty quickly. And I think that that's why a lot of people end up liking it.

Like I said, there's a speed that they can get to. They just don't have to think about a bunch of stuff and they don't have to type out a bunch of stuff they already know they need. One of the things you mentioned is that when you first started doing it, people would have this guttural reaction against the style of CSS and that started to change. people would have this guttural reaction against the style of CSS, and that started to change. Like Adam said, the trend is moving more towards this style.

I think we're seeing the benefits, especially as many of us still doing the traditional style CSS are pulling hairs out of different areas and trying to maintain sites that have existed for a very long time. It seems like some of that shift has been around the kind of reactification of web development with a focus on components, with the moving of CSS, or at least class things even into JavaScript.

We have CSS in JavaScript now. So it seems like the whole developer ecosystem is more open to kind of like taking our sacred cows out behind the barn and killing them in order to find a better way. We're not holding on to what we used

to consider to be the best practice. We're not advocating killing cows here, by the way. I would never say such a thing. Unless you eat hamburger, of course. Otherwise. A lot of disclaimers on this episode. Speak to React, how Tachyons fits in.

One of the things you have here, in addition to the gallery of people using it, is you have this component library, which are off the shelf. Grab the HTML and the stuff, and you can just drop it in and use it. It seems like that would fit very well into building out a component with React or a similar style JavaScript tool.

So speak to that. So my long-term vision there was most developers I know, if they have the discrete HTML and CSS they need to render, can port that to whatever templating language they're building. But that's oftentimes the difficult part for them. Also, I was trying to drive Jackson nuts because he was doing a lot of stuff with React. And I knew that if I just built out a ton of static HTML, he'd build me some design tools to help me out, which is totally what ended up happening. And so, yeah, I think that that movement is just more towards, yeah, like this mental model of encapsulation and kind of keeping our sanity, having like things be declarative and being able to predict stuff.

So Tachyon is one of the things that I started to set out to do on the design system side of it in regards to the values that I chose, because that's separate than the CSS architecture. That has to do with like the actual design part of it. I wanted to set out to see, can you make a whole bunch of different disparate looking websites with the same kind of CSS framework? Could you make it so that people can't just look at it and go, oh, that's tachyons. I really wanted you to be able to generate almost anything you could ever need. And I wanted to see how far you could push those bounds. And so with React, I've been kicking around this concept that I have a bad name for, that I'm calling component APIs, but there's probably, I don't even know if it's an API, but tachyons is a sequence of values, but there's probably, I don't even know if it's an API, but tachyon is just, you know, a sequence of values, but there's scales, right? So you have border radius and you

can have like two pixels or four pixels or eight pixels or 16 pixels. And I feel like that's kind of a reasonable range of like things that you're going to have for border ADI. And you can also do the pill and make it look like Twitter and everything's a circle. So what you can do is like kind of define for each component, every single thing that you would ever style. And so for instance, buttons, because buttons are easy to like wrap your head around. I think it's reasonable to declare a font weight for a button. So that would be a part of the button styling API. You might want to change the background color of the button because they don't have the best default background colors.

So you put background color in the API. You can set color. That's in the API. Now, on Hover, I think it's also reasonable to change background color. So that's part of the Hover API of the button. But I don't know if I've ever in my entire life hovered over a button and had the font weight change and been like, nice, this is

awesome. This is really, really great design. So you could not have that be part of your API. And so for each thing that you do declare, you can style for the component. Then you can either pass a single value as a default, which could be overridden, or an array of values that are okay. And you could pull those dynamically from a design system. If they're scales, you could just reference steps in a scale. And then if you built your design specs this way, you then have a, basically a combinatorial math problem. And you could just generate what each one of these components would look like, uh, with all the possible combinations of the values that you're passing in for your design system. And that's the kind of generative design tooling stuff that I'm really interested in.

So how do you kind of, yeah, take those root primitives and combine them in all the ways that you would realistically want to combine them in all the ways that you would realistically want to combine them in? Because I am really lazy. So it would be neat to not have to build the same components anymore. This episode is brought to you by GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. It provides continuous delivery out of the box with this built in pipelines, advanced traceability

and value stream visualization. With GoCD, you can easily model, orchestrate and visualize complex workflows from end to end. It supports modern infrastructure with elastic on-demand agents and cloud deployments and their plugin ecosystem ensures GoCD will work well in your unique environment. To learn more about GoCD, visit gocd.org slash changelog.

It's open source and free to use, and there's also professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. I think the interesting thing here is that like what you've done here is rooted in time to paint you know what I mean so like it came from this uh this journey to discover speed and focus on some of those things. And out of this has come tachyons and all of these components. And as you just mentioned, being able to generate a lot of these things, everything from cards to avatars to buttons to entire news articles that have really good design principles. So it's a good place to start i mean that's that to me is is pretty wild that you know the beginning of it though however was

was about performance and not just about uh let's just say developer user experience or even uh you know usability of a framework or design principles it was founded in the performance arena yeah perhaps even more pointedly is it was him trying to prove that the style was bad right i mean that's that's the life art and what what right and what i learned is nicole sullivan is a genius and she is uh yeah i've never seen her be wrong so um yeah i was also using css lint at the time and it was yelling at me about some things and i was like is this true like did somebody just make up these rules and testing them in multiple uh different frameworks it was like nope these rules are all definitely accurate so um yeah she has basically just been a constant voice of reason at the

beginning of my career as i was learning about css I want to put my designer hat on for a second because that's where I began as anything on the web. That was my forefront was on the front end side, but primarily HTML, CSS, not really much JavaScript, but really the designer, the user experience person. And so I look at things like these components and collections and stuff like that. And I think, okay, how can I, as a designer, work with a team that plans to and wants to use tachyons or even its principles and design around its constraints, essentially.

So how can I take the various collections that are there, but then also the ones that we can even dream of or build and help my team make really awesome looking stuff and all they've got to do is essentially either generate them or you know use the right classes with the right numbers and all those different things to essentially assemble this uh this beautiful page i mean the collections that you got here this is a particular uh component we're talking about is there's six different examples all very similar code

or the same code and very much different user interactions. So I feel like there was a lot to unpack there. It's not really a question, it's more like a pontificating. Designer hat, how does somebody I'll ask a question as a tell-in to that.

How does a designer looking at this, working with a design team to build an application or to use tachyons, how do they go in and put their designer hat on and use the constraints of tachyons in a way that allows them to design freely, but within the constraints that tachyons plays out? Yeah, I mean, you know, the word constraint constraint i feel like has so many negative connotations it's like uh like less options less power um whereas yeah i don't know there was a period of time where jackson and i were working together and he used to kind of talk about this concept of smart defaults and uh he would point out lots of examples in life um even like mathematically i think like i forget something like more than 80 percent of people get like a medium coffee or whatnot and but yet every single time uh they ask you what size you want instead of just like defaulting to giving you a medium unless you say something else. And yeah, so it was like, okay, how much can you do with these smart defaults?

And through a lot of testing, I've found like I could do a lot of stuff and that the teams I've worked with haven't actually like felt constrained. I think with designers, it's always different. I think a lot of the tooling we're trying to build with Compositor is lending itself towards that workflow defining a system

and then being able to work quickly within that system because even if you're a designer and you are bought into using a lot of the design system aspects of tachyons it's really hard in photoshop or sketch or illustrator to just say like, these are my spacing scales and snap everything to these like steps in a spacing scale. And we think that working within those constraints should be easier. Some designers just feel really comfortable hopping into the code. And so they actually feel really empowered by it. But others, yeah, don't necessarily like the values. So some people just completely customize it and just use the CSS architecture.

And the designers kind of handpick the types of scales they want to use and they make the scales with a lot more steps and with absolutely completely different values. I feel like it's a tough world for designers to not be in the code. Not saying they have to be, but it's a tough world whenever a lot of what you do may be in a graphics program like Sketch or Photoshop or something

like that, and you're not really playing a role in the implementation of the code that makes it real. That's a tough place to be in because you essentially create a lot of roughly good ideas when it's just a graphic that you hand over to a team. However, Sketch is making a lot of inroads to turn that into code or to aid in the handing to developers. There's a couple other unique design tools that are doing similar things where you can actually generate code or maybe even use principles

from a framework like this where you can essentially have that API or that brain, so to speak, to say, okay, this is what I designed, and this is how it maps to actual code. Yeah, exactly. I think I've worked with some designers who aren't in code at all, but the way we're able to communicate the way they design is at a fidelity of something I can't think through as quickly in code. And so they're able to provide an asset with the documentation i need to implement something um but yeah i mean the reason i started coding was

out of necessity just because yeah i was making images and um the first time somebody built something and it wasn't you know looking like this image i handed off it was like cool let me see if i cool i'm gonna do this myself help help yeah yeah yeah we get in there and anyway i can't decide if that was the smartest or dumbest thing i ever decided to do one thing you mentioned adam was compositor but we haven't quite uh defined what that is for the listeners can you tell us about compositor and compositor lab uh that you've been working on yeah um so that started uh i mean i guess compositor started started when Jackson and I and this guy, John O'Tander, worked on CSS stats together. Jackson and I had launched a web app and we knew nothing

about tech ops or DevOps. We knew nothing about servers. Jackson barely knew anything about JavaScript at the time. And this guy comes along and just starts like refactoring all of our horrible code and right away and like making the website way more stable. And after I think, you know, like the 10th amazing pull request in a two day, three day span, I was like, Hey, do you want to just own this project with us? And then we all kind of got in a chat room and yeah, every now and then we would do these like sprints on CSS stats and chat. And then sometimes we'd like go dark for a few months. But then I started working on tachyons a lot more and I was stumbling on trying to get certain things done with JavaScript in terms of the like dynamic build things. So I asked John

for help. And so he started helping me out and jackson at the time was building lots of open source tools um everything from colorable and like lots of different color tools to uh his rebase library of like stateless react components um and so the three of us were all kind of still in the same chat room and john and i worked together and jackson like and i worked together professionally but not a lot on dedicated open source projects and that's just kind of been our relationship for the last four or five years kind of all infecting each other's brains with ideas and John will listen to Jackson and I talk about CSS stats and then he'll go off and build something crazy like he built a service to download the top million websites, CSS, with snapshots and like one month intervals going back to 2005.

And so he is just like graphed out the history of design systems and CSS on the Internet. And it's just awe-inspiring to go through these graphs and just like see these trends at this 10,000 foot scale. And that's something we'll make public later. We still have a bunch of things to clean up there. But it's just a lot of fun working with them. But at the same time, you know, we all know that open source is, it's difficult. There are things that we wish we could pay contractors to help us with. There are features that we totally want in that we don't have time to build,

but we think are valuable, especially in something like CSS stats. And for our own work, it's like, how do you just make all of this sustainable so that people don't burn out? I don't know how many modules we have between the three of us. So I think it was about this time last year where I set out to just see like, okay, let's just make this a company and start to string a lot of our open source things together and build some apps and some design tools that nobody else is building, like the way that we want to work. I think Jackson and I have been together at four or five companies now. And, you know, there's just most companies, big or small, have the same problems. Most places don't ship the result of validated design. Like one design stumbles across the finish line.

You know, it's not like you're keeping six or seven things in parallel and doing a bunch of different user testing. And so that's kind of where our heads at is like, how do we create an environment where we can get the tools built that we want to use to design stuff? And so this is a compositor is that's kind of what the company is about. And so our first product is Lab. And that's basically a tool where you can build React components from scratch. You can build a design system and kind of set scales for typography, for spacing, for color palette.

And then as you're building out components, you can compose them together. And in your React app, we have a command line interface. And we'll also be releasing a separate app for this, but you can tweak values in your design system or edit things about your component and see them editing in real time. So you can drag sliders on border radius, you can change colors. And it's, yeah, it'd be like if you could edit sketch symbols

and see that update at the same time and not have to like switch between artboards. And that's always been my dream is to be able to edit things about a system and then see them propagate everywhere and know what's gonna render and not have it be unpredictable. So, yeah, I'm really excited about Lab because I am not good at JavaScript or React. So it really it's helped me kind of speed up my ability to build components and reason through that abstraction.

Always love to hear how open source hackers are trying to keep doing open source so many avenues and so many of those end in failure so hopefully Compositor is a success or financial failure Yeah, well failure at that particular effort I was going to say, I feel like we're successful because we enjoy working together and I use the tools that we build to design stuff Yeah. Yeah. I was going to say, I feel like we're successful because we enjoy working together.

And yeah, I mean, I use the tools that we build to design stuff. And that's kind of the whole point. So we're pretty excited about what we have coming down the pipe. So is Tachyon's under the hood of the things you're doing with Compositor? I know you got the labs you mentioned, but on the homepage, you've got projects. You've got even Xero. I'm leaving off Compositor because it's the, you know, the brand prefix. So compositor zero is a responsive kind of app you can use to build responsive pages. And it seems like tachyons is behind the scenes here. So, um, or am I assuming that and I'm wrong? No, no. I mean, I've always considered tachyons to be

like a modular set of ideas. There's a CSS architecture part of it, but that's just one implementation detail. I think the most important thing are the aspects around performance, which, you know, you could ship fewer than 16 kilobytes of CSS, which I think is the tachyons entire like build size now. You know, you could ship two kilobytes of CSS. That would be nicer. I like the values, the constraints of having a scale for spacing for typography. So that stuff is under the hood, the same patterns of being able to target a breakpoint and set any value at any breakpoint. Those are the underlying principles under the hood for the products, but most of the stuff is built in with various CSS and JS libraries. So the actual tachyon's classes aren't being used. But to me it's the exact same and it's a pretty fluid transition for me to use

like this different architecture because all the patterns are still the same. The CSS stats tool, which I had previously never heard of, is very cool. I've been in the background putting changelog.com through your tool. It basically will throw out your size of your CSS, all the rules, how many selectors you have, so on and so forth, all the way down font sizes, how many web fonts you're pulling in very cool so you said you have a lot of features this looks like it's all open source stuff is this a thing that people could hop in and help out with or is this

limited to the three of y'all what's the situation with this particular thing no that's that's completely open I'm actually doing some work at my day job. I work at Cloudflare and we are working on a living style guide right now where a lot of people, when they do a living style guide, kind of like present one site. But every company I've ever worked at has multiple websites. You might have a blog that's a different front-end code base than a logged-in app. Then you have your marketing site that might have a blog that's a different front-end code base than a logged-in app. Then you have your marketing site that might have been built out of house. But there's generally, maybe you have a status page, but there are generally more than five to 10 websites for

even a small company. And so in the effort of having a feedback loop for a design system and whether or not you're becoming more consistent over time, less consistent, or maintaining the same amount of consistency, we're using a bunch of CSS stats modules and then combining them with the Internet Archives Wayback Machine. And we just have an array or a matrix of where the common values are. And so you can scrub the data over time and see, okay, for these 10 websites, these are the four font sizes that are present on all of the websites. But you can also see where you were, whatever the back date is. So that's something that we want to open source as a web app that anybody can use and generate kind of an actual dynamic living style guide for an entire set of URLs, which I think is kind of an exciting project.

Nice. But it's definitely all open source. And so people can feel free to jump in and make it better. So CSSstats.com is what we're talking about in terms of open source or is this something future that you're working on? Is it connected? It's just connected in that Cloudflare will probably actually run it as a web app and pay for all the hosting there. But they're just using a bunch of the modules. But yes, all of CSS Stats, all the modules are open.

There's a lot of powerful stuff that you can string together there. And there's a lot of things that we just haven't had time to do. Like, you know, CSS stats in many ways is, it started out as our stab at making a rudimentary style guide in a first pass of just like what's already available in this visual system. Especially when you're a new front end developer, do a code base. That's one of my, like, you can only read a CSS file so fast when you really just want to see, like, what are the colors here? And I think that, you know, you could kind of make some agnostic themes and just run that as your own living style guide

and be able to, you know, theme it with all your own company stuff and kind of make it look however you want, but also toss in a lot of custom documentation with rationale and stuff like that and maybe some fixed values that you also want to document so i think there's a lot of work that people could do there if they were so interested i think it so just for the listener it'll show you all the unique colors unique background colors that kind of stuff so you know with the with the hex codes and everything so it definitely is like just looking at ours it's like yep there's all of our stuff

it actually looks like it represents like you said kind of a style guide of what changelog.com looks like will be really cool so maybe this is like a PR is welcome type of an opportunity but is to have some sort of like relative some sort of relation between

where you stand with the rest of the world so if you're trying to use it the way that I would, it was like, how can I optimize our CSS some more? And it's like, well, you have 138 font size declarations. That seems like a lot to me, but maybe that's like completely typical on a web app of this size or something. So like say, well, this is like six times out of the standard deviation for font size declarations or somewhere where you could say,

yeah, you're struggling here in relation to other people's websites would be cool. Yeah. So that's one of the reasons why we downloaded stats from the top million websites was to kind of get some of those numbers. We could look at averages, medians, means, and yeah, give some useful information, that was a big question of mine when I first started out doing stuff on the web is like, yeah, this seems like a lot or a little to me, but what does everybody else? Like, I remember just going around being like, how much is too much CSS? And people would be like 120 kilobytes.

Right. And like, now I'm just like 120 kilobytes is so much. Um, but at the time I was like, okay, cool. That's just like a number. Uh, yeah. And I remember just like 50 kilobytes. It's like like okay cool that's just like a number yeah and I remember just like 50 kilobytes it's like fine that's nothing and now I have yeah I'm like well we could have less than that but you know it's also not as bad as some other websites so yeah it's definitely something

we would love to have in there for sure because I think it's a useful information across every single CSS property I could be wrong but it sounds like you know what you're talking about in terms of where you're trying to go with Compositor, what you're trying to do with Jackson, John, and even your work at Cloudflare. It seems like you know what you're doing. Am I wrong in saying that or am I right in saying that? I feel like I stumble through every day, so I don't know if that means I know what I'm doing. What I mean to say about that is obviously it's a joke,

but to say that you're the kind of person we want doing the things you're doing because you're innovating, you're pushing the boundaries, and you're shedding light in areas where people really haven't or aren't as much doing this. And so my question for you really is, if people are listening to this show and they're like, Adam's amazing, I want to support him and his team

or whatever he's doing in any way I can, how are they, how can they do that? Is it, you know, tackle some issues? Is it step in on some different projects with you? You know, is it financial? How can people support the efforts you've been doing for the last four years with Tachyon, but then also the future that you've got, that you've shared is it financial? How can people support the efforts you've been doing for the last four years with Tachyon, but then also the future that you've got, that you've shared here with us?

Yeah. So, I mean, I think, well, cosmically, I think, you know, the best way is like to pay it forward and just make it easier for more people to get into the industry and like make things accessible. Even though I try to, as you said, innovate and be bleeding edge, a lot of it's in an effort to lower barriers between thought and execution for people of all technical abilities. I think for Compositor, I mean, yeah, we are excited about this.

We have probably five or six different apps in development that we've been working on for about a year now. So we plan on having a growing suite of tools that kind of work together. And I think, you know, we'd love if people bought subscriptions to them and tried them out if they're useful for them. We think that they're going to provide a lot of value. So we're excited to see where that goes. But besides that, I would just say, like, you know, contribute to the open source community at large, because there are a lot of people that, you know, you've probably never heard of that don't get opportunities. And if you just

gave them money, we would have better things. Right. The one of the reasons I was able to do so much open source stuff was because of, you know, certain financial privileges from being really lucky and at the right place and the right time in my career and nothing to do with any talent. But free time and mental freedom breeds innovation. And so I think like just finding junior people to invest in is like I was lucky people randomly invested in me and I definitely wouldn't have gotten to where I was if people didn't do that. So that would be the best way I think you can support me

is just by supporting the entire community at large. You know, it just seems like a larger ask, but yeah. Maybe a little more direct might be the available now, compositor projects. A lot of listeners here are familiar with GitHub, I think. So at least maybe one or two haven't heard of it. But it seems like this is beautiful, fast and simple GitHub project pages. So many listeners support open source or run their open source maintainers,

you know, sustainers, a wide variety of listeners to this show. But is that maybe a good place to go in and sign up for that is that is that a free thing is that a paid thing can you maybe share some of that before we tail off the call for sure that's a free thing um so the first thing we did we wanted to get some user testing and we wanted to start experimenting with the patterns as we built this web app to build uh yeah project pages like marketing pages for open source projects. Since then, we learned a lot from putting that out and we've kind of been heads down

and building the infrastructure that we found like we needed to really make that thing what we want to. So we have big plans for that down the road. And we're basically working on all the underlying infrastructure right now. So it's still useful as it stands. But yeah, I'm excited about, you know, in another six months what that project is going to be like. And to give a little bit more context, it says it's a free service for easily generating single page sites for open source projects, which I'm not really sure what that means, a service, but there's a sign-in with GitHub button there,

so you can easily check it out and take that first step and seems to use it for free for now, at least. Yeah, I can tell you that that'll always be free. We really wanted to, like I said, we just wanted to make something where we could start to get some user testing and then learn some things about building the type of general

design tools we wanted to with JavaScript. And so, yeah, we definitely want to keep that free for the open source community. And like I said, we've been a little stagnant on updating it for a little while, but we've got a huge long term vision to make that like a really robust thing. It's a smart strategy, too, for listeners to earmark in the fact that you release something as part of this growing budding company that has much deeper plans and much long-term plans to put something out there as a way to get QA basically, to get quality assurance or to get in a beta tester, so to speak, to see how the things you're building can be used

or being used so you can learn. It's a pretty smart strategy. Yeah, it's really valuable for us. I think the more I get into my design career, the more I focus on testing things with real users and just watching them. And Tachyons was a big part of that too. I would just sit and watch people write CSS,

try to use Tachyons, try to use other CSS frameworks. And that's some of the biggest things I've learned about product design or writing code. I've just been observing how people use existing things. Well, Adam, thank you so much for all that you do, these many years of service to the community and even your advice back to everyone. And the way to help you is to just level up for the love of the game you know the entire community so thanks so much for your time today man it's great talking to you yeah likewise thanks so much for having me all right thank you for tuning in this week if you enjoyed this show share it with a friend rate us us on Apple Podcasts, and thank you to our sponsors, Auth0, DigitalOcean, GoCD, and also TopTile. Also, thanks to Fastly, our bandwidth partner.

Head to fastly.com to learn more. We host everything we do on Leno cloud servers. Head to leno.com slash changelog. Check them out and support this show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. Editing is by Jonathan Youngblood, and our awesome music is produced by Breakmaster Cylinder. You can find more episodes just like this at changelog.com or by subscribing wherever you

get your podcasts. Thanks for listening. Thank you.