Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytic solution. Don't know what that is? Go to logrocket.com, thanks. Brian: Hello and welcome to the Rocket Surgery episode of PodRocket. This is a special Rocket Surgery because not only is it me and Kaelan, but Chris Coyier is here with us. Hey Chris, we are very excited to have you on, we have lots to get to. The first thing that we should get to though is the future of CSS, which is a broad topic. And so I'm not going to talk to you about it, Kaelan is going to talk about specific things within the future of CSS like right now. Kaelan: I thought today we were talking about the future of CSS. It's something that we often talk about there is big picture topics here at LogRocket. CSS I feel like doesn't get as much attention, because people are focused on, "Oh, the shiny new JavaScript features." But there's actually a fair amount of new things coming down the pipe in CSS land, you might have heard of it under the umbrella of CSS Houdini, which is basically a package of features. But my big question is, say that I'm a developer, I don't know a ton of CSS. How do I know what I need to learn? Should I even care about the new features? Is there anything new coming along that improves my life or are we just adding more complexity? And then we have another question that we've had on this podcast, it's the role of a CSS developer and how that fits. So, I guess we're just interested to hear your thoughts on that. Chris Coyier: Okay. Where do you want to start? I mean you mentioned Houdini and the future of CSS, I guess those are... they're similar but I don't know everything that happens in CSS comes through the Houdini pipeline. I'm not sure, I mean, you may probably know more about it than I do if you watch what the spec people are doing so much. I'm usually a little more detached from it than that, I just am like, "Oh, people are excited about this, maybe I should look into it." Usually by the time I'm, I don't know, maybe this gives away too much on I'm how unplugged in I am, but usually by the time I'm interested in something, there's already at least an MDM article that's scaffolded out that has some information on it, because they're usually pretty on top of things. Kaelan: Yeah. CSS Houdini, for those who aren't aware, is basically a set of APIs giving low-level access like the Paint Worklet, which allows you to use it in scripts as an image basically. And a lot of these features, they look pretty, but people don't know how it'll actually fit into their workflow, there's awesome CSS Houdini and you can see all of it, they're really cool things. Chris Coyier: Yeah. You mentioned the Paint Worklet, I think it manifests in CSS as paint "as a function," but you have to have scaffolded that in JavaScript for it to work and then you can use it anywhere that you would need to paint an image. But now because behind the scenes you had JavaScript then you could use the canvas API to paint it. It looks pretty cool to me, I mean, I've seen demos that can do some pretty neat stuff, have a border that there's no other way you could pull off in CSS. So you can see how that opens a door, where there's confetti in the background, it's like there's no CSS property for confetti, especially programmatic confetti. You could paint a canvas on the frontend but not as a CSS background image, so it's cool but it is canvas, it's like stuff that you could do some other way, but has syntactically moved to CSS. It's compelling to me, but I have literally never reached for it for a production thing. Kaelan: I guess my thought is, we have a large body of people who struggle to learn all of CSS and then we're adding on really complex things that people don't need to know or learn in their day-to-day jobs. Is that a good idea? It's just going to end up being another web component thing where... Chris Coyier: Yeah, it's unknown. I mean, you could take that to extreme levels, you could say, "Do you need to know any of this, anything at all of this new CSS stuff to do your job?" Nope, you don't. Especially if your job is already okay, like you make sites for a client or something and you do pretty good and they pay you and you're happy and they're happy, who cares? You don't need any of this, none of it. I had a fellow just email me the other day. In his opening paragraph he said he's 75 years old. Not that that should matter, but he's trying to stay up-to-date with stuff and whatever and feels like, "Wow, there's a lot of new stuff." And he was even specifically asking about grid and flexbox and stuff, and that last time he did web stuff those didn't exist. And he was worried and wanted to know what's up, do you even have to bother with that stuff? Let alone, "Should I learn Gatsby or whatever?" Chris Coyier: Those are on very different scales of what you need to learn, but they can feel the same to a person who doesn't know either, they're like, "I don't know, they're just words and I don't know what they mean, so maybe I should learn them." And I was like, "No, I'm not going to give you a checklist of crap to learn, I don't know enough about your situation." You can't just blanketly say "Yes, here is your checklist, learn all of these things." It's just doesn't... I don't know. What do you do that you would need to care? But I did say it like, "Okay, so you're aware of grid, right? It comes along and you don't know it." Let's say you want to line up three boxes next to each other, here's two lines of CSS that can do that now with no caveats, no hacks, no bullshit. Sorry If this is a PG show. It just works. Cool, right? So I was able to teach him that, good enough. Maybe that's a useful thing to know when something that used to be hard got easier, that's cool. Chris Coyier: In the case of a Paint Worklet, nothing got easier, only things got harder there and I'm not sure that the selling point is as easy. That's where we left Houdini, Houdini has other stuff in it that just is interesting. One of them that gets no fanfare at all is like CSS being typed, that you could ask for a value. JavaScript people are like, "Okay, I want to know the font size of something." So I'm going to get a reference to it in the DOM and that l.style.fontsize it's going to return like 16 or something and you're like, "16 what?" And then you just got to know that it's pixels, but when then you set it back to the DOM, you can't just set 16, then you have to string append PX to the end of it for it to work and say, "It's just a little janky," and there's probably historical reasons for all this stuff, but wouldn't it be nice if CSS was more typed in it, like knew what units things were. Chris Coyier: Well, I don't know why, but that stuff is all jacked into Houdini. That's one of the modules of Houdini and it has different support across different browsers, but that's another thing. And then there's ones that are way more obvious how useful they should be, like instructing the browser how to do a layout. One of the things that Houdini promised was, not promised, but people talked about was, "Couldn't you write a Houdini layout thing?" This has nothing to do with types, has nothing to do with the Paint Worklet, but tell it how to do masonry. And I think there's been some demos out there that have proved that it can. So now that's much more compelling, it's that something that people have wanted to do forever, people often call it the Pinterest style layout because it looks like a brick wall in how things stack up together and there's no super great other way, even in CSS grid, to pull that off in a good way. Chris Coyier: Now, as I say that, grid does have a way to do it. They've decided to smash masonry layout into grid instead. It's cool and I think it's cleverly done and I'm not sure what the browser support is entirely, but it's going to be like instead of declaring your rows, you say masonry, so things don't have to line up on rows or something. I don't have it loaded into my brain at the moment, but it's a little controversial because it's- Kaelan: The CSS grid wasn't too complicated. Chris Coyier: Yeah. I'd say it's up there in terms of complication, but it's opt in complexity, the very basics of it are actually pretty darn easy, but it can get gnarly for sure. But it looks cool, it looks smart to me, I gave it the thumbs up, but absolutely everything in webdev, it has its elements of controversialness to the point where some people are very bullish and happy on grid or like, "Not the place for this." But sometimes the ship just sails without you and that's that. Kaelan: Yes, sometimes it feels like the [center 00:09:34] bodies get a little bit too far in from the community. Chris Coyier: Perhaps, like CSS has variables, they're in the form of CSS custom properties now. There was plenty of people that just said, "That's a bad idea." It adds programming stuff to CSS that in a way that changes the nature of what CSS is. Well, guess what? Too bad, it's gone. There's no taking it back now, it's in CSS so the nature of CSS has changed, you can't AB test history, move on. Kaelan: And another new thing, it was under some of the container queries. I guess you can split all the new features into two different camps, like things that will be interesting to maybe use like in a library that wrapped it and made it easier to use and then things that you might actually use in your own apps. And I guess container queries might be in the back-end along with good. Chris Coyier: That's a cool way to think about it, I think. We say the word grid and hopefully people listening to this podcast know we mean the spec grid, like display column grid in CSS. But in the early days of talking about grid, it could be a little difficult to talk about it because what people meant by grid was just the abstract concept of a grid itself, just to mean I want to make some columns and rows and use them in CSS and the way that I do that isn't CSS grid because it doesn't exist yet, it's with floats or inline block or something. There was some other way to do it in the [inaudible 00:10:59]. Kaelan: Back in the day. Chris Coyier: Right. And so you'd very, very often reach for a framework to do it. In fact, it might be the number one reason some people reached for a framework at all. Bootstrap probably had some degree of popularity just because it had a grid system in it and people like grid systems. And grid systems were complicated enough, that it was nice to not have to think about it, it was nice to be like, "Somebody else deal with this column math for me, because columns suck." Or the gutters between columns, things can get complicated. So you'd reach for a framework to do it and then grid comes along and notably, there are no frameworks for grid. I don't know if you've seen a lot out there, but if there is one, it's probably a joke, because you don't need one, you just don't, you just declare how many columns you want and what you want the gutters to be and that's it. That is the framework. Is that going to be the same way for these container queries? I don't know, probably. Kaelan: Yeah, whenever I use grid, I usually use Styled System in React. Chris Coyier: Styled System? Tell me about it. Kaelan: It's like CSS and JS, but utility level, it uses Styled Components, but... actually I think it uses Emotion, I don't remember, but it's just like wrapping the flexbox and the grid API in a really nice React component. So I think that's the furthest I would get with a CSS grid framework. Chris Coyier: And you use It because you like the syntax, right? You just have a prop that says columns four and you get four columns. But the abstraction level there is, that's fine, because you like it, you're in JSX anyway, for example, you are writing in React. I like the syntax of JSX too, I think it's nice. I like that Prettier it fixes it all up for me, it's just a pleasant developer experience. But the abstraction in this case, from those props to what it's doing in CSS, is super light. It's setting display grid and grid template columns repeat 1 fr 4 or something, like it's almost one to one line difference of abstraction. It's not as valuable as it would have been should we not have grid. Kaelan: It's just like shorthands though, and one of the best features, I think, about using Styled Systems, is you don't have to worry about putting invariables for your sizes, for your colors, it will add all that to your theme. So instead of working with pixels or even running units, you can say small or whatever label you want to give so and so size. Chris Coyier: Right. You've made an API for your system and then hopefully it's not just you, that for other developers that work with you, they're either going to pick small, medium or large and not invent some pixel value which can lead to inconsistency in your app or something. I liked that, I always think of these things as bumper bowling for design, that you can't screw it up, there's only three valid values, so pick one of these. I think that's, whether people know it or not, that's what they like about Tailwind or a utility library. It's that there's only four valid values or something or we set up our system to have our brand colors be these particular properties and please pick just from them. The whole world isn't open to you on purpose and I think they look at their output of their website and be like, "Look at how consistent it is, look at how nice it looks." Which is, they're reacting to how consistent it is and these smart defaults they set up, because they set up some bumper bowling so they can get strikes most of the time. Kaelan: That explains the explosive popularity of Tailwind. It seems like in the last year, now everyone's talking about it. I tried to use it in some side projects. I thought it was great and then I looked at the markup and I'm like, "Oh, this element has 15 CSS classes on it." My app takes one extra minute to build. Chris Coyier: So you found some downsides for it for your own project? Kaelan: Like everything in frontend development, it requires a ton of setup to get it working in the right way, like you can compile all your classes down and treeshaking basically. Chris Coyier: Right, right, right. I think that's not optional, at least in my mind in Tailwind, that it ships this massive amount of CSS that can cover almost anything CSS can do, almost I think, which is pretty impressive and cool, but that piece of CSS, they don't intend for you to ship to production. It's too much. They say, "Use what you use then at the end, pull out everything you don't use." And that can be done programmatically to some degree. I think there's going to be misfires, I think they'll be like, "Oh, but my ad network pulls in this div and this div has stuff on it that uses a Tailwind class. And how would this build system ever have known that? It can't see that, that came from some API or something." Chris Coyier: So there'll be edge cases you have to catch, but for the most part it can be done intelligently and then all of a sudden you're shipping probably way less CSS than I am. I'm not using Tailwind. I think that's appealing too to the Tailwind crowd. It's that you can ship in, the end, less CSS and CSS is a render blocking resource on the web and a lot of people are very performance focused on the web and that's cool. If you can ship a third less CSS, I think you're going to feel that. It's a cool thing to buy with just a tool at the cost of whatever else, all this set up and getting it wrong and maintaining it for the rest of your fricking life. Kaelan: Yeah, I like the idea of the utility CSS framework, because it seems like from a rapid prototyping standpoint, you can just bang out a component very quickly and get something on the screen. Chris Coyier: I'm so curious about that one. I feel like the Tailwind nerds, I'll call them, are into the idea of how fast it can be. They're like, "It's so fast, I just bang stuff out," like you said, but I'm like, "Why isn't it any faster? I don't get it." I'm like, "I don't feel slow putting a class on something and styling the class." The speed thing, it doesn't land for me, but it does for so many people so that leaves me in this curious state. Kaelan: Well, it's because you have to set up your theme, coming from other frameworks. I've had a similar experience in other UI libraries. One of them Chakra UI, which is currently my favorite component library, they go with the Styled System approach. It's like bringing some ideas, you could say, from both the CSS and JS and the utility first approach. It's because whenever you have a slight variation on something that's already built in, that's a pain point. And if you can avoid that, however way, it could be just so much faster. You can see how, in the state of CSS survey, I like looking at surveys, I always pull data from them. It really seems like we're splitting into three camps. You have the CSS module, people who use PostCSS, you have the Tailwind's nerds as you call them and then you have the CSS-in-JS people, which seems to be coalescing still around established components. Chris Coyier: Vanilla CSS people aren't represented at all in the survey? That's sad to me a little bit. Not that I have many projects where I just write raw CSS, but I do have some and it feels like that's also a perfectly valid approach to writing CSS is to write CSS. Kaelan: True. I guess it wasn't in the survey for whatever reason. I guess you would consider that in the PostCSS camp, because in the PostCSS you are writing some standard-ish version of CSS, like Babel was five years ago. Chris Coyier: Right. Especially if you're not piling. I always found PostCSS fascinating because it doesn't mean anything by itself. We say we use PostCSS to be like, "That's a parser." So that doesn't mean anything. But it generally has meaning, it probably means you're running Autoprefixer with it because that's the root of that. So okay, cool. These days, I think it's starting to mean more and more that you're running PostCSS preset-env or whatever, that seems to be the big package that is spiritually aligned with Babel. It's like, "This stuff is probably coming to CSS, so we're going to give it to you now if we can." I would guess that CSS is a little harder to polyfill than JavaScript is. I don't know if that's a fair statement, but there's some things that you just can't do it. Like custom properties is a good example, that's not a polyfillable thing really. Your browser either supports it or it doesn't. Chris Coyier: You can have variables like SAS does, you can polyfill that, but you can't polyfill the dynamic nature of a custom property really. So they have an interesting way of handling it, I think, where they just leave it in there, they leave the custom property in the code, but then they put a static fall back to it so that it's just not broken, whatever. I think that's just clever, but I don't know. I think that's cool. I take your meaning is that you're just writing regular CSS, but you're running it through a thing that does some clever stuff with it to be helpful, but it's not as dramatic as a change as Styled Components is or something, where you're literally writing an object for your styles. That's just super different. Kaelan: Yeah. And many people also have all of the above in a project, especially with Tailwind people, there's some packages that I've seen that mix Tailwind with CSS and JS for instance. Chris Coyier: Really? Kaelan: Mm-hmm (affirmative). Chris Coyier: Why not? I guess. Kaelan: Make everything more complicated, it's the final way. Anyway, switching gears a little bit, I also wanted to talk about something that I thought was absolutely crazy, web containers, If you saw it. You are the founder of CodePen, something that I've used for literally ever and I'm really a big fan of rapid prototyping on the browser. I guess I want to hear your thoughts on where that's going and do you think running node in the browser is insane idea? Chris Coyier: Oh, you mean the thing that StackBlitz put out the other day with how they can basically run Next in the browser? That's just extremely cool. It sounds like they worked for 18 months on it or something, to get it even going with the help of Google and stuff. I don't know anything behind the scenes at all, but their demo is cool and it looks like they have a really beautiful new home page now, you can click that Next.js button and it just spins up a Next app, rock and roll in the browser. I mean, technologically is it cool that Next.js runs in the browser? Yeah, it truly is, but I also kinda don't care. Chris Coyier: What's compelling to me is the rapid prototyping in the browser and the fact that it runs in the browser is neat, because I could lose internet connectivity and theoretically it still works. That's pretty rad. But yeah, I mean, it's pretty damn cool. I think WASM is behind it, like the WebAssembly thing underneath the hood, which is cool. I was just talking with somebody about a SQLite, that lib for storing data can be built in WASM and then shipped to the browser so you can literally run my SQL in the browser. Wow, that's pretty rad. Run your whole app offline in that way, that's the doors that are opened by that tech, so I guess we have Mozilla to thank for that, good job. Pretty rad. It's above my pay grade a little bit, but interested for sure. Kaelan: I think another part that I'm excited for is, does this make it easier for people to learn if they can spin up Next gen and this happened in 10 seconds? Not just the barrier to entry, but the barrier to even being exposed to these technologies. Chris Coyier: Yeah. I mean the answer is yes, yes, totally. I mean, I've banked my career on it, so I hope so, that like can this be better, can people learn tech better and faster if there's less crap in the way? And some of that is behind the scenes, like the fact that you go and you click this link and you spin up a Next site and it's already working. It's not just the speed, it's not just that it's offline, it's not just that it's impressive period, it's that it's already configured correctly. You're not going to follow a tutorial and type that crap into your command line and have it be like, "Oh, I'm sorry, your global version of Node is wrong." And then read a tutorial and they're going to be like, "You should install NVM, because then you can have the right version of Node on this project, but not screw up this other project." And then your NVM install fails and then actually you missed this comma in your package.json when you were adding a dependency and it screwed it up. Chris Coyier: There's a lot that can go wrong with that and the fact that you've clicked a button and it's already right and working, and that if something goes wrong, you have the opportunity to tell them what they did wrong, there's more to that than just the fact that it works. There's more to get right in the abstracting away the painful parts. This one I know because you can pretty much ask any developer and they're like, "What's something you don't like about your job?" And so many of them will say it like config stuff and troubleshooting stuff where it's not clear how to even start troubleshooting yet. They hate that, nobody likes that. Kaelan: Speaking about barriers, switching gears a little bit. Did you hear the MDN is going to offer a paid content service? Chris Coyier: I saw this is the thing that launched today. So you're on top of stuff. Brian: You were saying, that we have a Mozilla to thank for some things and perhaps maybe not to thank for other things. I think that's what I'm wondering about. As you have been responsible for creating or in some cases facilitating content, which is different obviously than MDN, I don't know. Based on the reactions I see on Twitter, it's maybe not that popular? Chris Coyier: This MDN plus thing? Brian: Yeah. Chris Coyier: Really? Brian: It's a hundred bucks a year. So I mean, it depends on- Chris Coyier: What my impression is that they're so not ready for us to be talking about it on this podcast, they were supposed to launch it to 10% of users, but then everybody got the link and are sharing it anyway. As far as I know, they have one writer that's doing some pilot content for it and- Brian: Oh, that poor person. Chris Coyier: Well, I don't know that to be for sure so don't quote me on that, but it's just a trial to see if they should invest more in it later. I'm sure you at LogRocket are Cheering for their demise as you make content for a living too. Not really, we're all friends here, but whatever. They make content, you make content, it's a thing. There's a lot that complicates this that I haven't figured out, surely there will be upcoming messaging that explains this stuff, but they had that big round of layoffs, involved a lot of MDN people or at least some, but they've been still working on MDN pretty good. All of MDN is on GitHub now, which I think is a notable improvement to their process. Kaelan: Actually, I think they laid off everyone. Everyone who was working on MDN. Chris Coyier: I don't know that that's fully true, because there's definitely content managers and staff that still exists that still talked about MDN. I mean, that transition to GitHub was after those layoffs, so it can't entirely be true. Maybe it was all literal writers that got laid off, but there's other people and they still have people on contract. I know personally people still on contract producing content for MDN. So the story is complicated, whatever it is and how do you know, you just get little bits and pieces from people you know. It's not like they are super public about stuff like that, but then there was this thing, what was it called? Open Web Docs or something? It was like a foundation that was formed and the idea was it's super funded, it has millions of dollars or whatever from companies and the idea was to be a protectorate, almost, of MDN and contribute to it and make sure it keeps going or something. Chris Coyier: I don't remember all the details, but it was something like that. So it seems like a funky timing to say that some third-party thing has to swoop in to protect this and then we're going to monetize the content that's being given to us from that foundation. The messaging of that is going to be tricky, I think, but this thing is like, I don't know, you save bookmarks and you export stuff as PDFs and stuff. Some of them what they're promising here is pretty lightweight. Kaelan: I like MDN as the impartial third party resource. I don't like the idea that it's going to turn into a commercial thing. I don't know, it's like the UN turning into a business or something. Chris Coyier: Yeah. But I mean, whatever, it's a business, It costs money to maintain all these docs, I should know, I had a bunch of docs myself. It takes time and money and people to do these things. The answer then is what's the best way to extract money from this valuable resource you have? There's not that many different ways. You could start a logging company where you add JavaScript to your page and then monetize it and then try to sell. Yeah, you could do that or you could slather ads all over it. That's what I do, works out okay or you could try to sell pro plans directly to it. So there's not that many plays. There's another play where they could have paid educational content that's a little bit more in depth. They could be- Kaelan: T-shirts. Chris Coyier: T-shirts, sell t-shirts, you're going to pay for half an employee I guarantee you that's- Brian: The other half is stickers and you would be good. Chris Coyier: Yeah. But you could be like a Treehouse or whatever, you could double down on real deep education. They also only touch core web tech as you'll notice. There's Houdini stuff and there's raw JavaScript API stuff, but there's not React help. There's a lot of things that you can teach developers as part of docs that are this trusted, that go a little deeper than what they already have. Not that this is an MDN help session, I don't know what they should do. They should just give it to me is what they should do. I'll take care of it. Brian: We could split it up. Chris Coyier: Yeah. You can take the front half I'll take the back half. Brian: Exactly. Actually, it's not a terrible idea. If you're listening, MDN, we're interested. Okay. So the last thing that I'm interested in is I wanted to run this by you and then get your thoughts. A few months ago, we, on the LogRocket blog, I was wondering really if our audience would answer questions, open-ended questions. So I just put a really small three question poll in the bottom left-hand corner that was asking open-ended questions about the future of frontend or just really how you are feeling about it and one of them was, what are you most frustrated by in frontend? And we got thousands of completes and far and away the biggest pattern was, there are so many things to learn, there are so many things for me to keep up with and I have no idea how to do it or even how to prioritize that. I'm wondering if that's something that you hear a lot too. And then if you do, what do you say? Is there a roadmap? Is there a framework to put this into? Chris Coyier: I mean, I've seen roadmaps, have you seen that those go around once in a while? Brian: Yeah. Chris Coyier: That are this little cheesy boxes tied to other boxes that say this is the stuff you should learn? Some of them are even well done, I think, They feel right-ish to these days, but is anybody going to do that? Is anybody going to print that crap out with a red Sharpie and cross the crap out that they learned? No, absolutely not. The only way anybody ever learns anything is just doing it anyway. People don't listen to your advice, you can give advice until you're blue in the face, they don't care what you say, they're just going to do whatever they want anyway. And probably they're going to learn by getting a job or being forced to do it in some way because they joined some bootcamp and that's the homework of the week or whatever, or they're just particularly motivated to get something done because they have some stake in the game anyway. Like they really want to build this thing so they're going to learn how to do it and build it and that can just be you getting dragged along, I think probably most people learn at work. Chris Coyier: I did a whole conference talk on this one time, that I'm falling behind kind of thing or how do I choose what to learn next? And in fact, I have a podcast too, ShopTalk Show is probably the most asked question on the whole show. Over 10 years of people sending in questions, people are obsessed with the idea of being told what to learn next even though they're not going to listen to you anyway. That it comes from different places is what's interesting. It could be that you're a boss already, you probably already know a lot about web design stuff and you still feel behind and you still feel worried because, let's say you have another project coming up, how do you know how to intelligently make choices for that next project? Maybe you just don't even know what's cool anymore or what you should be picking because of who knows what? That can totally be a reason and that's an extra difficult one. Chris Coyier: Just because it's like your choices hinge upon stuff like hiring, what if you're like, "I don't know, Google's behind Angular, right? How can this not be the most popular one?" Everybody likes Google. Well, you'd probably be wrong. I don't know, at least in the circles I run, it's not as popular of a framework. There's not as many Angular devs out there. I don't think boot camps are kicking out Angular devs like they're kicking out React devs. So if you just didn't know that and you're just like, "Oh Google, that's Angular's Google's framework. I'm going to pick that one." You may have foot gunned a little bit there and that it'll be a little harder to hire for. I don't know that to be true, but that's a concern. Brian: You get some really, in my experience, very passionate Angular devs when I'm like, "Well, we don't really cover Angular as much simply because it's not as popular." And they're like, "It should be more popular though. You should write more about it." I don't make the rules really. Well, I guess in this case I do, but do you know what I mean? Chris Coyier: Well, listen to Kaelan, he's talking about React right and left. Probably because you write React for your job, right? Kaelan: Yeah. Chris Coyier: Right. It's not like you're writing about... like if you used Angular at work, guess what? You'd probably write a little bit more about Angular. You might be one of those passionate Angular people if you felt particularly productive at work. Kaelan: I used to be a passionate Angular person, but my heart belongs to React now. Brian: Well, it's interesting. I mean, I know that when people write for us, they will pitch topics and I'm always like "Well it's clear to me what you use at work." It's clear to me what you're actively working on and fixing. So if I get a slew of Vue topics, that's what it is almost all the time. Chris Coyier: Yeah. I've done Vue projects so I can work that, but it also depends on that you have editors. Somebody there is in charge of making sure that what you publish is correct. At least it seems to me you all do a pretty good job. Not everybody does by the way. Kaelan: Thank you. Chris Coyier: But I won't even take an Angular article because I can't tech check it, I don't know anything about Angular. So if I did, it would be a greedy grab at, just like, "I don't know, it's tech content. I'll take it, I'll publish it." That's not fair. I could be publishing total garbage and it's not that I couldn't hire somebody to do it or something, I don't want to. I'd rather just be able to know, by looking at an article, whether it's basically right or not. I've been around long enough that I can do that for Vue and I can do that for React and some other things, but there's some frameworks, it's the same way for something like Ember, it's cool. There's good people that work on the project. I can't tech check your Ember stuff. So unfortunately there might be some self fulfilling prophecy there where we just don't write about it then and not that we have a big say in the popularity of it, if you're not publishing Angular stuff and I'm not publishing Angular stuff, that's all the less. Not that we're two small fry in a big world, but it does affect things overall. Brian: For sure. Kaelan: As far as fear of falling behind, my trick has always been side projects. Before I was a Reacts developer, I had a side project where I play around with React and I've always learned new technologies like that. I don't think I've ever actually completed a tutorial, ever. I always just jump in with a goal in mind. Chris Coyier: Yeah. I read the docs or whatever. That's why the docs are so important in how, I would think of that on your content team too. That's probably the number one email I write back to people it's like, why is your thing that you just pitched better than the docs? Because it's probably not, but then you just have to take it a different way, that's not a no, that means please don't recreate the docs, hit it from some other more personal angle. Kaelan: I have a point. You do get some docs that are way too verbose looking at your TypeScript. I'm not going to read 50 pages to figure out how to do X thing in TypeScript. So I think- Chris Coyier: Yeah. A little mini blog posts that says, "Here's how you make a generic type for your function or whatever. It can be useful alongside the docs." Yeah. Kaelan: Somebody called that a blog spam, but I think where there is a real need there. Maybe just a weakness of the TypeScript docs that they need to break it up. I've never liked how they- Brian: That's funny people call that blog spam? Kaelan: They do. Brian: I've never heard that before. Chris Coyier: I mean, I get what the meaning is. It's quite literal. I think it means, it's like casting a stone like your SEO. You're greedy, you're just going for a page view over the docs because you think it's just SEO garbage. Brian: Oftentimes We have to be like, "No, no," we will say the same thing, which is like, "The docs do this." Occasionally, they'll be a TLDR for a doc that, like Kaelan is saying, is a little bit too verbose, but there are also occasions where, I don't know if you ever noticed with your stuff, we will outrank the docs and then I go, "Well, as the Director of Content and LogRocket, that's cool, as an internet user, I don't really love that." And then usually LogRocket or not LogRocket, Google, realizes it a couple of weeks later and it's like, "We're going to put the React docs back on top." Chris Coyier: Yeah. You also got to be careful of how you're... you're a Director of Content, so you probably know more than I do about this stuff, but if you're logged into Google and you're doing those searches, that you go to LogRocket all the time, so Google might be helping you out in putting that search result higher, than me who goes there just slightly less than you do. Brian: Yeah. Kaelan: I guess if you're an open source project leader and your docs are outranked by a blog post, maybe if that's an indication of something then. Brian: Maybe switch to incognito when you're doing your search. Chris Coyier: Yeah. I'm not saying people need to bow down, but you could be a little thankful too. It sounds like your SEO is that... yes, you got out ranked, but your SEO is so low that there's no way I'm not helping you. As long as you're linking to them properly, that would be the jerk move, it's to not even have a link in your document to them. Brian: Oh yeah. Chris Coyier: What even New York times uses. Brian: Not yet. Okay, cool. I think we should probably wrap up. This is usually the portion of the show where we ask you what you want to plug, who you'd like to talk about, where people should go. It doesn't have to be you. What do you got, anything? Chris Coyier: I know we are doing plugs, but it is always mandatory in whatever podcast, that that other podcast audience knows that it's mandatory to go pro on CodePen as well. So after you've picked up your LogRocket subscription, you have to immediately go over to CodePen to do the same. Brian: And do your MDN plus, a link to everyone, just sign up for the things, yeah. All right, that's it. Thanks a lot for coming on with me and Kaelan. Chris Coyier: My pleasure, thanks so much. Brian: Take care. Hi, thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out, it's free to try then it costs money, but yeah, we'll see you next time. Thanks.