Paul Mikulskis: Welcome to PodRocket. Today, we have Rob Levin on with us. Hi, Rob. How are you doing? Rob Levin: Hey, how's it going, Paul? Paul Mikulskis: So Rob has something pretty exciting to share with us. So we're going to be talking about AgnosticUI. And to wrap it up really quickly into one sentence, to me, it's one UI framework that can fit with all of my frameworks. But I'm going to read the quote off of the GitHub page just to make sure we get it right. "AgnosticUI is a set of UI primitives that start their lives in clean HTML and CSS. These standard compliant components are then copied to our framework implementations for React, Vue, Svelte and Angular." So could you tell us a little bit about what you think AgnosticUI is and... Rob Levin: Yeah. Paul Mikulskis: A little bit about yourself. Yeah. Rob Levin: Absolutely. Thanks, Paul. Okay. Well my name is Rob, Rob Levin, and I'm a UI engineer and also I guess design technologist. I do a lot of style guides, design systems, UI component libraries. And yes, AgnosticUI is a component library. It focuses on UI primitives, so your really nuts and bolts UI components. And basically as you read in the blurb, Agnostic starts with HTML and CSS. So it's not tied to any JavaScript framework. It's not tied to React, Vue, or Svelte, it's initially done in HTML and CSS. So it's probably useful to quickly go through the process of creating a component, how I create a component in AgnosticUI. Say you have a button that'll start with a button.css and a button.html, make sure that that's using semantic markup, that the markup is accessible, that the CSS has got it styled basically the way we want. And then that button.css will be used in all of those framework implementations. Rob Levin: And so for React, we use CSS modules, which is an implementation detail, but basically that button.css That we originally made the component in gets copied over with a little Node.js script into the React directory and is used for the React button component. For Svelte and Vue, it's very much the same. They both use single file components so the styles will reside in the component itself. And basically, that same Node.js script will copy the contents of the button.css into those style tags using simple regular expression matching. So basically, the idea is that one button.css, the contents of one style sheet, is literally being used across the frameworks. And the reason why that's important is because once you've got your button branded to your company, you'd like to be able to use that same branded button whether it's React, Vue, Svelte, Angular. And that's the value prop and the promise of AgnosticUI. And I even have a CSS-Tricks article, which I'll link to, which does a very simplified version of building the button that I've been talking about. Paul Mikulskis: Fantastic. So it sounds like to me, I can build something in AgnosticUI and I could even make a little UI library for myself and run with that for the rest of my career no matter what framework I use, because it's going to be able to be ported over provided it's implemented. Rob Levin: Absolutely. Absolutely. And in fact, that's what I like to do is build design systems and the whole project started because I had built a React only design system. And then just as that was getting underway, I discovered that our admin was actually done in Vue. And then I met with our new Singapore team, which was offshore, and they were about to build a back office app and they preferred Angular. And so I was asked, "Hey, can we use Angular instead of React?" I was like, "Well the React component system is branded and really you're going to have to do it in React." And that was a bummer. And I was also I think tinkering with Svelte at the time. And I realized, "Hey, why does a component have to be tied to a framework, especially if what's critical from a branding perspective is really just the CSS?" Rob Levin: And so having tinkered a bit, I was like, "Wait a second, I can copy these over and just have a constraint that each component only has one style sheet." And so I slowly started working on it and did a couple proof of concepts and sure enough, it's definitely doable. Paul Mikulskis: Do you see any core piece of functionality that people would expect to be easily available not easily available because of the abstractions you have to make or the copying process? Or would you say that the majority of the functionality is still there? For example, could we get into a bit of Open Props? And how are those power components? Rob Levin: Absolutely. So let's see, Open Props the library, Adam's library? Or just- Paul Mikulskis: Yes. Yeah. Rob Levin: Yeah. Yeah. Oh, okay. Sure. So I did some experiments on my blog actually using the Agnostic Svelte package, and one of the libraries I experimented with was Open Props. And to back up a step, AgnosticUI is platform CSS. There's no SaaS, there's no post CSS. Those are great tools by the way. But for AgnosticUI, it's pure CSS. And so the only way to, of course, theme it is using CSS custom properties. So AgnosticUI exposes a set of themeable properties. And what I did was some experiments taking Open Props and assigning those where Agnostic became the in-house property, the way Adam demos it himself. And then have a little switcher where you can switch between indigo, cyan, blue, whatever. And then I threw in a custom theme where it didn't derive from Open Props, but really any CSS custom properties system could be thrown at this because they're just CSS custom properties. It's just platform standard. Yeah. Paul Mikulskis: Would you define a CSS custom property just an overarching class of properties that you could apply to a given style sheet? Rob Levin: Yeah. So CSS custom properties are a thing I guess that came about a few years ago I want to say. And I think of the syntax like a dash, dash and then property name, and then you have a colon and a sign of value. You would in SaaS, but it's on the platform. So those can be changed dynamically at runtime and the user agent or the browser will actually respect it. In fact, that's how a lot of light mode, dark mode switching is being done these days, you stick a class on the body tag and then the CSS custom properties are essentially reactive. So then you can just have your brand that was blue now point to whatever the inverted color is, maybe it's white or something against a black background or whatever that is. And so using Open Props, getting back to using Open Props, we're just assigning those values from one to the other. Paul Mikulskis: Right. Okay. So for me, at least in my mental model right now, that's mimicking Material-UI's different theming strategies where I can pass on the theme and then replace the value based on what that value might be. Rob Levin: Sure. Yeah, absolutely. I have an example on my blog which I'll link to so folks can see a more visual. Paul Mikulskis: Great. Yeah, we can include that in the podcast description for anybody that's listening or viewing can go check that out. Rob Levin: Awesome. Paul Mikulskis: So who should be using this, right, Rob? Me just designing things, should it be big companies using this? Who would you say is your first customer or intended user, I guess, of this type of library? Because it stemmed out of your professional need where you're like, "Wait, I see where this can go." But did it translate for that type of customer when you built it? Or? Rob Levin: Yeah. I mean in terms of today, it's a very early new library. So I think you'd want to be careful, you wouldn't want to use it maybe quite yet on an eCommerce site or something like that, but side projects and things like that. But it's coming underway pretty quickly. So I think it's also in good shape. But in terms of who would use it, you or I might use it on our blog or our side projects, companies could use it. The intent was, as you said, it was as I was working, the vision was like a design system. So say you're trying to create a design system from scratch, so that's something that I do and I've been doing for a long time, and I definitely believe in design systems. Paul Mikulskis: What is a design system? Just to define it real quick. Rob Levin: Yeah. Well so that's a loaded thing to define. So let me say a design system is usually a set of things. It'll be a UI component library, but also a definition of a bunch of patterns, it'll define the brand and identity, it'll talk about how content is used. So maybe I should avoid design systems... Well no, let's stick with the design system. So you're a design technologist and you're trying to create what you can offer was just say a component library inside a design system, and you're trying to do it from scratch. I've done this before and it's very hard to get enough of these components built fast enough to where the business is not starting to get a little impatient and questioning the ROI. Rob Levin: So one of the things honestly for myself was I wanted to have something sort of in the can because another very viable way to build a custom design system is just to build it on top of Bootstrap or Material-UI or Chakra or whatever as you alluded to, I wanted to have my own that had a couple of things, because I'm picky, the way that I wanted them to be. And I also really like this idea of- Paul Mikulskis: You're an artist. Rob Levin: Yeah. I'm an artist, right? Creative. I also like the idea of polyglot teams and having a polyglot code base. And most of the popular implementations of, say, Bootstrap or Material, well Bootstrap, it's a CSS library. Most of the ports, as far as I understand, are done from community members and they're not necessarily by the core team, I could be wrong, maybe the React one is, I'm not certain, but that's not necessarily the reason for Bootstrap being, right? It has solid CSS based components. And then the community adds things. Or let's take Material, same type of thing. Say I'm going to Vue and I know I like Material, am I going to use UDify or am I going to use Vue Material? They both seem to implement Material design, which one does it better? Which one has more bug fixes? Which one is tracking the material spec closer? I don't know. I have to go read blogs. I have to go install it. I'm not criticizing these different approaches by the way, I hope it doesn't come off like that, but just comparing and contrasting- Paul Mikulskis: They're considerations. Rob Levin: They're considerations. Paul Mikulskis: Right. Rob Levin: Right, right, right. And so AgnosticUI, the idea as a first class citizen was, "Hey, we're going to really focus on semantic clean HTML and CSS, and then use that CSS especially to derive these different frameworks so that if I'm working in React and I want to stay on brand and use Vue for my admin, I can and it'll still have the same brand." And that's all through the CSS custom properties that I've chosen. Paul Mikulskis: Got you. All right. That was a fantastic little overview about the motivation there. Rob Levin: Yeah. Paul Mikulskis: So if I were to go try to use AgnosticUI this evening, what do you think would be one of the biggest barriers to entry of somebody trying to approach this level of design versus starting with maybe their company has a design system or they just use Material-UI or something? Rob Levin: That's a great question. I think AgnosticUI is similar in the camps of Material-UI and Bootstrap in that it does give you a prefabricated component that you can then extend and customize yourself. So if you're not a designer, if I understood correctly, you're talking about some people might be more inclined to define the aesthetics of your whole UI component library and some might not. So you get a very nice off the shelf button or carousel, well we don't have carousels yet, but tabs and whatever, it'll look nice. And then as you want to customize it, you'll use CSS custom properties to do so. Gets to the various ways you can do UI components today. It's very splintered. You have atomic styles which are CSS utilities based styles, so that approach uses CSS classes in the class attribute of your HTML and people that use Tailwind or Tachyons would understand this approach, very popular, works great. Rob Levin: And then there's these camps where you have a prescribed initial component that you can extend and override and customize, and Agnostic falls in that camp, Bootstrap or Material would probably be in that camp. And then you even have CSS and JS, right? So styled components where you're actually dictating how the style should look in your JavaScript, and Chakra UI is a great framework for React if you happen to be in React for that. And there's styled components and other things that are popular. So all these things are viable and great approaches. It's like what do you prefer? And I think the reason why something like Twitter Bootstrap has been so popular over the years is it covers the broadest set of users, because you can customize it if you need to, but as you unwrap it, it looks pretty decent. Paul Mikulskis: It's very digestible upfront. Rob Levin: Yeah. And I think it gets a bad rap because a lot of people are like, "Oh, this has this me too Bootstrap look." But what people don't realize is with Bootstrap, you can import just one module if you'd like, you can override all the SaaS variables, you can use their CSS custom properties and their code's pretty clean. We used it at work so I've had to look pretty extensively at Bootstrap code. But yeah, so AgnosticUI takes a different approach because we don't use SaaS, but we use CSS class training or SMACSS if you've heard of that, SMACSS by Jonathan Snook, just a methodology. I might be getting into the weeds if I go down that road. But- Paul Mikulskis: Yeah, yeah. Rob Levin: Yeah, yeah. I'm a CSS nerd so I can digress pretty- Paul Mikulskis: What is the coolest thing in CSS that maybe it's not even practical, right, but it's just something that you love? There's this one guy I saw who programmed Bad Apple in CSS. Rob Levin: Oh, wow. Paul Mikulskis: Yeah, and that was very impressive. That definitely piqued my interest. Is there a project or something that you're just like, "Damn, that was cool?" Rob Levin: You know what? I'm in awe of all these geniuses that do that stuff, I'm such a nuts and bolts plumbing kind of guy. I'm amazed at CSS grid. So not very- Paul Mikulskis: Pretty dope. Rob Levin: Adventurous, but yeah. In fact, AgnosticUI does not supply a grid because grids, there's a lot of code involved with abstracting a grid in a CSS library. And so I had a Flexbox based one and it was a thousand lines of code. I was like, "I don't need this." I got rid of it. There are some Flexbox utilities. So AgnosticUI is not an atomic utility first framework, but it does provide a small set of utilities. And so you can use Flexbox through utilities. But otherwise, I'm like use CSS grid. And yeah. Paul Mikulskis: What is a utility? Rob Levin: Oh, yeah. Great question. So a utility is something like everybody's seen it, but they're not quite aware of what it's called. But basically if you have a CSS class that does one thing well, so say it says text capitalize and you plop that CSS class on your paragraph and it capitalizes your text, or text upper case, or font hyphen bold, so it's literally defining one CSS property as you would in CSS. And usually, they apply important because the idea is if you've applied a utility, you really want it to override anything else. So those usually get important. And the idea of designing or applying an atomic system is you assemble these different utilities, these individual classes together. And just like in CSS, if you imply five or 10 of them, all of a sudden you've got a really nice card and it's got a drop shadow and stuff. Rob Levin: And I also think that people that are proponents of this, it's different than inline styles because you do have a rhythm. So if you're applying spacing using something like Tailwind, you'd at least have some rhythm to your spacing and there'd be a rhyme or reason, you know what I mean? But there's big criticisms of it as well, which I won't get into. Paul Mikulskis: Well when it comes to- Rob Levin: To get into the holy wars of- Paul Mikulskis: There's a lot of opinions that are easy to find on the internet- Rob Levin: Oh, yeah. Paul Mikulskis: Very quickly. Well just for the record also, we heard it from the man himself, use CSS grid, guys. It's really great. It's very powerful. You can do a lot with it. I've always wondered when I've used Material-UI grid why I was doing so because it could have been done in six lines of CSS grid, but alas it exists. Rob Levin: Yeah. Paul Mikulskis: Extra stuff. Rob Levin: CSS grid isn't exactly easy to learn. You do have to spend a weekend maybe just wrapping your head around it. But once you've got it, it's there for good. Paul Mikulskis: Rob, I just want to pick your brain. I don't know a lot about frontend and I like to make my own apps, you know what I mean? And they're always terrible. So every time I do it, they're better. And I learn everything I did wrong last time. So it's really great to hear it from a master I guess. Yeah. I'm a backend person. Rob Levin: Yeah. Paul Mikulskis: But I guess we should talk a little bit about Agnostic UI in the roadmap for anybody listening who might want to use it. So let's get back into that and touch on what do you think the next big milestone for Agnostic is? Rob Levin: That's a great question. I mean it's very early, I'd say the roadmap priority is increased component coverage. I've got about 25 components and that's across four frameworks, so it's really more like a hundred. But I'd like to get that up. There's about probably 10 more that I need to really feel like it's a component coverage complete and that'll be maybe a V1 pre-release or something. And then after that, I'll probably incorporate dark mode and otherwise stability, bug fixes, edge cases and just really making sure it's solid and is usable in a real application. I'd love to have core contributors involved to help shape the future of the project. I feel like I have to get it underway and get it as far as I can myself. But eventually, I'd love to have some core contributors, especially if somebody wants to do the Angular stuff, because I'm not as keen on in the Angular. But it's there. Yeah. So that's the roadmap. Paul Mikulskis: So right now, if I'm on the GitHub, it seems like there are five contributors. Are these people that have just posted things up and just been in and out? Rob Levin: Yeah. Yeah, basically for the most part is typos or documentation fixes. I have somebody who's supposedly going to do a port of view to type script, which is exciting. So folks are starting to roll in, but for the most part, it's been me working alone. Paul Mikulskis: Got you. Is this your first framework that you've posted up or have you done other ones? Rob Levin: Ironically, I did do a SaaS buttons project eight or nine years ago I'd say with Alex Wolf, and it was really popular for back in the SaaS days. And now, I'm not using SaaS or post CSS or anything. So it's funny. I think SaaS is great by the way, but AgnosticUI is just very straight on the platform. Paul Mikulskis: Yeah. And also one thing I liked about it when I went to the website is it's very in your face about here are the things we do, you do it once underneath. And it feels like it fits very well into the frontend space right now at this point in the timeline, and hopefully as time continues on, it'll help consolidate things. Rob Levin: Yeah. I mean right now, you've got these cool projects like astro.build and Eleventy with Slinkity where they're doing this thing where you can server render everything by default, but then use a little directive to say, "Hey, I want this little part client side or partially hydrated." I guess they call it the islands architecture. Well Astro supports React, Vue, Svelte, and you can actually pull those in to a single Astro page. So I'm starting to do some experimentation, that's a sweet spot for AgnosticUI. And so you can imagine you're doing a site that lends itself to a static site generator like Astro, and you use one team to do, say, the header and the sidebar, maybe is in React, and then you have an image carousel and you do that in Svelte, and then an advertisement that's server side rendered and you do that in Vue. And that could all be stitched together with Astro. So I'm pretty excited about how AgnosticUI could stand on the shoulders of the upcoming giants. Paul Mikulskis: So it seems like on the roadmap, really paying attention to making sure this can be pluggable into this new landscape that's evolving with this modular style of having server side rendered. We actually had the creator, Slinkity, on a few weeks ago to talk about how his library worked. Rob Levin: I listened to it. Yeah. I listen to all your guys', or most of your guys' stuff and you guys are pretty frequent, so that's a lot. Paul Mikulskis: Yeah. Rob Levin: It was actually accidental. Yeah, it was accidental. I hadn't really planned it. In fact, actually I have to give Austin Gill credit for coming up with the idea. I was talking to him on his podcast and he was like, "You could plug this in with astro.build and use React, Vue and Svelte and Astro." And then you don't have to ship those frameworks down unless you opt in for client hydration. So you can imagine a world where you have maybe it's a React app already and you've got a lot of React developers. So you decide, "Okay, we'll ship some of the partial hydrated stuff in React. And then we'll use Svelte for these ad widgets that are server side rendered anyway. Well Svelte compiles itself away, but maybe Vue. Maybe you do these widgets in Vue, you don't have to ship the Vue run time down. Or you could do a completely statically server side rendered site and not ship anything down and use multiple frameworks. So it's pretty exciting to me. Paul Mikulskis: And the way that's changing with the edge now too, things are becoming fast. It's really- Rob Levin: Absolutely. Paul Mikulskis: So it's good to hear that you have your eyes on that for the framework, 25 new components, aka 100. Rob Levin: Right. No, no, no, wait, wait, wait, I meant 100 because there's four frameworks. Paul Mikulskis: Right, right. Yeah, 25 times four. Yeah. Yeah. It's lines of code that's got to be written. It counts as 100. Rob Levin: Yeah. I'm doing a menu right now. What UI component library doesn't have a menu? You have to have that. But data grids or exotic date picker, date range things, I love those and they're necessary. But for this framework or this library, I'm hoping to keep that in add-ons repo or something, but not in core. Paul Mikulskis: Right. Rob Levin: There's only so much of me to go around. I want to see my kids on the weekend, my wife. Paul Mikulskis: Yeah, those are good goals. Rob Levin: Yeah. Yeah, absolutely. If I don't hit them, I'll hear about it. Paul Mikulskis: All right, Rob. Well thank you so much for taking the time to come on and talk to us about AgnosticUI. We'll definitely be providing those links that we mentioned during the session below for anybody interested, not only to your blog, but also to the repo for anybody that wants to check it out, maybe contribute, look if it's something for you. Is there anything else you'd like to point our viewers to, Rob? Rob Levin: No. In terms of shout outs, well I shouted out Austin Gil, so I'll go with that. He's a really awesome frontend developer and thought leader. He's the author of Vuetensils and Bedrock CSS. And yeah. So that's a shout out. But otherwise, AgnosticUI is pretty easy to find. I did get the domain agnosticui.com. Paul Mikulskis: Heck yeah, that must feel good. Rob Levin: Yeah. Yeah. I finally picked the bull. I was like, "Well what is it? 10 bucks. I better just go do this." Paul Mikulskis: Awesome. Well thank you again and see you around. Rob Levin: Yeah. Thanks, Paul. Thanks, Kate. Speaker 3: Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcast. Thanks.