Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I continue my discussion with David Hemphill. David is a developer. He has built a bunch of products on his own and he's also a part of Rebel which we actually talk about in just a few moments. We also discuss Atomic CSS in today's episode so make sure you stick around. Today's episode is sponsored by the fastest growing cloud infrastructure provider, that is Digital Ocean. If you are looking for an SSD server that you can spin up in less than a minute, Digital Ocean is the answer to that problem. So we'll talk more about what Digital Ocean has to offer to Developer Tea listeners. Later on in today's episode but I want to jump straight in to the rest of the interview with David Hemphill. I know that that's a great intro to talk about your Atomic CSS beard.css. Yep. That's beard is by, I call out what is it. I don't even remember not to look at it. I call it an extremely pragmatic and utility focused CSS framework. Yeah, so it's definitely in the same family of all of the Atomic CSS sort of libraries and strategies out there that you'll see. I think it has a leg up on a few of them though. Well, first let's say that you actually ask everyone not to call it the extremely pragmatic and utility focused CSS framework. You said, actually don't call it that on GitHub. So I'm not going to call it that. I'm just going to call it beard. No, so here's the thing. Atomic CSS for those of you who are unfamiliar with what this concept is, is creating CSS rules or rather classes that only apply one rule and never allowing a rule to override another one. And David, you can refine that definition as it relates to beard further if it's different and beard. That's pretty much it. It might cover a couple of rules depending on what it is. But for the most part, it's a single class that does one thing. It has a single responsibility. And you kind of string all of these single responsibility classes together to get the structure and the aesthetic that you would like. And so there's parts of this that I definitely agree with. I like the idea of immutable, immutable classes that if you add this for sure, it's going to work. And that's probably the most valid argument for atomic CSS in my opinion. Yeah, that's even with object oriented CSS, which is, I guess it would be the grandfather of atomic CSS. Yeah, that's the same kind of deal that you focus on the class as the unit instead of, I don't know, like deeply nesting selectors or using the element selectors or anything like that. You would just focus on using classes only. I want you to convince me that I should use beard. And here's my question for you. Let's say that I'm writing some markup. And I know that pretty markup is something that beard is not concerned about. Typically, beards are not concerned with being pretty in the first place. Being markup is not necessarily a concern. But what I do want to be able to do is relatively easily change the way that something looks in the future. So what I use beard along with more CSS, for example, maybe use beard as, I don't know, mix ends, for example, or what I need to go in and change all of those immutable classes in the future. I wanted to change a particular, so let's just say I have a widget that appears on five different pages. And that widget has a selection of immutable classes that get applied to it. And let's say I wanted to change that widget on all five pages. How would I go about doing that? Would I need to go and change it in all five locations? Or would I add kind of a parent class and extend from those immutable atomic classes? How would that work? Well, definitely in today's sort of development ecosystem, it's not just like there's five HTML pages that you need to edit this widget on, and where you have this five different, in five different places, you know, in the modern kind of CSS workflow, you would, or if you're using like something like React or a component-based system, you have it in one place and you're using it in the multiple times. And so if you would edit it in the template for that widget, you would, you know, those changes would be represented in all five of those places. That's the most common case that I see. And Beard's kind of written for people that are working on apps and not necessarily just in a marketing size. But even though it's good for that, and I've used it for that. So if you had a widget on five pages, for me personally, I find that when I'm authoring things like that, I'm using some sort of include like that. If it's like a heading, a lot of times, if I'm using the same class again, I will abstract it out into a more domain-specific sort of class. I might say heading one or heading two. But though, you know, in general, I'm not doing that. Most of the time, I know what heading I want. I know how to get it quickly because Beard is kind of inspired by by them's like composable classes or something like Emmett, you know, where a class name, if you're just looking it from the outside, it might not make sense to you. But inside, if you know the system, it makes a lot of sense. So you might have a BGB that stands for background black, you know, or a text color white would be represented by TCW. And that, you know, that kind of, once you learn the system and kind of fall it for a while, it becomes really easy to write those classes over and over without having to look it up. So what I'm taking away from this here is essentially that Atomic CSS is particularly most useful when those widget types are kind of secluded into an includeable file, right? So in Rails, for example, that's a partial MPHP, you just do like a require once. And I don't know what it is for other things. But for the most part, those classes are only going to get written once. And so changing that particular thing only happens in one location. That to me is the most important part because the semantics are in the file name at that point, rather than in the class name. And I think that's a no-elk, Gallagher quote. Because a lot of people are concerned about the class names. They're basically, they look like gibberish if you're just looking at them without understanding what they are. You know, people are used to button and button dark and this sort of thing. And even other Atomic type frameworks like Solid, you know, the Buzzfeed thing, they have like Phil Red, Phil Blue. And those are really kind of descriptive of what's happening. And Beard, it's shorter because we want you to type less. We want you to write less and get on with what you're doing because in the tagline, it says, a CSS framework for people with better things to do. Personally, I wrote this because while I enjoy design and building things, when I'm building products like PushSilver, I need to do a lot of things really quickly. And so this kind of tailored towards that mentality. And Beard, there's this concept of like the scales. And so the type is on a scale. You'll have FT1 will be the first value in the scale. FT2 will be the second value in the scale. And then likewise, there's like border colors that are, you're using the first value in the scale and that will be one color. It can be your, and it's usually your branding color that we have you specify earlier in the configuration. And it kind of gives you this, I don't know, it's almost a built-in style. It's sort of thing that you can use to. For me, it helps organize some of this stuff. Sure. And that makes sense to me, actually, especially the idea that Beard and similar atomic frameworks, these are made for doing rapid prototyping. So you're putting a view up really fast. And typically, from what I've learned, particularly with these small, short classes, these short CSS classes, a lot of that information about what that class is either is directly available in the CSS or it needs to be documented. So let's say you run a large organization with 20 or 30 people. Atomic CSS in this format is probably going to be harder for the new guy or the new girl to onboard with because they're going to have to learn all of this kind of domain specific or platform specific stuff. And if they don't have a guide or, well, even if they have a guide, but it's a large guide, that's going to take them longer to digest. But if you are building a product, especially if you and a small team, like a restricted size team, if you're building a product rapidly, then this is a great idea. It kind of has this interesting dichotomy of value for different size teams, particularly because of the documentation problem. If you have this common pattern of naming classes, for example, so you have something like BEM, for example. BEM has this structural aspect. And if you can understand what the underscores mean and what the dashes mean, then you can kind of get an idea of what the rest of them actually is. So you kind of fill in the blanks. Whereas with something like an atomic set of classes, those blanks, if they are somewhat obscure, so, text color white being TCW, you have to learn what TCW means. And that's one thing, and then padding top being PT or something like that, PT2 or F, what was the F class that you mentioned? There's FT1 and then there's FW1, so font size 1 and font. Oh, okay. Yeah. So, and while that is certainly simple and shorter, for, let's say you're onboarding like five new people a month, which is pretty fast to be fair. But that level of documentation and training is significantly more than if you said, okay, underscores means that it's an nested element and dashes means that it's a modified element. Go forth, right? Those are two different conceptual things. My stance on this is that atomic is incredibly valuable, especially if you have a team that is smaller and is kind of restricted in size. In other words, it's not growing at a rate that is faster than, you know, say one person every month or two months. Yeah. I could see that. Well, you could say that about bootstrap. Every project, every project like that has its own sort of nomenclature and built in nice to tease that you kind of have to learn about. But definitely if you're having classes like ours that are basically, I don't know, they're not acronyms, but they're just short inversions of the actual attributes that you would write CSS. Then, yeah, that could, I can see how that would be difficult. I've personally found with the people at MusicBed, which is where beer kind of came out of previously we had this project called Kombucha that was sort of like beard beta. They seemed to take it on really quick and like it because it sort of made a lot of decisions for them. So, if you're designing something, there were, you know, a lot of times it's hard to decide what space you should use between elements. And it was this kind of limited your choices to anything one through ten. If needed something bigger than that, you could definitely write your own class, but kind of following the convention, but you would be rewarded for that and a limited consistency to the interface. I find things like beard and, and BIM, not to be, they're not like competing philosophies, but I think they can actually be complimentary because you could write a widget that has five or seven classes on it. And then it's, this widget is actually used in a, in a place where it needs to be positioned absolutely. And beer doesn't have, it does have some absolute positioning classes, but if it's, you know, just a value that's not inside of beard, I can see you definitely writing, you know, a specific class just for that instance of that widget. That would be different from, you know, somewhere else where you might use it. Does that make sense? Yeah, that's a great point. I think that this is all underlying a bigger point here, which is actually that CSS is difficult. Number one, and number two, it's very broad, right? Like you can do CSS in a lot of different ways. And so what you shouldn't do is try to pigeonhole yourself into only one way of thinking, right? So you shouldn't just think that BIM is the only way and you're never going to do it any other way. You shouldn't think that beard is the only way, right? You shouldn't think that atomic or, I don't know, smacks. You shouldn't think that those are the only ways to do things because that closes you off to new ways of doing things. And just as you're saying, David, you can have this atomic concept be totally living alongside BIM because CSS allows for it, that can be a very useful practice. In fact, quite honestly, that's basically how we work at Whiteboard. We use something similar to atomic. So we have great classes that are atomic in nature. They mean one thing, they do one thing. We have padding classes that are atomic in nature. We have some text classes that are atomic in nature. In fact, a lot of what Bootstrap has in it, like you said, is atomic in nature. You know, sometimes it will have two or three actual rules built in, but ultimately it does one, maybe two things. And then alongside that, we layer our more semantic classes, right? So the things that are named. And that has actually worked super well. And so I guess I come at this from the two perspectives. One, practically seeing it work really well, right? So from that perspective, David, you've totally won the argument. In a practical sense, atomic makes total sense. From a software design perspective, that's where it seems like it shouldn't. But this underlines another point that's important for every software developer to be open to, which is, I don't know how better to say it than don't knock it until you try it. There's so many things that you learn in practical software development that theoretically seem wrong. Theoretically, you shouldn't do it this way or that way. But when you actually get into the work, you realize, wait a second, that actually isn't all that bad. That totally makes sense. Before Beard, I was using BIM kind of across the board and basically forced myself to do that. I'm not paying in that because when you're using BIM and you're using something like SAS, you're, a lot of times you're doing extens inside of SAS or, what's the other thing, includes, I've used those features so long since I've been using Beard. But you'll be doing that. And so you'll kind of have these attributes or these objects, classes kind of obscured away in these really kind of domain-specific things for no reason. And I think that if you couple BIM kind of naming with something like OOCSS or Beard, you know, Atomic Framework, those classes that are domain-specific are really actually domain-specific and not describing something that is used in many, many different places inside your project. And so like display or the font sizing, all of those things can be global level things. Because CSS is really, it's global anyway. It's the main problem with it right now. Or you know, some people will debate whether that's a problem or not. But I personally am on the team hate the cascade. But and until we get some sort of CSS module system that makes all of this not useful anymore, then I think something like BIM and Atomic classes can live together and piece and make the development experience much better. And I know a lot of people will say with something like Atomic or even OOCSS that, well, that's no better than just using inline styles. You know, that's kind of like the first thing I hear from people that don't really understand it. I avoided saying that because I know that that's probably ignorant. Well, one, single classes are very non-specific and inline styles are the most specific you could write CSS. So that's the most important thing probably. Yeah. And no pun intended. Yeah, I like that. And so yeah, a lot of people will think that it's basically mudding up the markup, you know, and that they're used to hand crafting their markup and they don't want a machine, you know, to spit out their CSS form kind of thing. But basically markup is for machines. It's for machines to read the markup and to spit it out and format it. And so I don't necessarily reject a programming concept just because it's kind of ugly. You know, everything has to be weighed on its own merit. And aesthetics is one of those merits. But also if something being more visually appealing comes at the cost of being less maintainable, slower to work on, more costly, you know, that kind of thing, then, you know, aesthetics might have to go out the window for there. You know, the fact that we can argue over this kind of thing shows a few things. One, CSS still has a lot of room to grow before we figure it out. But perhaps more profoundly, development or programming is still something that requires opinion. And it's still something that requires experience to determine, you know, what is a good way for this particular scenario? And that changes. It's not the same for every scenario. It's not the same for every person. It's not the same for every team. These things are not set in stone. They aren't concrete. And what works for David or for me or for you, if you're listening to the show, if it works for you, if you love coding in Pearl, I don't personally enjoy Pearl. But if you enjoy Pearl, then don't let other people tell you that you shouldn't enjoy Pearl, right? Like if you enjoy a particular framework or if you found something that makes you productive, then go for it. There's not really a specific science to what should and shouldn't happen. Sometimes there are ways of measuring that and saying, well, maybe I should try something different. But if you experience something new, if you experience that, you know, I don't like Jonathan's way of doing CSS, I like David's way of doing CSS, go for it. There are plenty of reasons why this is still a huge matter of opinion more than a science. Definitely. You can't use something like atomic everywhere, even. So I can think of one case where a CMS might output mark down and you don't have the ability to touch any of the elements inside of that output. You can't apply classes to that the way you want. So I mean, you have to use something else like maybe wrap the whole content div in a dot mark down and style, you know, something more traditional CSS like. So you're going to have to mix and match any of these approaches anyway to come to a solution that's going to solve the problem you're trying to solve. And if you're like most people, the stuff that you're making on the web is temporary. Number one, and number two, it's a living document. So as you find new ways of doing things, just change it. It's live. It's one of the beauty, beautiful things about the web is that you can change it anytime. There's no reason why you can't experiment with new things, change things around. It's particularly more valuable for smaller teams and smaller projects. But as you find new ways of doing things, the web is not a book. It's not something that goes through a printing press and then it's done and you have to release new additions. That's not the way the internet works. The internet is constantly delivered. Brand new pages every single day, you know, dynamic delivery. It's an incredible process. And you should take advantage of that and allow your learning to evolve with the things that you're making. This is not the space shuttle. It doesn't have to be perfect the first time. Exactly. It's not a piece of healthcare equipment that's going to keep someone's grandpa alive. Yeah. Well, thank God. Yeah. I don't know how many poor grandpa's there would be if I was in charge of that. Definitely. If it's not right. Not on purpose. Not on purpose. No, I mean, clarify. Good intentions. Yeah. Yeah. David, tell me about Rebel. We've beat this CSS horse into the ground. So just for anyone who is wondering, I was playing the devil's advocate position there. I am not against David's beard.css. I want you to try it out. I want you to go to there's going to be a link in the show notes. Go and check out this. Would you call it a framework, David? I wouldn't call it that. I don't know what I would call it. You call it beard. Just another tool in the bill. Go and check out beard.css, which is on David's GitHub account. Correct. That is your GitHub account. Correct. I believe it's under monarchy. Okay. Yes. It is. That link will be in the show notes aspect.fm. But now I want to switch and talk about Rebel. But first I want to talk about today's sponsored digital ocean. Digital ocean is the fastest growing cloud infrastructure provider because it is a laser focused on its mission to create simple and elegant solutions for developers and teams. And that's not just a sponsor read that is true. Digital ocean has an incredible back end for developers. It's easy to deploy. You can spin up a droplet that is pre-configured with pretty much any popular open source framework. It is built to scale. They have an API and floating IPs. So you can scale it as you grow. And you can create team accounts so that you can manage it with your team, not just on your own. You can select data centers from around the world or you can deploy across regions for redundancy. And probably the most important part is that they are straightforward pricing. You only pay for the resources that you actually use by the hour. And there's no set of fee and no minimum spend. That means you can try out a server for just a few minutes and you're only going to pay for those few minutes, a couple of cents to try out a server. So you have almost nothing to lose. But to put the icing on the cake. The lotion is provided a special code for you to use at checkout to get a one gigabyte droplet for free for an entire month. That is not their lowest year. That's actually their second tier droplet and you get an entire free month by using the code Developer Teaat checkout. Of course, a link to digital ocean as well as that code will be available in the show notes at spec.fm. Thank you again to digital ocean for sponsoring today's episode of Developer Tea. Now let's jump back in and talk about Rebel with David. David, tell me about Rebel. Rebel is a company that has four partners and I'm one of those partners. We have Elias Reyes and Travis Gates and Ishmael Berciaga. And we all play different roles. But we're basically working on right now donor give, which is a giving platform for non-profits. It's very cool. So what made you see a need for a giving platform for non-profits? Well, our partner Elias, he works with non-profits and there's quite a few solutions that are out, but they're very, very dated. They don't have nice looking user interfaces. You know, some of the codes clunky. The reporting is not good. And so we set out to kind of solve that problem for a certain market of these non-profit people. At Whiteboard we work with a lot of non-profits as well. And there is very much so a lack of support in this area for non-profits. You'd be surprised actually because there's a lot of money in this particular business. And unfortunately, the platforms that exist, I won't name names, but they don't solve the problem very well. And so I'm really interested to see what Rebel ends up creating. Yeah, we're working on it. It's coming close to its beta, the first beta with our first customer. And I think we're getting somewhere good with it. It's been a long process. I've been working on it since July. Just now get a beta out is a pretty long cycle. One of the longest projects I've worked on so far. Just for the needs of a non-profit in this area is just great because you need to have reporting, you need to have exporting, user management, donor management. Those are different. Funds and managing recurring, putting all of that on the schedule, integrating with gateways, all of that sort of thing. Security, multi-tint application. Yeah, it's been a big project, which is maybe why there's not a lot of competitors in this space. Sure. A good job at least. Or a lot of the solutions are installable software products and not web-based. Yeah, absolutely. Well, this is one of those classic kind of, it looks easy from the outside kind of problems. You think, oh, yeah, I could make a better version of that. And then you start working on it and you realize this is far more complex than I ever would have imagined looking from the outside in. For sure. Yeah. There's a lot of things that you don't see when you're getting to the beginning of the project until you get in there and realize that there's just a lot of video secreties to all the beast. And coming up with a solution that's generic enough and for multiple organizations to use is a tough cookie to crack, too. Yeah, definitely. Because everybody has their own way of figuring out payroll or how they pay out their, if they're a mission organization, how they pay out to them or that sort of thing or how they even count the revenue can vary from organization organization. And most of these nonprofit organizations, they don't have a lot of energy to be able to change the way they do things. Yeah. A lot of it. They have a lot of legacy systems, then that's just how they've done it. Yeah. And they need to be able to import a lot of those contacts from those old legacy systems as well and even importing old transactions so that they don't have a weird, a weird year where there's like kind of two reports if they switch. Yeah. You know, yeah. With all sorts of little things you get into. Yeah. And it's particularly at least in the United States, I'm not sure how nonprofit stuff works outside of the US. But there's a lot of legal ramifications of what these reports are generating, right? This stuff ends up in the hands of the people who care about that 503C designation. So you can't get it wrong. That's right. It's incredibly important that the data is accurate and that you're not over or under reporting that there's not any rounding errors in your stuff. Yeah. That's all big problems. They're kind of going to have a good test suite to make sure all of that works correctly. Sure. Yeah. So again, you're writing this in in Laravel, correct? Yep. Using Laravel on the back end, using Viu.js for the dynamic parts and of course Beard has snuck itself in there. And it's working well, I assume. It is. It's playing more of a secondary role for like building out interfaces before he is able to get to it. And so sometimes I'll scaffold out the basic interface and he'll come in and suite it up. Well, David, this has been very enjoyable and super relaxed. I've enjoyed having you on Developer Teathis evening. Thank you for having me. I've had a good time. So I have a couple of questions that I like to ask everyone who comes on the show. All right. The first one is if you could give every developer 30 seconds worth of advice, what would you tell them? I would tell them to always focus on the people they're building products for. And not to be married to the tools that they're using because tools will eventually rust and break down at some point. But always to be pragmatic and build with the outcome that you want to have in mind. Not necessarily be married to dogma of what the current industry expects of you or what they say is best practices, but to kind of weigh each situation with the data that you have and the expertise that you have and weigh that against the goals that you have. I love that visual of the tool rusting. We don't think of digital stuff as expiring or as expendable. It seems like it could live on forever. And when a computer starts to act kind of strange or when things slow down, we say that it's probably a virus. Very few times do we think, wait a second, maybe this thing is just getting old, right? Perhaps it is out of date. And I love this visual of the tool rusting because that's such an important reminder that the things that we build are not permanent, the people that interact with them, those interactions are the thing that we're building. We aren't building a building, right? We aren't creating a physical thing. We're creating something for people to interact with. And if we don't get that part right, then it doesn't matter. That's right. For the most part, this is not art. There are creative aspects to it, but it's problem solving and solution building. And so anytime you treat it as art, it really becomes more about yourself than not the people that you're building for. So the second question I like to ask everyone who comes on the show is, what do you wish more people would ask you about? What topic do you wish more people would ask you about? I wish more people would ask me about getting products done as little as possible, using as little as possible to get it done. In what way? Well, I mean CSS is fun to talk about, right? It's fun to debate. And there's really not a situation you can arrive at that where there's like with a one true way. And back in programming is just a subjective a lot of ways and different approaches you can do it. And about getting the resolve to build a project, to build a product and market it and put it out there that I think for me, that's been the most interesting thing doing. I like using technology and I wouldn't want to do any other job, but I really enjoy building prize more than I do like any of those single aspects of it. Sure. Yeah. And so that would be great. So kind of the bootstrapping mentality. Yes. How to get from idea to a ship product as quick as possible. Yeah. That's, I mean, that's one of the most important pieces of understanding, you know, what it takes to be an entrepreneur. If you can ship early, when I started this podcast, for example, I had the idea and I shipped my first episode within a week. Now that's not too bragg, but instead to say that, you know, I move quickly. I intentionally decided that the idea and the implementation of that idea, there's an energy that kind of follows that idea that requires some level of action. Right. And if you allow an idea to percolate long enough, if you do it, you know, I'm going to have, if you don't act on that, then ultimately it takes more energy to think about it than it would have taken to just try it out. Yeah. That definitely resonates with me. And this new podcast that I've done, Dad's in development is exactly the same way. I think we thought about it on Monday and we were going to meet to talk about the first episode. And I said, let's just do one. He's like, well, my mic's not good. He'd already bought one on Monday to do it. And so we'll just ship it anyways. We'll apologize in the show notes and we'll do it. And we launched it. We launched it the next Monday. And now you have a story to tell about the mic, right? There's always a way to look at these things with a different light. You don't have to look at it like, well, the quality of the audio is bad. You can look at it like you remember that one episode where the quality of the mic was bad? Yeah. Those are two different perspectives. One is kind of a memory and a story and for those who listen to your podcast into the future, that'll be a moment in time for them that they can recall and perhaps appreciate. Yes. There's no such thing as perfect. There's only good enough. And you have to decide when is good enough and I prefer to say that earlier on. I prefer to ship it early and because it's the web or it's something like a podcast that is a serial in nature, you can just keep improving. Yeah, absolutely. Great advice, David. Thank you so much for sharing that and for coming on to Developer Tea. Thank you so much for having me. Thank you so much for listening to Developer Tea. I hope you've enjoyed the second part of the interview with David Hemphill. Of course, if you missed the first part, you can find it at spec.fm. If you don't want to miss out on any of the future episodes of Developer Tea, make sure you subscribe in whatever podcasting app you use. This does two things. Number one, it helps you be alerted in the future whenever we put out a new episode, which actually happens three times a week. And the second thing that it does is it actually helps other people find Developer Teabecause for every subscription, this actually helps Developer Teaget more exposure in places like iTunes. If you want to reach out to me, you can email me at Developer Tea at gmail.com. Of course, you can join the spec Slack community by going to spec.fm slash Slack that is free now and it will always be free to Developer Tealisteners. Of course, you can follow me at Developer Teaon Twitter and in fact, every single day, we tweet out the latest episode of Developer Tea. So that's a good place to keep up with the show as well. Thank you once again to Digital Ocean for sponsoring today's episode. Digital Ocean is the fastest growing cloud infrastructure provider and that's for a very good reason. They have some of the most user-friendly ways of spinning up a server that I've seen. Go and check it out, especially if you are looking for a cloud hosting provider, digitalocean.com. And of course, you can use that special code to get the one gigabyte droplet for free for one month. Thank you again to Digital Ocean for providing that for Developer Tealisteners and for sponsoring the show and thank you once again for listening. Until next time, enjoy your tea.