Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
What do backend devs think of CSS? ft. Lane Wagner image

What do backend devs think of CSS? ft. Lane Wagner

Bad at CSS
Avatar
672 Plays9 days ago

Do backend developers like CSS? Usually not. But that really doesn't matter because you don't have to like everything. So to get into the mind of what a backend developer thinks about CSS and how it affects their daily life, we brought on Lane Wagner, a true bonafide backend developer.

Links
https://www.youtube.com/@backendbanterfm/
https://boot.dev
https://x.com/wagslane
https://x.com/badatcss  
https://x.com/argyleink  
https://x.com/_davideast

Transcript

Introduction to Lane Wagner and BackendVenture

00:00:00
Speaker
Do backend developers like CSS? I will say it is my least favorite programming language to write. CSS is also basically not a programming language. This is Lane Wagner, and he's like actually kind of a serious backend developer. Assembly, particularly like arm assembly, which is what I learned in school. I mean, it's simple. He also runs the BackendVenture podcast, and his actual profession is teaching people backend development through his own company, Boot dot.dev. So we had him on the Bad at CSS podcast to figure out what exactly backend developers think about CSS. i'm a back in be and i'm
00:00:35
Speaker
this is the nerdiest thing i've ever which is incredible backend development So get ready for a real and actually balanced discussion.

Is CSS Harder Than Assembly?

00:00:48
Speaker
Welcome to the Bad at CSS podcast. We've got a guest today, Lane Wagner, SLC punk, back-end go rockstar. He's not a businessman. He's a businessman. He's a teacher, indie hacker, toot maker, and I mean like tutorial maker and lead on boot dot.dev already helping millions get a bad rack, a bad backend career.
00:01:08
Speaker
a rad back end career, a bad back end. You don't want one of those. That's what I have on 40. You don't want that. But what could be the baddest CSS podcast, man? What you bad at in CSS? It could be everything. I don't know. You tell me. That was the best introduction I've ever had. And I've been on like 20 podcasts at this point. That was incredible. The only criticism is it sounded like you said the baddest CSS podcast, which I guess could be interpreted as good or bad.
00:01:31
Speaker
I love that our logo looks like we said badass podcast. Everyone's like, it looks like it says badass. And we're like, yes, kind of. We like that about it. Well, I am bad at CSS.

Exploring CSS Anchor Positioning

00:01:40
Speaker
I'm the perfect guest, I think. so I've been very excited to have you on because Adam was telling me he was i was talking to this guy on his podcast and he was telling me that he thinks CSS is harder than assembly. Both Adam and I laughed at that because we were like, ha but no, it can't be. so I need and need this take care. How and why is CSS harder than assembly?
00:02:05
Speaker
So we have to be very careful with the word harder. It's not harder to get useful things done in CSS. like That's definitely not true, right? like If you're trying to do useful things, it's definitely going to be easier to do that in CSS than in assembly. But assembly, particularly like arm assembly, which is what I learned in school, I mean, it's simple. Almost like, definitionally, it has to be simple. There's not all that many instructions. There's not a gigantic API to learn.
00:02:29
Speaker
There's not radical changes happening every year when Chrome decides to add new features. right um so like From that standpoint, like assembly is a lot easier to learn the basics of. and Well, I shouldn't say to learn the basics of. There's there's just not all that much stuff happening in assembly. like You can learn the whole thing. Now, of course, building roller coaster tycoon in assembly is.
00:02:51
Speaker
It's not easy. ah It'd be very, very hard, and it would be wrong to say that that's harder than you know styling a landing page with CSS. But yeah, to like go really deep and and understand like the nooks and crannies of CSS, very difficult. I don't know the nooks and crannies of CSS. i know the I know the high-level stuff, or I should say the the basic stuff. We're still learning too. Don't worry.
00:03:13
Speaker
Yeah, I know. I still needed to learn anchor positioning. That's that how one is sick. Oh, I've been exploring that one in the past couple of weeks. We just record. Oh, it's good. It's so good. I got rid of position relative on something and then just got to like anchor it. And I was like, I love deleting position relative. I love it. Just like I like deleting float. Like, yeah, get out of my life. I don't need you no more. You guys got to explain this to me. Anchor your positioning. Tell me about this. Adam will have to be the one to explain to you.
00:03:43
Speaker
All right. All right. the the The basics are you have two two things need to participate in anchor positioning. You have the anchor, which is the thing that like doesn't move. All right. You could think about it's like the thing you dropped off the boat, right? It fell to the bottom and it's stationary. And then you have a boat that's anchoring to it. And that's what we call the positioned element.
00:04:02
Speaker
And so you you just give any element you want. You just say, here's my anchor name. And you say dash, dash, you know, my anchor and then any other element and it can be positioned fixed position absolute anywhere in the Dom doesn't have to be a child or none of that shit. You can just say anchor to that other one. I want to be on top and it's on top. And there's all these keywords for o tips I imagine, right? Like, Yes. And it even has a hidden keyword that's like centered on top and it'll allow the tool tip to widen and shrink and always stay in the center. It also has capabilities called auto flipping. So let's say you put a tool tip on top and you scroll up and the element is and the tool tip is about to exit the viewport. It will flip to be on the bottom.
00:04:45
Speaker
It's called a, it's like a complimentary flip. So if you positioned it with top, it knows that to flip would be to go to the bottom. And so as you're scrolling it out of view, it flips to the bottom to stay in view. And then as you scroll it out of view, there's another one called position visibility. And you can say, Hey, if

Backend vs. Frontend Development Challenges

00:05:00
Speaker
the anchor is not visible, then hide, hide the thing attaching to it and hide the thing that attaches just hides.
00:05:06
Speaker
And it's glorious. It is so so glorious. All these keywords, all of this noise that we were doing with JavaScript to get this behavior is just baked into these succinct, terse, amazing ah little anchor APIs. That's new, I'm assuming.
00:05:22
Speaker
yeah Yeah, and it's gone through some thrashing. Chrome early shipped it, ah and then there were some like working group discussions, and now we're in like ah the tail end of updating all those things, and then they're working on anchor anchor level two, which is going to bring even more stuff, like a tether, like the little dingle, the little dingled triangle. you know That helps you orient like what's this thing attached to you got like a little tool tip of a little down trying. So we're calling that a tether. And so what's hard about this like that flipping technique is really cool. But you're like, how do I position a tether to also flip to the bottom, but beyond top when it's underneath the type of deal. And so that's coming in the level two of the spec, you'll be able to add a dingleberry. And it'll be a perfect dingleberry every time.
00:06:07
Speaker
What word choice? ah it's a specbo
00:06:15
Speaker
i That's really cool. Building tooltips is kind of a nightmare. On Boot Dev, we were originally using, when the project was really new, we were using some off the shelf NPM package and then we wanted a lot more custom styling and stuff, so we rolled our own, and there's a lot of edge cases. You just got to write a lot of code, at least you had to. so Cool. I'll be checking this one out.
00:06:41
Speaker
Yeah, it's rad. It works really great inside of nested scroll views. It's really good too for commenting systems. It has another function called ah anchor size. And so the positioned element that's trying to anchor to something can ask that item what size it is and use it in a calc and be like, I'm double the width of whatever I'm attached to. I'm half the height or whatever.
00:07:00
Speaker
and it just enables all and then then it can also be spatially aware. so you can have it positioned to So the position element that's floating can have its left side positioned to the button and its right side positioned to the right side of the page. So you can anchor different edges to different elements and it makes that like Google Docs commenting system trivial, where they stack under each other.

Tailwind CSS: Utility and Limitations

00:07:21
Speaker
They're like yeah textually aware. Dude, it's out of control. ah Be excited. That's good stuff.
00:07:29
Speaker
radical This is the nerdiest thing I've ever heard, which is incredible coming from a backend developer. Yeah, like as a backend developer, so I once worked. ah I still do, but I once, once upon a time, I worked very heavily with a backend engineer. Uh, in the early Firebase days, uh, we launched Firebase hosting and, uh, pretty much Chris Rayner, uh, shout out Chris Rayner. He built so much of the Firebase hosting system, like kind of himself. And so he built, set up all the backend development with the CDNs and the cache purging and all this stuff and deployments and blah, blah, blah.
00:08:05
Speaker
And then he went to build the CLI and pretty much told me that that this was incredibly difficult. like yeah i'm Like he just basically built a system in which anytime you deploy your website, it will purge the cache in 2013.
00:08:22
Speaker
It would like purge the cache in all everywhere in the world. And boom, now you got your site all in these other spots. So it's like, it was pretty amazing, but, but a node CLI. Oh my God. And he considered that the front end. He's a very back end developer. So node CLI is front end for him, but he told me. he's front I mean, definitely. Come on. ah As a CSS developer, you're like, note CLI as back-end development. um But he told me what he found to be so difficult about building front-end systems that are back-end systems. So with back-end systems, he can basically set it up as a function where it's like, these are my parameters. This is the input. If I have too much of this, I can compensate for that. and and
00:09:02
Speaker
you know i can i can always like My problem will be like resourcing before it will be, like not understanding what will happen. Like I know what will happen. He's like, but on the front end, he's like, I have no idea what's going to happen. He's like, I feel like I cannot prepare whatsoever for what comes my way. And he's like that. If ah he's like, if it's a function, he's like the parameter list, the argument list is just like, you know, he's like, it's too long. You can't see the end of it. And, uh, I've always found that to be like an interesting comparison between the two. And I was going to ask you, is that sort of your take or you have anything kind of like some familiar insights doing both?

Frontend vs. Backend Testing Complexities

00:09:36
Speaker
Yeah, I think there's kind of two sides to that coin when it comes to like, whether something's like easier or or more difficult to test based on the environment. So I think it's absolutely true that the environment in which your front end code will run, whether it's a CLI tool that you're shipping, which, you know, and in a lot of cases I would consider a front end, especially if it's like a CLI tool that interacts with a server and that's his primary purpose. Um, something like, um, you know, the G cloud command line tool or.
00:10:04
Speaker
um the AWS CLI, those are very front-end. It's going to depend a lot on you your environment, what stuff you have in your path, right? Config files that need to exist in specific locations, different operating systems. like You have to take all that crap into account. And then the same goes with you know web front-end development. Different browsers, different APIs that are available. So like that's a nightmare that we just don't have to deal with on the back-end because we control the servers.
00:10:31
Speaker
Uh, so in that regard, you know, back in developer is, is back in development is easier or at least simpler. But then there's this other thing. Is it like doing like end to end testing? I'm like kind of in quotes and 10 testing on the front end. Yeah.
00:10:48
Speaker
way easier than on the back ends, especially if you're trying to like simulate real world load and stuff like that. Yeah. Because you don't have to. you know Yes. And also a load test, or I don't even use the term load test, but a Like a heavier integration test for front end is usually like a lot of clicks or like repositioning or adding things. Whereas like a QA person to click through the UI, like that's your end of the test. Yeah, you can use Cypress too and do all that type of stuff. But with backend development, while there's tons of tools and stuff for that, I mean, load testing itself is, can create like a large bill.
00:11:26
Speaker
Actually, low testing can create a bill larger than like your first like week of usage is going to be because you want to make sure. And yeah, i i one of the cool projects I ah helped out with like very tangentially um was when Firebase Cloud Messaging, ah you know, massive push notification service, i they had to do all this preparation for the World Cup. And as you imagine, lots of ah lots and lots of push notifications sent during that time, like sort of an unimaginable scale. And they wrote, I helped them out basically with this, doing images and kind of setting a narrative for this blog post. And as they were describing to me the things they had to do to prep for that, and they were talking about how the load testing on the backend would be so complicated,
00:12:11
Speaker
Because most traditional load testing and sorry for those who are listening, it kind of goes like a parabola sort of like, if you're like, Hey, look, it spikes up and we handled it. Now it's going down and we handled that and we're really good. But they're saying like, that's not what load looks like, especially during events like that. Like when the goal is made the yes, you get something else, but then he's like, it's a straight lineup and then you fall off 60 seconds later. Yeah. He's like. You're hitting these weird gaps. and he was the I made this image that was really interesting where it showed like where you could basically be missing how you could handle certain types of load. and That's where like people fall off on load testing is that they just do like a very traditional, like we handle the huge loads. So therefore if we can get this high on a load, we'll be fine. And

Learning CSS and Tailwind's Abstractions

00:12:56
Speaker
that's not the truth at all. Like there's so many more variables. Uh, but even at that, it's kind of cool that you can, you know, simulate and and do that in a way that I think actually you can't really do and in front of development. Yeah. And I will just point out, cause I'm assuming there's a lot of people listening that don't work at Google.
00:13:13
Speaker
like If you're working and as a backend developer at a smaller company, like just handling that very traditional spike might be a pretty good real like map yeah pretty well for your reality. um and so Doing all that extra stuff is, I would argue, kind of a waste of time. um but yeah like you kind of need You just need to know how your system typically spikes in usage and what that looks like and and then test for it.
00:13:39
Speaker
one One thing that you have me thinking of talking about assembly in CSS is is that if assembly is harder than CSS you know in your and certain aspects, does that make Tailwind a like higher level programming language?
00:13:57
Speaker
Uh, you know, CSS is the, the, you know, it's got, it's like Malek and all that. I don't know my assembly. smell are yeah Yeah, exactly. And it's, it's doing something tailwind is just like, you know, it's the, it's the C, the C plus plus on top of that, or I don't know. if Or is it tailwind like visual basic? I don't really know how high up the chain we're going here. How pro tailwind is this a podcast audience? Just out of curiosity.
00:14:19
Speaker
I mean, I started out when Tailwind was very young, like in 2017, 2018, whenever it was first out, like in its alpha days, using a ton of it. Like I built my original ah or one version of my personal site with it. i'm ah I love Tailwind. I don't like the view that Tailwind fixes CSS or that I don't need to know a CSS because I know Tailwind. Yeah, i'm I'm Pro Tail and I think there's a lot of ah great benefits for it. I mean, the style sheets people are making with it are really nice and tidy, short selectors. I mean, it's got lots and lots of really good things going on with it as a methodology. And I went, David, some of those things are annoying to me. Like, I don't mind escaping out of the the Tailwind um paradigm here and there, especially because I'm quite opinionated. and But for me, it's like it got it got really harder with the tooling. ah Like, I liked one and two.
00:15:10
Speaker
When I just sort of like grabbed a style sheet and I was like off to the races yeah But I do like the JIT compiler I like the way that it's sort of being additive and instead of subtractive because it was annoying then to sort of reduce the bundle after you after you got it But and ah yeah tailwind tailwind positive ah here

Educational Value of Utility Libraries

00:15:27
Speaker
yeah Okay. um So here's here's kind of my thing. So I've always been a back-end developer, but I've always been building side projects. um yeah And to build side projects that you want people to use, but turns out sometimes you need to write some CSS. So you know I started out with like Bootstrap again because I was like, I'm a back-end developer and I'm just going to use Bootstrap because that's what you do when you're a back-end developer.
00:15:52
Speaker
Um, I hated it. Um, didn't like bootstrap because I always want to do something different. And bootstrap is, this is the thing that has always bugged me about, especially, I don't think this is much of the case early on and definitely not, probably not people listening to this podcast, but you'll hear developers say things like, you know, I hate CSS frameworks because it like locks me into this thing. And that's like true about bootstrap.
00:16:11
Speaker
right That's like the whole purpose of Bootstrap is it's a style. um The thing I love about Tailwind is it's not a style. It's more like a um it's more like a philosophy of like yeah how to write clean CSS. It's almost like, you know not that I'm saying.
00:16:26
Speaker
The methodologies have equal value. But you can almost think of like clean code by Uncle Bob Martin as kind of like Adam Wadden's like view on Tailwind. I actually read his book, Refactoring UI, before I ever even knew about Tailwind. It's a great book. I loved a lot of the stuff in that book. And it's like, if you agree with a lot of those philosophies about how you should just like write kind of clean, maintainable and usable CSS, Tailwind is kind of naturally follows from that.
00:16:54
Speaker
So I'm a big fan. I drop down into CSS anytime I need it, um which which does happen. um And I like that, you know. for the most part, they don't, they don't really conflict, which is great. Um, boot dev is a very custom style. If you ever have visited the website, it doesn't look like bootstrapper. I think it's very custom and it's, it's for the most part it's tailwind. So, um, I guess to get down to your actual question, which was like, is tailwind kind of like, you know, I guess the way I think about like lower and higher level would be something like, okay, if like, see your assembly is lower level than like, you know, Python's maybe be higher level. I don't really think of it too much that way.
00:17:31
Speaker
A big reason for that is like when I learned Python, I learned a lot about coding and and computer science and programming basics, but the lower level details, like ah again, about like memory management, malloc and free, all that was abstracted away and I didn't learn about it until I explicitly went down a level to learn about it.
00:17:48
Speaker
I feel like like you kind of just learn CSS as a natural byproduct of using Tailwind, which is fantastic, which you can't be said of other um libraries that again are very prescriptive about style, things like Bootstrap. Like I don't think when I was using Bootstrap, I was really learning all that much about how to um use CSS. I was really just kind of trying to take ah a styling shortcut because I was a bad designer. So yeah, I'd say it's a little different. That's a beautiful answer.
00:18:18
Speaker
I like it too. I'm thinking over here, like

Lane's Take on Backend Languages

00:18:20
Speaker
underscore and low dash, like, um, those don't have the learning JavaScript benefit like tailwind offers to a CSS author, right? They're both kind of utilities that you import and they give you all these things, but with tailwind, the name is so close to the property value that you're using that your brain.
00:18:37
Speaker
Kind of just learns to mini map and my and micro map like these short names to the long form thing and that doesn't happen with low dash or underscore right you're sort of like using group by and you're like I don't know how group by is working but I want to group by this key you know if if somehow low dash it gave you these things and exposed it to you more like maybe if you copied and pasted it into your project instead of just importing it and using it so high level. So yeah, Tailwind does sit in this fun middle ground where I genuinely think, well, and yeah, you have to be in the mentality and you also have to not be ah copying and pasting too much. Because if all you really do is copy and paste components from presets, you're just not going to learn UI. But then again, that's not your goal at all either. You're not trying to go custom at that point. You're trying to just
00:19:21
Speaker
And also, I like that Tillwin shows you the composition in the class name stack there. So you kind of get to see how all the pizzas and parts and bobs and and effects all come together in a nice little view. Yep, it's good stuff.
00:19:34
Speaker
that That bit on the learning is interesting. and Like you mentioned Lodash, which I'm not familiar enough with load lat Lodash to make like a really good comparison, but but maybe a similar comparison that I think is similar is, um so we teach Python on boot dev and there's like you know a dot sort method or a sorted function. And we have lessons on boot dev where we're like explicitly trying to teach how sorting works.
00:19:59
Speaker
ah right Not because you're going to be writing a lot of sorting algorithms from scratch, but it's good to know that like sorting lists is an order n log n operation, and here's why. and It's also just really good brain teaser practice to get you think thinking algorithmically. and you know Some people pop in and they'll be like,
00:20:17
Speaker
you know define bubble sort uh first line uh list dot sorted return it but right and they're like my solution is way more elegant than the the solution given by like like boot dev and the answer key mine's only one line it's like yeah but you didn't sort anything by yourself so there's like There is this idea when you're learning about finding the level of abstraction that isn't going to hinder what you're trying to learn. Now, that doesn't necessarily mean like if you're not trying to learn how to sort, then yeah, by all means, use the built-in. But especially when you're new, you know being trying to be very aware of the tooling that you're using and whether or not it's it's helping you understand fundamentally the stuff that you're working on ah is important because it's not always obvious.
00:21:06
Speaker
Adam, do you think you could implement bubble sort off the top of your head? I could implement a sort that bubbled things and I don't know if it would match the computer science. It would be bubble sort. If you invented an algorithm for sorting on your own, it's bubble sort. That's the one you will invent unless you're a genius.
00:21:25
Speaker
Bubble sort is the one where you literally do like, uh, each one only goes up or down in the array, right? And it just kind of trickles and then it reruns and it continues trickling until it's like, doesn't have any more pieces to scoot. I think that's like the proper bubble sort, but I

Simplifying CSS Development

00:21:40
Speaker
would have cheated and just sort of like reduced and then just inspected everything and figured it out and just been like, all right, I made, I didn't bubble anything. There are slower ways to do it, but it's like one of the slowest and simplest ways to sort. Yeah. probably could only do bubble sort off the top of my head. If I sat down with like a group of objects, like, you know, I'm having to like, and I could physically do bubble sort in my head. And then from there, I'd be like, okay, yeah okay. All right. Now I can write the code. Like I don't think if someone like just looking at like a blank file, I couldn't do it. I, but if I, if I, for most sorts, actually, I think I could do that. I'd be like, Oh, what's the thing with merge sort? Like if I physically do it, then, you know, I can, I can, I can write it, but it's, uh,
00:22:23
Speaker
That's actually, I remember in school, the only thing that helped me with sorts is when um we all stood up in the front of class and physically sorted ourselves according to the algorithms. And then I remember being like, okay, now this makes sense to me. Like, okay, all right, this is fine. Before then I was like, this is, this makes no sense. I love reenactments like that. It's so fun. um And there's even one, I really want to do a video with Jason Langstore for, i' I sit down at my computer and I NPM install um next or whatever. i just And then all of a sudden like four different people show up over my shoulder and like one of them's the linter, one of them's the, ah one of them's Husky that's watching my Git commits, another one. And then we're like, oh, okay, hold on. I need to add a style in. I had a style in, another person's head comes up and all, they all just start whispering to me the whole time I'm typing.
00:23:08
Speaker
Are you sure you want to type that? Hey, uh, I know you're half done typing that word, but it's wrong in its current state. And I'm like, shut up. You know, like eventually. And then, but I'd love to see it next to another dev, like some dev that's just like loves them. You know, it's just like.
00:23:24
Speaker
You're right. Thank you so much because there's so many devs that they stack on 10 to 15 different tools that are all, you know, co-pilot mixed with this, mixed with that. And I'm like, that's like 10 different people over your shoulder telling you what to do. And I, that drives me nuts. this is not so like Just seeing these two different juxtapositions of developers, one of them in love with all the 10 heads behind them. And one of them that's just like, get off of me before I backhand you and delete you off my machine.
00:23:50
Speaker
I love the, I love the tools at the right time. So like, yeah I hate Husky, for example. It's like, shut up, shut up. I'm going to commit this. Uh, if it's a bad, I can fix it later before I open a pull request to go into everybody else's repos. But like, I'm local. I do local. Um, same with, uh, same with like the, uh, the tooling that will like tell you you're, you're, you're typing it wrong, but you haven't finished typing it yet. It's like, well, I don't want to format it now. I want to format it. I'll format it later i'll format it on save or something.
00:24:20
Speaker
TypeScript would be the one over your shoulder being like, that's not going to work. Uh, yeah, no, you know, it's the, no, you need change shit. might be normal ah Did you know that? Did you know that that might be no, Hey, Hey, it might be no, you really, really should check if it's the i'm like, dude. Shut up. I'm not even done completing my thought.
00:24:38
Speaker
you know but yeah you know we We can't be certain we know what that's going to be. so you know like You're going to need to clean that up before you can write the next line. That is so funny. yep Personifying all these things is really fun.
00:24:54
Speaker
So with Lane, you have lots you know lots of backend experience. If you're talking about right in Python, teaching Python,

Evolution of JavaScript Tooling

00:25:00
Speaker
you told us previously before we started your Go developer, you talked about assembly. Could you give me yeah a list of your top five most difficult backend languages that you know with with your experience? you know Anyone can put like... you know brainfucker like Haskell or something weird, uh, to me brainfucking Haskell are the same, but, um, but, you know, what, what would your five be? Most difficult. I mean, I don't, if I don't like them, I don't work with them is the problem. Right. So it's like, I've i've worked with several that I've been like, yeah.
00:25:35
Speaker
I don't want to do that anymore. I'm just not going to do that anymore. The most hated, again, I don't know if I'd say difficult necessarily, but I don't enjoy working in Java. It drains my motivation to do anything. Yes, share us your hate. Show us your hate. It's not just the language or the tooling which are abysmal already, but the culture surrounding Java is disgusting. And I mean, I mean, not like the human culture, that would be very rude and probably cancelable to say. Not that. The like the coding culture, the technical like coding culture, like I hate the like endless factories and abstractions and like solid design principles that come with it.
00:26:21
Speaker
Um, I hate all of that stuff. So Java for me is like, that's the last one. I would go write PHP before I'd write Java and I'm not a fan of PHP. So that's like, I think that's the only two I could really, really complain about. So you're not a fan of having an abstract factories all over create abstract factory, uh, method.
00:26:40
Speaker
i am you know I'm not a fan. I like defining struck liberals in Go. they're They're very simple things. it's It's a group of fields, and you're done. And that's it.
00:26:52
Speaker
There is a site internally at Google where you can, um, I can't remember what it's called, but basically you can look up what the longest, uh, method names are in, in like code base index in Google. And you, and there's like, you know, you can see like but it pyramiding down, uh, pyramiding by sort of like, you know, sort of descending down and where I can't remember where the longest ones are, but they are like scrolling and you're like,
00:27:19
Speaker
You know, and they're following the convention, like you, cause a lot of times I'm like, why would you make it that long? And it's like, that's the rule. Like they, there is no choice not to. Yep. Yep. Working at Google. I could be wrong. We're Googles back in systems, primarily written in Java before all the go stuff. Yeah. I mean, from what I, I mean, there's a lot of Python. Yeah. Yeah. There's a lot. I mean, there is a lot of Java, but also a lot of Python.
00:27:46
Speaker
Um, I actually, I remember when I joined in, uh, 2014, uh, you, I had that same sort of idea, like, Oh, it's gotta be Java. It's gotta be a ton of Python and all that's true, but I mean, it's a large company, so a lot of code. But I remember someone told me that, uh, the, this is in 2014 and I have no idea about the stats now. um They're like the largest, ah that the most common programming language you use, like more lines of code is JavaScript. And and that's just because, you know, and and I also think it's funny that so much of like Google's past, I think now it's not there, but it was like trying to keep trying to not write JavaScript, like, you know, like
00:28:21
Speaker
Uh, like GWT, uh, man, I, this makes me so sad because I'm going to say GWT and I'm fairly certain there's a lot of people listening to this podcast right now who are like, what is GWT? And, uh, they're not saying JWT, you're saying GWT. It's the Google web toolkit. Yeah.

Understanding CSS's Declarative Nature

00:28:40
Speaker
quit GWT, that's how it's lovingly known, Google Web Toolkit, which was building, uh, which when it came out in, uh, 2008, um, was considered like so ahead of its time and you could write JavaScript as our Java and create websites with it. Uh, so it sounds like a perfect.
00:28:58
Speaker
Uh, tool as you should rewrite boot dot.dev in GWT. Literally the only thing worse than JavaScript is Java. I can't. And what's amazing about GWT though is, is that the tooling in GWT was so far ahead of its time.
00:29:13
Speaker
even to this day, it actually is, they would be able to, uh, minify all of your JavaScript classes based in the HTML, based on the, uh, based on your style sheets. And it was able to, and it was like a front end. It was like a, you know, a whole full stack framework. And so any, uh, like any payloads you'd send down to the client would be able to get like analyzed, and they would cut like unused properties and things off of stuff. So like from a tooling standpoint, it was actually kind of mind blowing how much it did ah that we still actually don't have today. um But yeah, you it was all in Java, so it was kind of doomed from the start.
00:29:52
Speaker
I mean, it was really popular for a long time, but I think its longevity was due from the start with that. I hate Java too. It was one of my first programming languages um that I built anything like substantially with. And i ah I couldn't wait to get out of the typed strict hell that it brought me. That's the wrong reason to hate Java. You're hating it for the wrong reasons. ah there's There's plenty of reasons. i I agree. But yeah, I was just like,
00:30:18
Speaker
It's just so much work. There was so much to type all the time. And then, yeah. Okay. Here's a question for Elaine. Curly brackets after your function name on a new line or right after the, after just on the same line. New line is unhinged behavior. You could be friends. Okay. Yeah. It is when you see like, if, and then it's like the brackets, like right below the if, like I'm always like, it looks like the code's broken. Like I know it will run. I know it will run.
00:30:47
Speaker
But part of me does it wishes it wouldn't like, I'm like, I wish this code would not run if it was written this way and go, it wouldn't, um, yeah go, go cares about white space to an extent. I mean, that's kind of true. It'll like, it like adds some stuff so that it like doesn't care about it after. But like when you're writing the code, the white space actually does matter a little bit, not nearly as much as Python, like it matters a little bit. right Um, and it ships with a formatter. So you don't get that sort of nonsense.
00:31:17
Speaker
Oh my gosh. And speaking of Go, i Go has

Challenges with CSS Performance and Debugging

00:31:20
Speaker
lots of cool concepts in it. One of the things that I am constantly, when I talk to Go developers, me my primarily being front-end web developer, so lots of JavaScript, lots of CSS.
00:31:31
Speaker
I talk about, uh, like asynchronous programming and Go developers must, it's, I think it's a rule that if you talk about promises or callbacks or something in JavaScript, Go to developers have to stop and be like, well, in Go we have co-routines and, uh, they are a superior form of asynchronous, you know, if asynchronous programming. Uh, but they're kind of, you know, a little difficult to to wrap your head around, especially if you're not used to that environment.
00:31:55
Speaker
Uh, and so what would you say is easier to learn, uh, like go, like co-routines or any, uh, complex go, uh, concepts or like CSS positioning or like CSS box model and like margin pattern. Like, what would you, what do you think is harder to wrap your head around?
00:32:13
Speaker
Well, first I have to, um, actually, it's not co-routines, it's go-routines. Yeah, you're right. And you're in go. They are co-routines. Yeah, they're co-routines. The more generalized idea is co-routines. But in go, they're they're a little more specific and they work a little differently. um ah there's There's some... there's some Some additional Go kind of magic happening. OK, so it's a good question. Let's take the like very basic like example of fetching some data. right So you're making an HTTP request and you're fetching some data. In Go, the HTTP dot.get method in the standard library um is synchronous by default.
00:32:56
Speaker
It won't do anything in the background. They'll just sit there and block till the network request comes back. To me, that's more obvious and easy to understand, right? There's no gotcha there. It's like

Benefits and Challenges of Declarative Code

00:33:10
Speaker
I make the request and then I sit there and I wait and then it comes back and then I keep going. JavaScript land is... nuts because it does all this extra stuff because you can't block the main thread. It's like, why can't you block the main thread? Well, sorry, you can, you shouldn't, yeah right? You shouldn't block the main thread because that's rendering stuff on the screen. ah And that's like a whole bunch of extra um assumptions that JavaScript is running in a browser, which used to always be true, is not true so much anymore.
00:33:41
Speaker
um And so like you're writing a command line tool. It's like, why do I have to explicitly await this thing? Shouldn't it just wait? And so anyways, I guess my point being, when I'm writing JavaScript, you have to remember and you have to kind of know what's going to fire something off to be done in the background. And you have to know, especially if you're doing dynamically type stuff rather than like TypeScript.
00:34:02
Speaker
You just kind of have to know and you have to await it and if you don't, you'll get like some weird errors or like you're trying to interact with a promise because you expected it to be raw data, but it's actually a promise. Whereas in Go, it's like, okay, if you want to do something in the background for performance reasons, then you use the Go keyword. So it's just like the inverse. Instead of awaiting things explicitly, we're going and doing things in the background explicitly.
00:34:23
Speaker
um The challenging part, I don't think, is the um which one of those you choose necessarily. Again, I think the the goat like the explicit go do something in the background is a little easier to wrap your head around. I think it's just the fact that like concurrency and parallelism are hard to reason about, just just like always. but No matter matter what you do, like those are yeah those are just hard concepts. And so to go all the way back around to your question, it are those concepts in In whichever language you're using, are they harder than like, you know, padding? and
00:34:57
Speaker
and and spacing and stuff like that. I would say definitely. I think there's some of them the more difficult, and I can almost say that objectively. I mean, I can't say actually objectively, but I watch a lot of students go through our full like computer science and backend curriculum. And there's like a few places where we're definitely like the sticky parts and it's like recursion and concurrency or like the two that I'd pick are like probably the hardest for most people.
00:35:22
Speaker
you know What I have learned from our wonderful guests on this podcast and Adam is I think the essence of why people have struggled with CSS is really the idea that a lot of back-end development or even web developers who dislike CSS or tend to be JavaScript developers is that a lot of the things you're doing ah with these languages is very imperative. You're like, I want this. Give me that. Go go do this. You're writing all this like instructional bits of code.
00:35:51
Speaker
But with CSS, you can't do that. It is declarative. and it is and On top of that, CSS, even though people talk about declarative, it's such a great thing, but it's more so what it represents. It's not just declarative in syntax, it's declarative in like and function because everything that you do in CSS, they're saying is is a request. and so It's saying like, hey, we will try that. We will we will try to get to that that we that you wanted to do. and You know what? It's probably going to come out that way, but it's not going to.
00:36:20
Speaker
And I think this actually circles back to what you were saying previously. You're talking about like how end-to-end testing can be easy. ah But the difficult part is that if you look at like the matrix, like if you look at a matrix of like even doing something like testing ah a CLI, you're like, OK, who's got to it's going to be on a Windows device? It could

Frontend Development Challenges

00:36:40
Speaker
be on node 18, but it could be on a Mac on node 20, or it could be on Linux on this one. So you can you can kind of like you know it can get kind of large.
00:36:48
Speaker
ah for like the human eye, but for like an end-to-end test system, it's pretty simple to like run through all these tests. When you want to create that same matrix from a front-end development standpoint, it gets unreal because you're like, what browser? What version? What computer? ah like all these different like What screen size? like All this different stuff becomes just unreal. and That's why CSS in a way needs to say, like hey, I'm going to take what you want me to do.
00:37:15
Speaker
And I'm going to, and I'm going to think real hard about it and I'll try to respect you. But if it doesn't work out due to these factors, uh, or like we're going to, we're going to do something a little wonky. go do something I just know, no, if you'll like, right. yeah Right. And then sometimes they're good scenarios. Like the whole, like CSS is awesome thing. Like the reason why it's jet now is because you asked for like a, you know, you asked for 200 by 200 pixels, but that text needs to flow 275 pixels. So what does it do? Does it go behind the box or do we, do we still want to keep the text legible?
00:37:45
Speaker
And so that's that's to me, ah I think that's why people don't like it is because you you basically have to say, it's like being on an airplane. You're like, I wish I was driving ah because I'm out of control. like you know like I think people just don't like letting go of the control ah that they get with imperative languages.
00:38:03
Speaker
Yeah, I like what Lane was saying too. It made me think that, um you know, the side effects of writing a line of code, um there they can be much more wild in CSS. um You know, you can write something that just seems so, I mean, padding is a good example or margin. Like, I'll just add some margin to this item. And then, oh, I guess that does, that pushes all the other boxes around it. Oh yeah, okay, now I need to go.
00:38:26
Speaker
uh tap those boxes and then you tap those boxes and they tap another box and all of a sudden you're in that one of those scenarios where like you can't fix all the leaks and so uh you're you just got a finger and a toe and a nose and all these different holes trying to hold it down um and yeah so when lane and i ah talked on his show he was like where's the tooling at And I think that's a really good point here is that the the tooling could really help articulate side effects. like A really good example is like DevTools now will tell you, you're like it let's say you set top 20 pixels on something, and it'll be like, this is not applying because your position is not relative or whatever. And you're like, oh, yeah. so that but the But when you're authoring that, you don't get any of that feedback. Same thing with type information. I can pass a color red to the um the font size.
00:39:13
Speaker
And it just lets me do that and it doesn't tell me anywhere in the editor that that's just wrong. And so yeah, when we're working these other languages, we a we get a lot more feedback immediately about the single line that we wrote and about its impact and its viability and its possibility. And secondly, CSS, since everything lives in this big space and there's all these different screens and all these different contexts, one little line of code can cost so many side effects that you can't predict.
00:39:36
Speaker
Um, it gets really frustrating. So yeah, it's, it's nice to know, um, that the command you're giving it has a simplicity to it and that there's like an elegance to the least amount of side effects that will come from doing this thing. Um, and CSS doesn't offer that. Yeah. Difficulty. So I think it's really important to talk about like what.
00:39:56
Speaker
what we mean when we say difficult, but also like how we would like it to be interpreted. So I remember when I was first learning to code, there was, and maybe this was like unique to my cohort of CS students, but there was like some almost like gatekeeping or, um, like you're better than another developer. If you can work with the hard shit, like the difficult, hard to learn stuff.
00:40:21
Speaker
That's what real developers use. That's cool. That's the good stuff. I dug a hole with a spoon bro. No way yeah go on Yeah, exactly. And then like later in my career, it's been a lot of more of the opposite, where it's been like, wow, I hate Java because it's effing difficult to work with. like I have to wrangle with this VM thing. i Again, I hate like the abstract classes. fact I want simple. I want simple. I want some easy to work with. That's what's good for me. um And so like when I say things like you know CSS is, is um you know I think it's, for example, easier to learn.
00:40:58
Speaker
how margin works than

Debugging and Performance in CSS

00:41:00
Speaker
how concurrency works. I think that's true. um But that's not to gatekeep and say, if you're going to be really good at CSS,
00:41:09
Speaker
um you like that doesn't take you know that takes less skill or you shouldn't be paid as well as someone that's that's good at concurrency. That's like a whole different Discussion because again, like I've seen lots of talented back-end engineers be like front ends. Fuck it easy Look at this red button. So yeah, it's the ugliest button I've ever seen in my life Nobody's gonna convert on the landing page. We're not gonna sell shit. We can't pay your salary anymore So it's like CSS is really Like, especially when you start mixing the idea of design in CSS, they get really hard, even though the building blocks can be simple, and I would agree if this was the point you were making, David, like, in a lot of cases, declarative is better than imperative. If the abstraction makes sense, I would much rather write declarative code than imperative code. it's It's doing a lot of work for me under the hood.
00:41:56
Speaker
That can be packed with lots of safeguards, like CSS is guarding people from doing things wrong so well because you can declaratively ask for it and the browser can know internally if it even has time to run that animation. It'll drop a frame if it needs to, but pick it back up when it can. Yeah, it's really jam-packed with sort of handling the details of that request for you. It's nice.
00:42:16
Speaker
I used to work on the ah Firebase console for Firestore, so like the data viewer editor and everything. And so I'd work with a lot of the Firestore database engineers. And I was talking to this this, actually this engineer, this guy came up to me one time and was like, hey, I'm building this little thing for like a demo. And he's like, and I'm umm having a hard time. And like most of these guys are like PhDs and like they are like very like they, they speak to you a lot of words that you're like, I'm going to jot that one down to look up later. So again, I don't feel so stupid. Uh, and so it's like lots of stuff like that. And, uh, but he walks up to me and he's like, I'm having a hard time here. Okay. He's like, I used to do front end development a long time ago, like back in like 2004, 2005, and this is like 2017. And I'm like, Oh, okay. So it's been a hot minute. And And he's like, I'm just, I'm, I'm just trying to get some JavaScript on the page. And it seems like you can't, you can't do that anymore. And he was like, you can't, you need, you need, um, you need other tools to put the JavaScript on the page now. And I was like, Oh, you mean like a bundler? And he's like, yes. He's like, and he was like, and I can't just like, he's like, I need like a, I need to use node to even if, but I'm not writing node. And node was for backend development. Why do I need to write, it run its right react? Yeah. And then.
00:43:37
Speaker
I'm talking to him and he's like so confused. And then as I'm getting him set up with like Webpack and everything back then, he is basically like, he's like, you know, ah back on my, my first project I did here at Google, he's like, I built this whole front end. It was great. I was like, Oh, would you build? He's like, I built iGoogle. And I don't know if it was like long time ago, iGoogle was like this custom Google dashboard that was so ahead of its time. And then, and he was like, yeah. And he explained to me how they made it. And it was like in this super, like,
00:44:03
Speaker
write Java like and it transforms things. It was like before GWT though. and I remember him just telling me about this and I was like, wow, like here's this person who's so smart, but yet the tooling, all this stuff, all the hurdles can be like exactly like to your point. is It's not a skill set thing. It's not who deserves to pay more. It just shows that like when you're out of your element or like when things change so much so often, it can kind of just put you in a state where you use hands up and you're like, like I can't do this. Lane, have you seen the movie Office Space?
00:44:32
Speaker
i Yes, I saw it for the first time just like a couple years ago. I can't wait so long to see it. Yes, seriously Okay. So you remember

Critique of CSS Float and Design Issues

00:44:40
Speaker
the scene where there's the fax machine, right? And it's like, they keep smacking it, they get upset with it, but later they turn into gangsters, right? And they take it out in the back, they grab bats and they just brawl out on it. Right. Okay. So yeah I want you to grab a few CSS properties and brawl out on them right now. I want you just to just be like, you know, uh, I don't know, whatever position, whatever thing that you're just like, I hate this feature. it's Just never just pound it. You know, let's hear it.
00:45:09
Speaker
Okay. give Give me a second to gather my thoughts. I'm going to have to think. Okay. Um, probably float. Um, yeah I used float all the time when I first started doing CSS. And then I, I mean, to be fair, there weren't as many APIs back then, like flex and grid, but float is mostly a disaster. I feel like every time I use it now, um, and flex and grid, I feel like have mostly replace the use cases for float. That's probably the worst one. I'm scrolling through on MDN to see what other ones I have a particular taste for. I too am bad at float also. I just remember I was like, oh, hold on, hold on, I'll float left and then I'll clear right. Oh, crap, that didn't do shit. Okay, I'll clear left. Oh, that's not doing shit. Oh, here we go, clear both. It's still in the same spot. What's going on? Oh, jeez, I was just so much guessing check with float. I just had no idea what was going on.
00:46:09
Speaker
Okay. I've got, I've maybe got one more, except it's not specifically a property. It's more like a thing I'm dealing with at the moment. but Love it. Yes. Like I said, boot dev is very, has a very unique look to it. ah A lot of people arrive on the landing page and like, what the hell is this? Am I starting a D and D campaign?
00:46:29
Speaker
Yeah, very weird. You can kind of tell the back-end developers built it. There's, you know, maybe some design decisions that aren't up to snuff. But anyways, we're in the process of getting the site redesigned now, working with a front-end engineer who has like really good design chops.
00:46:46
Speaker
and We've had this thing plaguing us for a while. We do like ah a glass morph um animation on like our modals that pop up. so They've got that kind of like fuzzy blur through look. and We've realized that on maybe 1% or 2% of our users' machines, again, coming back to how you can't know what everyone's viewing your thing on, for some reason, I think their machines are not using like graphics cards. to right They're getting a fan to spin up, huh?
00:47:16
Speaker
Oh yeah, not just a fan to spin up, but like it gets choppy and laggy. They can't scroll very well. Again, like we can't even reproduce this on like, some of us have like some older PCs we've tried to reproduce on. We just can't. So in

Conclusion: CSS Challenges and Boot Dev Promotion

00:47:28
Speaker
the redesign, we're like, we need to probably just stop doing this because it's been such a pain in our ass. So there's something about like, I guess the complaint boils down to like, you're allowed to do a lot of stuff in CSS.
00:47:40
Speaker
but But debugging performance on across all the machines can be tricky. And like just to give another analogy, I know we're kind of going over on time, is Firebase. One interesting thing about Firebase, even though I don't really love it as a product, for other reasons. ah One cool thing it does.
00:48:01
Speaker
but is it forces you to have fast queries. like You have to have your indexes in the right ah set up in the right ways such that when it's time to read them, they'll be fast, which is nice. Whereas, apparently, I don't even know this, in CSS, you can write some hairy shit that's going to run real slow on some machines and you know you don't really get feedback on that. Yes. I just went through this, dude. On my site, I had a dialogue.
00:48:29
Speaker
And it was using view transitions. You click an image, and it like zooms up into full screen, and I had a blurred background. ah And it it was chunky, terrible, nasty ugliness. And I got rid of it, and it smoothed it way out. I had another performance issue on my page. I was having two second recalc styles on my work machine. It's like a 2017 machine, ah which was causing all sorts of things to lag. um And it turned out the solution was to remove some has selectors that I wasn't even using.
00:48:59
Speaker
They were in the page as like a ad supports backup thing. I can't remember exactly what I was doing, but dude, that just some has queries caused. So when the page got reflowed and it had to recalculate all the styles, that particular set of selectors was dragging down the page. And when I got rid of them at all, I got seven millisecond recalc styles. I went from two second recalc styles to seven milliseconds.
00:49:24
Speaker
and i i looked at the engineers because i was working with chrome engineers to debug my site i was like guys my site is slow it's not cool i need to fix it like i'm supposed to i should have i should have a fast site and we're looking at it and um once we found it uh which literally was by commenting things out we were commenting chunks of code out trying to figure it out because all we knew was the report that it was a long recalc style and not even them could go tell me what it was And so later we ran the selector stats feature, which is so new in Chrome DevTools, if you open up and do a performance review, you can hit the settings and say selector stat performance. I urge everyone to run this and it will surface to the top your most expensive selectors. And look there, if there's like a couple that are just nasty gnarly up there, check them out, see if you can make them faster and you might see just better paint times for every time your site has to get reflowed, just boom, increases in performance. Yeah, it's not fair. What, how, how is a normal person supposed to do this? They don't have access to the team there. I literally, I've been, since this happened, I'm like asking around, I'm like, this can't do this. So the answer to this question cannot be meet with engineers that know how to do this or comment and comment out code until you find them. Like that's not good enough.
00:50:35
Speaker
tooling needs to surface this crap to people and be like, huge recalc detected you know like abnormal activity. I mean, you can see it in the performance chart. You get the flame graph that's just fat and long, right? You're just like, whoa, why did it take so long? um But yeah, CSS performance is definitely one of those things we're supposed to be able to trust it. I should be able to ask for a filter blur. I should be able to animate a glassy, glass morphism thing without pain or without knowing what the internals of the engine are doing. but Yeah, one of the one of the realities is you kind of do sometimes have to understand what is it doing so that you can work with it and use it in a way that it's happy about and sort of like pacify it. Which again is what we do in JavaScript. right You write the function first and it works fine, but then you later find out there's a way to do it faster. and so Then you make it faster and then you realize users are interacting with your function and they're throwing random shit in your function. You're like, okay, so now I have to have all these edge cases. and That's why node is slower than bun.
00:51:30
Speaker
i mean this is
00:51:33
Speaker
that last one caught up to me as i started ah This is an important point to note. like Fundamentally, this is about abstraction. right The performance has been abstracted away from you, which makes it really hard to debug when it matters. and I just want to point this out. that Declarative is good, but it is by definition an abstraction because the world is not declarative. The world is imperative. The way computers work is imperative. so um I'm a big fan of declarative code, um but it is important to understand that like it's this the same goes for SQL on the backend side. like SQL is very declarative. You write this query and how fast is it going to run?
00:52:11
Speaker
I don't know, like depends where it's running, how it's running the dataset. Um, and so you need like really incredible tooling to kind of make up for that. Yeah. I took a class in college where we would have to, uh, calculate the length of a query depending on, uh, like certain factors, like an award problem, it'd be like,
00:52:29
Speaker
Bob has this much data in his data set. He's going to write a story that like does this, like how long is this going to take? And it was very difficult. So like you'd get this, you know, like, I think throughout the whole semester, pretty much like 80% of our grade came down to probably like 40 of those questions. And so yeah, everyone, you were like,
00:52:50
Speaker
Oh, I don't know. Hey, how come imperative databases aren't cool? Why isn't there a database that everybody loves where you do all the work? You stick it in, you get it out yourself, you stop using the query language. Why not?
00:53:03
Speaker
I think because that almost like the thing that follows from that is writing your own database. The whole point of a database is to give you an abstract abstracted query layer. Uh, I don't even know what it like, I think that thing exists. It's called like writing to files on disc and then reading them. It's like PHP flat files. Yeah. Yeah. It's like IO dot read IO dot write. There's your, there's your imperative database. That's actually what I was thinking as soon as Adam said that I was like, I don't.
00:53:34
Speaker
I think that's just doing it yourself, which, you know, eventually at some point in your life, and even whether you know it or not, there's multiple things that you make yourself. CMS is databases. There's, you know, there's, you, everyone does it at some point, uh, JavaScript frameworks, apparently, uh, it will be one as well. Uh, you, you must make that if, at least accidentally, I'm writing a Markdown formatter right now, because I'm very frustrated with the same Markdown format. So we'll see how it goes. You know what? Uh, report back to me on that. Um,
00:54:03
Speaker
Awesome. Well, Lane, that was a very enlightening. It's always amazing to get someone from you know sort of the other side of the aisle like to come over and and give you insights into your world. Very appreciative for your time and everything today. and You can catch Lane over on his podcast as well with Boot Dev. like just boot dev into YouTube or boot dev into, you know, whatever your preferred search engine is. And it will, uh, you know, just show you all the amazing things. If you especially want to learn, if you do want to learn Python, then, you know, give boot dev a try. So, uh, thank you for joining us and we will see you all in the next, uh, bad at CS episode.
00:54:42
Speaker
and its csu possible