Ein Software-Architektur im Stream Podcast

2: The Power of Modern CSS

In this episode of maschinenraum.fm, host Lucas Dohmen sits down with web development veteran Dylan Beattie to explore the surprising power of modern CSS. At least that was the plan. But then they take a tour through web development from the olden days to today.

Note that at ~38:00, Dylan talks about WebKit (the rendering engine powering Safari), but actually meant Blink (the rendering engine powering Chrome and a lot of other browsers).

Transkript

Lucas Dohmen: Welcome to the Engine Room, also known as maschinenraum.fm, a podcast about web development, operations, and design. My name is Lucas, and today we will talk about the power of modern CSS. We will do it again in collaboration with Software Architect im Stream, so if you are listening there, then welcome from the other side. To talk about that, I invited Dylan Beattie. We're both at the Software Architecture Gathering from November 16th to 19th, so if you want to meet us in person feel free to to find us there we're happy to chat so now welcome to the show Dylan.

Dylan Beattie: Thank you very much. It's lovely to be here.

Lucas Dohmen: So can you introduce yourself to the listeners who have not heard your name yet?

Dylan Beattie: Yeah, so I'm Dylan Beattie, and I do a whole bunch of stuff. I've spent most of my life as a developer, one form or another. Started working, so I started programming on an Amstrad 6128, which I think in Germany it was the Schneider 128. It was the same machine under a different name. So that was like I was eight years old, that got me hooked. And then, you know, through Windows 3 and PCs and the 386 and then the early incarnations of the web, I started writing. I wrote my first HTML in 1992. It was just like a fun thing to play around with. I had no idea that the web was going to be as big as it turned out to be. And, yeah, I spent most of my career, first of all, building websites and then, working for a long time on one specific work company. Basically hired me and said, come and work for us full time. And uh that kind of grew from being webmaster there into running a team into being a systems architect and distributed systems and microservices uh but also along the way i started first i started going along to meetups just because i wanted to see how other people were solving these problems, and then i started doing lightning talks at meetups and then i started doing long talks at meetups and then people started saying can you come do that at our conference and then i discovered that sometimes a conference will will they'll pay your plane fare and they'll put you up in a hotel So you get to travel for free, which is awesome because I love to travel. And yeah, that's kind of where I ended up. So now I have this weird, I've been independent, you know, self-employed consultant since 2020. And I have an interesting mix. I do a lot of hands-on coding. I still run actual production websites for a couple of clients. I do consultancy. I do teaching. I do presentations. I do keynotes. I do a comedy rock and roll band who writes songs about software architecture and play them in bars. Uh. Yeah. And so when you go on a website and they're like, you know, job description, job title, one line, I'm like, I don't know.

Lucas Dohmen: Yeah, very nice. Like, I also recommend checking out your awesome music videos on YouTube. They are really cool. So before we get into the actual topic, like, talking to someone hands-on always means talking to someone who has broken stuff. So my question is, when was the last time you made a change to your CSS for one page and broke a completely different one? When was the last time you did that?

Dylan Beattie: Tuesday. It wasn't it wasn't css specifically but the last time uh I made a front end i've got a site i'm working on at the moment uh which is pulling in uh it's conference website that pulls in speaker biographies from two different backend systems and one of them gives you HTML and the other one doesn't and i accidentally double escaped some HTML and ended up with the little the p tags coming out as as angle bracket p slash angle bracket on the on the live site for a couple of minutes, so yesterday I was like no we can't do that again and so I'm wiring in some visual regression testing so it actually visually compares the before and after which was kind of fun, but you know CSS is... One of the challenges of working with it is that it is, it doesn't have any error messages and it doesn't have any output. There's no CSS equivalent of console.log, if something doesn't work it just doesn't work. You know, very, very seldom will CSS actually give you an error message that you can catch and you can log and that kind of thing. But also, you know, as you sort of point out in the question, the understanding the scope of changes can be very, very difficult when you're working, particularly on a complex website that... One of the big challenges with CSS is a lot of people have written a lot of CSS over a long time. And really, the only way to keep it manageable is to be disciplined about it. And once that's gone, you know, like any project, when it's Greenfield, you're like, right, everything. We got 100% test coverage. We enforce our coding standards. We've got a linter. And you keep all those things. And you keep all those things. And then there's the week where you need to get something out by Friday because there's a trade show. There's a deadline. And that's the first week that you're like you know what we'll do the tests next week and that that's it now you're screwed because you're not going to do the tests next week and then you're like well... test coverage was 100 and now it's 95 and then it's 90 and then it's 80 and then you start switching the test the you know, the natural tendency of software systems is the same as the natural tendency of any other evolving system it's towards entropy it's towards chaos yeah And the only way to mitigate that is to have very, very disciplined people working very hard with very capable tools, to try to keep things, you know, when you see where something is getting chaotic. And software takes a lot of cues from, you know, engineering and mechanical, civil, structural..., these kinds of things. We don't learn nearly enough from landscape gardening. A lot of the time, if you've got external contributors, you've got, you know, customers putting their own data into your system. It's more like, you know, going out to look at a garden after you've been away for a week and being like, oh, oh, well, that's not supposed to be there. And that's grown and that's died. And that's, and you know, this sort of relationship with an evolving system, which has its own ideas about where it wants to go and what it wants to look like. But yeah, but no, in CSS, yes, it is very, very easy to make what looks like a significant change. And then a couple of, I'm trying to think what the actual last one is, probably putting an overflow rule on elements to make sure that if you have a narrow layout on a mobile phone, then something wide like an embedded video or a table it doesn't throw the whole layout at, just that one element can scroll sideways. And then somebody pointed out that now on Safari, on desktop, on the previous version of macOS, you were getting scroll bars where there shouldn't be scroll bars. And it's like, that's an absolute classic. The only way to get it right is to check every page on every device in every version. And then you're like, well, we have all these fantastic, you know, one of the interesting things about CSS right back to the beginning, is how much the user is empowered to dictate the nature of their own browsing experience versus how much the website maintainers can inflict, you know, their own designs and everything. And I use the word inflict intentionally there because a lot of times the way I want to read a website is not the way the company wants me to read the website.

Lucas Dohmen: Yes.

Dylan Beattie: Adblockers is a classic. They want you to see the adverts. We don't want to see the adverts. There is an entire industry based on, you know, remove the adverts and there are plugins. And, but also, you know, there are some fairly fundamental things that, you know, if you're sensitive to, you know, a lot of rapid motion on screen, you can set a preference, turn that off.

Lucas Dohmen: Yeah.

Dylan Beattie: I don't want to see rapid motion. And then you go on some websites and you're like, oh, well. There are some websites that just ignore the rule, and you go on, and there are jumping animated menus, and there's flickering video. And there's some that do it really well, and you just get this nice, kind of very calm experience. And then there are the ones that are like, oh, well, don't show the animation if they've set the preferred reduced motion preference. But no one's actually realized that that means the menus don't work, because the animation is what makes it.

Lucas Dohmen: They don't test it.

Dylan Beattie: Yes. Yeah, they haven't tested it. And, uh, so, uh, yeah, it's a very, very interesting technology to me. It's, it's one that I, I enjoy working with it because I enjoy, uh, the immediacy it's, you know, I've done a whole bunch of presentations all over the world, different events, different technology, and you can, you know, try really hard to take a story about, you know, doing distributed transactions in a backend message broker, and you can try to turn it into a great story. But at the end of the day, all you can show people is a log file.

Lucas Dohmen: Yeah.

Dylan Beattie: Whereas with css you can be like look it moves it jumps it bounces it's a rainbow it's it's visual and it's very immediate and you know you can build stuff in CSS that would make a three-year-old kid who can't read yet go oh pretty i like it and.

Lucas Dohmen: Yes exactly.

Dylan Beattie: I think on some level we never grow out of that. There's always a a bit of everyone that enjoys like bright colors and pleasing movement and picture books and those kinds of things.

Lucas Dohmen: Yeah for me it's the the best and worst thing at the same time, right? For a while i taught children computer stuff like in a CoderDojo and we always like offered kids to build their first website and it's so amazing to see them like seeing oh you can actually change this like this is your choice you can make it pink you can make it green whatever you like like it's your your thing, right? And it was always such a, pleasure to see like how much creativity they put into the site but it's on the other side it's also the the worst thing because everyone has an opinion on what you're doing, right? Like you cannot just like do something and then like oh but the button it should have a different border radius it should have this and and so on right like everyone has an opinion which is different for like classic back-end work where like the other developers have an opinion the product owner doesn't have an opinion. The business owner doesn't have an opinion, right? Like that's how it usually goes.

Dylan Beattie: I think the absolute peak of productivity when it comes to user interface design was probably Windows 2000. Because, you know, Windows 2000 was, it was gray. The buttons were rectangles. They worked. You know, it was a solid operating system. And it meant that when you were building desktop applications, you spent all your time thinking about layout and, you know, user experience. And none of your time thinking about theming and colors. And then, you know, Windows XP came along, which had a much more kind of colorful set of user interface conventions, but it hadn't been applied consistently. And so you'd find if you went into the toolboxes in Visual Studio, some of them would be like the up-level controls and some of them would be the old versions. And then, you know, when we got high DPI, like, you know, pixel scaling on displays. At that point just there's now like i think in modern windows there's about 25 different ways to draw a button and I remember when there was one and it was just "button" and that that was all it was and nobody ever had an argument about what the button was going to look like unless you were working in game development or web development, um and it actually gets us onto an interesting uh. Kind of a topic that we we touched on a little bit which is is software a tool or is software like a media experience or a software marketing channel. And, you know, there's obviously... Because I get advertisements in my operating system now, which I always think is, I'm pretty sure. But then I remember when operating systems were really expensive. And I'm like, would you rather have Windows for free, but it shows you adverts? Or would you rather have Windows for $300, but it doesn't show you adverts? And obviously what we'd like is Windows for free with no adverts. And everyone says, well, you should just use Linux. and it's like well i do use Linux on all of my web servers and on all of my RaspberryPis on all of my embedded devices but i also you know i have videos to edit I got Premiere i've got AfterEffects i've got music composition and uh, yeah tool the right tool for the right job but, there are increasingly many you know websites and mobile phone apps and stuff now um where the company behind it are like oh well they've got to log into our app because they've got to pay their electric bill: Show them an advertisement and i'm like i don't want to know i just i need to pay the bill you know it's like i got things to do yeah. And uh and then the really frustrating one is when you have an app that, uh could work offline uh because i live in London. The underground uh, rail system here the London underground a lot of it still has no uh mobile reception when you're in the deep lines in the deep tunnels and so i have these games that you play and it's like i have a couple of versions like Scrabble and puzzle games and things. And the game works offline but it won't load because it can't load the advertisements. And you're like I see a solution to this problem here. And that's always frustrating. And the fact that advertising is the only way we really came up with to fund the web, I think it's such a... It's led to some really horrible outcomes. And I still wonder whether there is any way to roll out an improved model. Because Cloudflare, earlier this year, they announced a system which is designed that if bots, you know, AI crawlers and AI training bots want to access the content on your website, they have to pay for it. And I think the idea there... the thing which made this quite compelling to me, and I haven't really kept up with that, I don't know what's happened in the last month or two. But, you know, Cloudflare is a massive international company. They have payment systems. They are established as a corporate entity in all the territories where they do business. And you've got somebody like OpenAI or Anthropic. And so you're running a Claude bot, and Claude wants to go and crawl a website, which is hosted behind Cloudflare. And the idea of setting up a transaction between Cloudflare and Anthropic seems a lot more feasible than Cloudflare and everybody on the planet. You know Anthropic already have our money because they're taking Claude subscriptions and cloudflow already have our content because everyone's got websites on them and so, you know that to me looked like quite an interesting idea and of course the next thing is well why does it need to be AI bots why can't we just you know if this could become sufficiently established as a standard, a protocol that actually works, um then you could be like well we're not AI bot we're a browser but we're a browser that's linked to a you know like a online bank or your Stripe account or Mastercard or whatever um and now you can you can click the things and you can pay money for websites and you know yeah no no adverts and yeah.

Lucas Dohmen: I understand that there could be something there, but it also would probably make it even more central, right? It would mean, if I want money from people that visit in my website, I need to go with Cloudflare, right? And I'm not sure if I'm comfortable with that. In the current project, we're trying to move away from Cloudflare because it is just too much of a central thing that we are not trying to support, right? Um but i think like the the whole business model of the web is a big question mark. Like it goes beyond just what we pay for visiting the web right like if you think about it like all the browsers are basically paid by ads right like because all of them in the end are paid by Google, right? Google pays Apple and Google pays Mozilla and Google pays their own Chrome team, right? And if they would stop paying like we had would have a frozen web basically, right? Nothing much would happen. And I think that goes way beyond just like the ads we see as a user. Like indirectly, they fund the browser that we use, even though the browser itself doesn't show any ads, right? But it might be a good reason why the browsers do not have an ad blocker built in, right? Because you won't bite the hand that feeds you, right?

Dylan Beattie: So yeah, there's... Have you ever paid money for a web browser?

Lucas Dohmen: No..., Oh I have. Once, yes. Back in the day, I paid for iCab, that was a browser for the Mac, and there I paid for it once.

Dylan Beattie: So I had Netscape Navigator when Netscape Navigator cost $40. And I also used Opera a lot in the early 2000s when Opera was paid software. And it's like, well, I know where the browser's coming from. People buy it for money. And it had a lot of very innovative features. It was the first browser to have tab browsing. It had like a speed dial dashboard. So when you open it and all these features, you know, everything has tab browsing now and everything has like a start page with, with top links to your, your frequent websites. And yeah, Opera, Opera built that and Opera got spun out of a, um, it was the Telenor, the Norwegian telephone company, which had built a web browser and they did. And like, imagine that happening now.

Lucas Dohmen: Yeah.

Dylan Beattie: But, uh, actually that, that's another interesting thing that, that I wanted to talk about today. So obviously the topic of the show today is about CSS, but actually I'm as much interested in, the role that CSS plays in the whole broader sphere of modern software development and software delivery. And, you know, it's one of the things I really enjoy about the CSS community is how transparent everything is and everything's driven by open standards. And having worked on the web in the days when Microsoft would say, ta-da, here's a new version of Internet Explorer. And everyone would be like, oh, it does this thing. And Netscape and Opera would be like, oh, it does that thing. And I remember when Google brought out the first version of autocomplete. Because this was really early. This was back when every website in the world, if you wanted to get new content, you had to submit the page, submit the form or click the link and you'd get a whole fresh page. And that was it. That was how the web worked. And I remember because that week we told a client that we couldn't give them what they wanted. And then on Friday, Google launched the first version of Google Search with like IntelliSense, like autocomplete. And you'd start typing "how to", and it would give you "how to convert to", and you'd be like hu. And the same client is like you told us this was impossible and we're like it was impossible on tuesday, but Opera shipped support for that feature within 48 hours so by monday morning Opera had figured out how they did it and made it so that the same JavaScript would run and they did it by, uh so there's an interesting story the reason why that feature so this is what became Ajax - Asynchronous JavaScript and XML. And then Ajax was the precursor to the modern fetch API and to single page applications and the whole, you know, Angular, React components that fetch their own data from backend APIs. All of that came on the back of this, this innovation. And, uh, it came from Outlook web access. Because you know Microsoft they had a team doing Internet Explorer and they had a team doing Outlook and Outlook... they wanted Outlook on the web and uh basically they went to the Internet Explorer people and said can we like can we refresh someone's inbox without having to reload the whole page, and they're like well there's this com object there's the XML HTTP object, and you we could make it so that you can use JavaScript to instantiate a com object and then use that to do stuff in the background, which is why we got this weird syntax. And that's where that came from. And then Google figured out they could use that for autocomplete. And then, of course, the one that really blew everything wide open is Google Maps, where you just scroll, and you scroll, and you scroll. And it loads the entire planet one tile at a time as you're scrolling. And if any of the folks watching or listening remembers what things like Street Map were like before that. You'd get a page of maps so you'd be like I need to go west and you'd click west and it would wait a couple of seconds and then it would load again and now you're one square to the west yeah.

Lucas Dohmen: Like one of those old school text adventures like do you want to go east or west.

Dylan Beattie: Yeah. Go north. Turn west. Look at sign.

Lucas Dohmen: Very nice so we had two comments here from people watching live so uh Coder By heart, wants to hear our ideas out how to get out of the CSS-in-JS mess i would put that a bit back, because i think we yeah

Dylan Beattie: We'll come back to that one

Lucas Dohmen: Definitely and Eli Miriam also sees like the problem of the advertisers becoming basically content moderators and i think that's very visible on the Meta platforms, right? But also visible on other platforms as well...

Dylan Beattie: we talked a little bit about about centralization and one of the big challenges for certain kinds of online content is, activist groups will petition Visa and MasterCard and say, don't offer payment services to these platforms. And that's it. If Visa and MasterCard say no, now there's basically no money. Because at that point, anybody who's like, well, you know what? You can put payments through us and then we'll send them to Visa. And then Visa's like, well, no, if you do that, we're not going to support you either. And, you know, this is the extent to which a handful of massive players has consolidated the clearing and, you know, payment systems that the web runs on gives them a, huge amount of power, which they have not been elected to. They have not earned. And, you know, most of the time, most of us just ignore it because it does most of what we need.

Lucas Dohmen: Yeah. But it's also like interesting from like a European perspective, right? Like, if I go to a German online shop, right, and I want to pay, there are basically three options. Either I go with PayPal, or I go with Visa, or I go with MasterCard, right? Like, those are the three options. They are all US American companies. And I don't have a choice, even though, like, I'm shopping at a German store as a German from Germany. Like, there's no way for me to just pay it, like, without going to the US first, right? Like, even if they are not hosted in the US and so on, right? Like, but the payment will go through them. There's basically no way around it. There are some initiatives about it, but they are very early stage, but I think it's still a problem.

Dylan Beattie: A whole growing topic of... people are starting to use this phrase digital sovereignty, about the data and the systems that handle web hosting. Because at the moment, if you want to put a website in the cloud, you've got a choice of Google or Amazon or Microsoft or others. You know, there's Alibaba Cloud. I don't know anyone who hosts an Alibaba Cloud on production. But have you heard of STACKIT?

Lucas Dohmen: Yes.

Dylan Beattie: Yeah. So STACKIT is Lidl. It's the German supermarket chain who decided that they didn't want to host all of their online e-commerce with an American multinational. So they built their own data centers in Europe, in Germany, and put all their own stuff on it. And then went, hey, does anyone else want this? And I actually, I went to look at it the other day. I needed a cloud VM. I was like, I'll give STACKIT a go. And unfortunately, Brexit benefits, I'm not allowed to sign up to STACKIT because it would make it too complicated but if i was in Germany or the Netherlands or Austria it would be fine yeah, and i could i could get a private server on a you know European owned company uh still probably running American branded hardware manufactured in Taiwan under a license agreement from um, but the chip design is probably British because ARM Holdings is based in Cambridge. So we still got that going for us, which is nice.

Lucas Dohmen: I told the story about going from AWS to a German Hoster in the last episode. So if people are interested, check out the first episode. I think it is more possible now than it was a while ago, but it's definitely a different style. You need to accept that you do not get 200 services like you get in AWS, right? But it's definitely something that is possible now, but yeah i think it's still like the gold standard i i saw some statistics like it's overbearingly like those three platforms and even between the three like AWS is so much bigger than the other two right like, the the Googles and Microsofts are basically small compared to to AWS and everyone outside of that is just a dwarf, basically.

Dylan Beattie: It is always fascinating to me how many websites and applications are over-engineered, you know we're kind of at a point now where if you if you're going to make a new website whether you're doing it by hand with a template or you're using like npm templates packages or you've got AI to do it for you, it's probably going to assume you want React and so you're going to have React before you've even written a line of content um and a lot of websites are like you don't need react you don't need anything you know yeah uh, there's an interesting thing that i've noticed happening around the area of london where i live which is that local restaurants are going back to running their own website so they got their own website their own menu their own delivery their own drivers, and 20 you know 25 years ago you couldn't order food online because it just wasn't really a thing that happened. Maybe 30 years ago so and then you know the big players like you know Just Eat and Deliveroo and Hungryhouse they kind of came in and websites are like, oh, this is great. And of course, you know, it's the classic, it's Cory Doctorow's enshittification model where, you know, first of all, you get the critical mass of end users, which is us, the hungry people. And then once they're locked in, then you can start treating them like crap to make it better for the customer, the companies. And then once the companies are locked in, you can start treating them like crap to make it better for the shareholders. And then everyone's miserable, nothing works, and the shareholders are rich.

Lucas Dohmen: Yeah.

Dylan Beattie: And what I've noticed happening is a lot of local restaurants like actually, you know, for what we are paying across all of these different platforms, we can run our own system now. Cause you know, AI has made building these kinds of systems a lot cheaper, more cost-effective. Hosting is easy because cloud is ubiquitous. And, uh, apparently I'm, I'm spoiling Eli's talk for NDC London. So, uh, yeah, you want to roll the rest of the story? You're going to have to come to NDC London. But no, it's nice to see, and you know, to me, food delivery is a classic: You're delivering pizza on a motorbike. You don't need a multinational company because you can't really go any further than about three or four miles, like, you know, five, six kilometers. And so there's a very definite, this is the radius. It only works when the restaurant is open. So you literally, you can switch the website off at night because who's going to order pizza at 4am from a restaurant that isn't selling pizza at 4am. And, you know, I like seeing the kind of the green shoots of people moving away from massively consolidated cloud back towards: You know what, we can solve our own problem and we can own the tech and we can own the stack. But then a lot of places, if you don't have online ordering, your website doesn't need anything except pages. When are we open? What are today's specials? Where do you find us? That's it. And we don't need. to hear your family history and we don't need to hear about your grandmother's farm in Sicily. We want to know what's on the menu when are you open and how do I find you that's it and, you can do that with static HTML in a S3 bucket or in a Cloudflare Worker or on a Raspberry Pi or any number of systems, um yeah.

Lucas Dohmen: Yeah as someone who's quite critical of the whole LLM thing and not using it as at all. Like I see what you're saying right like but at the same time like people that do that using some bot of course are like getting into a different kind of dependency, right? Like now they are dependent on the system existing and I think for the other point I agree much more right like I think there is a lot that is much simpler than people think, right? Like, bringing up a website is so much easier like people got so used to just having their restaurant on only Facebook and Instagram that they are not even thinking about having a website.. But it was already possible with website builders and stuff like that to have a very simple website. Like you said, we are not asking for the most delightful website. We want the menu and we want the opening times. We want the phone number because that's also hard to find outside of those platforms. As someone who doesn't have an Instagram or Facebook account, sometimes I want to go to a restaurant and I don't find a telephone number. The only place I have a chance to find is Google Maps. So yeah, I think there is a lot of challenge. But Dylan, before we go into an, entirely different direction, let's talk a bit about CSS, because that's what's in the title and that's what some people tuned in for. In CSS, we came quite a long way. If we go back to the early days, some things that are now super easy in CSS were super hard to do. There were things that took weeks to build, and now it's just two lines of code. And you had one example that I really liked about the buttons, like rounded buttons. Tell us the story about the rounded buttons.

Dylan Beattie: So because I've been building websites a long, long time, this is going back to the late 1990s, and buttons were square or rectangular. Buttons all had sharp corners because that's what buttons looked like. Because on most platforms, the things like buttons and drop-down lists and radio buttons, the browser didn't render them. The operating system rendered them. And there was a fairly compelling argument that familiarity is a factor because a user comes to understand. It's what they call affordances. They see a gray box with a raised shadow effect on it. They're like, I can click this. I know what this is. And then when the web came along, as we mentioned, earlier we got this this interesting thing where on the one hand we have software engineers going it should look like an application. On the other hand we've got customers and particularly marketing departments going no it should look like a showroom. It should look like a brochure. It should look like our publicity material, and one of the earliest things on this was buttons that didn't look like buttons because you know Windows says buttons should be gray and the customer goes no the button should be uh you know it should be like purple and look like it's made out of jelly because that'd be fun because we're a company that makes gummy bears and candy and so we want candy buttons. And so we made buttons in Photoshop by hand. And every button would be a separate GIF with the text written on it in Photoshop and then exported separately. So we'd have folders full of buttons. And then we invented nine slice scaling. So every button was actually a tiny little table. And so you'd have nine slices around the outside, the top, the bottom, the left, the right, and the four corners. And in the middle, as long as the middle had like a consistent background, you could change the text on that, which means you could drive it from a back-end database or a content management system. And the company I worked for, we actually charged money for buttons. We charged, I think it was 15 pounds for every button on your website. So this was like free money, you know? Amazing. Like we just, we make a button and every time we do it, it's another 15 quid. And which sounds crazy now, but this was how nobody knew how to sell this. You know, you had people who were experienced business people from other areas where they're like, well, we need a, like a pricing structure, which reflects the materials and the effort. Time and materials. And materials was obviously, well, we don't know what a website's made of. They're not made out of timber. They're not made out of concrete. All right. So it's all on time and hosting and that kind of stuff. But then, of course, your rounded buttons. And when they first came out, it was eye-catching because you would look around the web and you'd be like, how did they do that? Like, that looks amazing. This was a state-of-the-art web design in about the year 2000. And then it became a standard. We had border radius got introduced. And for a long time, it worked everywhere except Internet Explorer, which was a headache because you still had to use nine slices if you wanted IE to work. Or you try to persuade the customer, look, this is going to look really good on Netscape and Safari, and it's not going to look good on Internet Explorer. And they said, well, how many of our users are on Internet Explorer? And you'd say, it's about 85%. And they'd be like, no. Um and of course you know that and this is this is what the web used to be like is there would be a feature that was cool because it was difficult, and you know this i think has always been a theme with uh because it has to do with fashion as well you know there are fashions in web design and at the moment i think that the the the trendy fashionable thing is liquid glass because Apple brought out this new UI paradigm in the latest version of iOS which is controls that look like they're made out of molten glass. And everyone's like, I want my website to do that, and we can't do it easily. And so there's a lot of people being like, well, if I put a CSS, I can have this highlight filter, and I can apply that to an alpha channel, and then I can do a composite, and then I can put stacked background layers on it, and I can get something... And I'm sure that, you know, in a couple of years, there will be like a, you know, a CSS rule that says button, you know, filter, liquid glass, boom, one line. And then if you want it, you got it and it's free. And if you don't want it, you can do something else and we'll find something else to be interesting. But there are so many, you know, liquid glass is one. A couple of years ago, there was parallax scrolling. So like the background moves at a different speed to the foreground. So you get this impression of depth on the page. And masonry layouts is one. So was it Pinterest that kind of popularized this very particular layout which is very difficult to do but now that's coming in i think... is it called a masonry grid? There's something in this year like literally being added to CSS now, and you know to me it's interesting one because i enjoy watching the collaboration which results in these standards becoming established and then becoming supported. And it's not that many people, you know, you could take, I've, I've been to a couple of events this year and you look around the room and you're like, probably 90% of the people who make CSS happen are in this room right now. Um, and you're like, if this building burns down, we're going to have a big problem for the future of the web, you know?

Lucas Dohmen: Yeah.

Dylan Beattie: But it's kind of nice when you can go and have a beer afterwards and you're like, well, they work at Google and they work at Mozilla, they work at Apple, they work at Adobe, and they're sat around having a drink and talking about how to make CSS better. I like that.

Lucas Dohmen: Yeah. It was also an interesting thing with the masonry layout. They renamed it to grid lanes, I think.

Dylan Beattie: Grid lanes, that's what it's called. Yes.

Lucas Dohmen: And there was a competing proposal. It was really nice to see the whole interaction between the different parties. It wasn't clear which of the proposals would win. It was very open for quite some time. And now they landed on something. And I think seeing that quite openly, seeing that this is the one approach, this is the other, this has this advantage, this has this disadvantage. This is interesting stuff. This is what we want to see as people using the web. I think the strength of the web is when things actually happen in cooperation between those parties and we have a bit of an insight into what is happening. Because a lot of people are quite unhappy with things being voted for cross-browser compatibility, and the top-voted thing was not worked on. What happened in the background? And of course, this will always happen, right? Because there are things that, maybe one of the managers at Apple didn't like, so then it's not coming. I think it's not solvable perfectly, but I think we are at quite a healthy state where if you want to, you can actually follow discussions quite early on and even voice your concern. And I think a lot of people do not use their voice in that way. They could ask, what is the current status? What are you trying to solve? I think that would be a call to action for everyone. Get involved in things like that. They actually want to hear about you. And it's not like thousands of people working in the background. It's like a very small group of really active people. And then a lot of people that are around it and maybe chime in for one or two things.

Dylan Beattie: I think it's probably fewer than 20, which means that if you, have a very strong opinion about something that might be coming up and you can persuade 15 people that your approach is valid or that your idea has relevance um, it'll happen you know it's well it'll it'll happen most places and then a year later it'll happen in Safari yeah but i mean...

Lucas Dohmen: Uh there are some things where Safari has gotten up a bit in speed.

Dylan Beattie: Yes.

Lucas Dohmen: So i think we should be a bit more...

Dylan Beattie: It seems very much that the pattern because obviously the the challenge now is that webkit the browser engine is... We basically... it's like everything we've got Coke and Pepsi and you know Webkit is Coca Cola that's everywhere and pepsi is Gecko, Mozilla's rendering engine and so although everyone is collaborating on the standards there's then a prioritization process so once something is in is in Webkit it's relatively straightforward i think to get it into edge and chrome and you know Vivaldi and Arc and all the boutique browsers which are based on the WebKit engine because there's a relatively straightforward upgrade path for the rendering part of that. Safari takes a little longer because of the integrations with the features which are only available on the Apple platform. And on iOS, still, even if you're running Google Chrome on your iPhone, it's actually running Safari wrapped up in Google Chrome. So you've got your Chrome bookmarks and your Chrome account and your Google login. But the thing that renders the pages is still the Safari engine. Yeah. And then Mozilla, kind of, they're like, right, well, here's the standard. And it is often, you know, it's very rare to see Chrome not being first, because that one tends to have the most, I don't know what, aggressive, enthusiastic, just the upgrade cycle on Chrome is very, very rapid. But then often, you know, Safari or Firefox will be relatively close behind, and it's not that unusual for one of the others to lag by a few months in rolling out some of these features. But to me, the really positive thing is that when they do eventually ship support, it's a solid implementation of the standard. And so as web developers, and if you're designing or you're making decisions about how to provision your site, you can be like, well, we can use the new shiny thing now and accept that it won't work in Safari. But then at some point next year, it'll just magically start working and we don't need to deploy anything because the browser is going to meet us there. Or we can deploy it now and we can put in a polyfill, which will work with all the things, or we decide we're not going to roll this out. But certainly the days of having to write very complex, you know, bespoke client-side rendering to do things like animations, most of that now just don't do it. Just use what comes in the box. And uh that that kind of there's an interesting overlap there because a lot of people think that you know the CSS is a kind of front end and software architecture is back end and there's not a lot of overlap but one of the very I think underrepresented aspects of the discipline of software architecture, is deciding when you can deprecate things and when do you get rid of stuff you don't need anymore, and uh so jQuery is a great example here because it's still very very popular. Something like 80% of websites or web traffic or something still use jQuery. And when jQuery first came out, it was amazing because it gave you a consistent API across different browsers. And so a lot of people learned it because if you knew jQuery, you didn't need to learn Internet Explorer versus Chrome versus Edge versus Firefox versus, you know, whatever else. And we don't need that anymore because the API that the browser exposes in terms of, you know, CSS behaviors, JavaScript, you know, element query selector, all these kinds of things, that is very consistent now. But that means that it's now, you know, a lot of these websites should be saying, well, you know, can we remove jQuery now? Can we take it out? Can we replace it with native JavaScript and native CSS animation, which will, in a lot of cases, it'll improve performance? Because certainly running stuff in CSS, most of it now gets offloaded onto the GPU. So you're not blocking your main JavaScript thread for doing animation and interaction and those kinds of things. But you know it's it's relatively little discussion in architecture is about deleting things and deprecating things and switching things off and one of the best reasons to do that is look we built this thing and then an open standard came along that solves the same problem. I worked on a system 10, 15 years ago now where we needed to, put you know we had OAuth so we had OAuth 2 federated authentication so that we could build integrations with third-party systems without having to give them access to our main customer data stack. And we just needed a thing where you could say, right, I'm signed in. Now, who am I? Get me my name. Get me my email address. And nothing existed at the time to do that. And so we implemented our own system to do that. And about a month after we went live, the first version of OpenID Connect came out. And we had that moment of: Are we going to take the time to throw away the thing we just spent three months building and replace it with this open standard? Or do we accept that the system works, it is live, we've got other things to do? And there's no right answer. You cannot look into the future and see the cost of maintenance. Is it maybe a year from now we're going to be recruiting? And if we're on OpenID Connect, it's going to be much easier to find engineers who already understand the landscape. Yeah, definitely.

Lucas Dohmen: I mean, that's the case for both CSS and JavaScript. Like for me One of my favorite pieces there is the the Temporal API, right? Like for like ages Everyone had to include. Moment.js like basically it became a standard library for the web, right? Like everyone used it.

Dylan Beattie: I have a bug in it's it's not temporal, it's Intl, it's the internationalization stuff a bug yesterday that uh, whole bunch of scheduling stuff being moved over and turns out I had this weird bug because I got a visual regression stack now. So before you deploy stuff, you run a script and it says it takes like 200 screenshots of the live sites and 200 screenshots of local sites and does a pixel comparison so you can see what moved. Because as far as, you know, for CSS stuff, sometimes that is the closest thing you've got to a test suite is something that goes, hey, these two, something's different and you can look at it visually and say, oh yeah, that's fine. That's the feature we are deploying or no, that's broken. That's shifted, or that button's disappeared. And I'm sure that the next iteration will be some kind of automated reporting, probably using language models and things. And Eli says "you mentioned CSS being transparent, and I thought you were making a pun about this bug". No, it didn't even occur to me that could be a pun. And I had this thing where the site localhost didn't match live, But then when I ran localhost, it didn't match live and I'm like, what the... And so I go digging into it, and it turns out that the site is, when you build it, it's built using Bun, but when it runs the snapshots, it runs them in Node.js because Bun doesn't work with Playwright. And Node.js does not format dates the same way that Bun does because they disagree on how British-English date formatting works and whether there's a comma between the day and the month or not. And I'm like, really? Like, this is not a bug in the code. It's not a bug in the design, the layout, the CSS. It's that we've got these two runtimes, which theoretically have implemented the same standard. But one of them's gone, oh, yeah, British people use a comma. And the other one's been like, no, they don't. Or they didn't even think to ask the question. And yeah, that was literally like yesterday. That happened less than 24 hours ago. I was like, what the, where is this coming from? And you know uh i realized there is a diversity of opinion about language models but this is one of the ones where i said to Claude code what is going on and then i left it thinking about that and I went out to get a drink and i had like remote control on my phone and i got to the table with my beer and it pinged up and went yeah this is the problem and this is this and you want to fix it and i said "yes please", and it did and that that that is uh strange. You were talking about dependencies a moment ago. You're talking about the language models. And something I wanted to mention on that, to me, there are pipeline dependencies and there are production dependencies. And I think it's very, very, we're at a point in the evolution of software development where it's very important to understand, I think, the distinction between the two. Because to me, a production dependency is something that if it fails, the site goes down, or the app stops working, or you can't sell tickets, you can't take payments, you can't do any of that stuff. Whereas a pipeline dependency, if that goes down, it means we can't make updates, but the software still works. And at the moment, I'm very much at a point with a lot of my own projects where I will happily take a pipeline dependency on LLMs and stuff. Because at the end of the day, if I get up tomorrow and Claude is like, "you know what, we've run out of free money, it's going to be $10,000 a month for Claude now". I can be like, okay, well, I was using that, and it was useful, but I still own all of the code that was written, and I understand it because the vast majority of it, certainly everything that goes to production is stuff that I review every line and I verify it. And I have automation scripts for doing things like regression testing that were, you know, some of it's handwritten, some of it's Claude-written. I have the script. I don't necessarily have access to the tool that built the script, but the script is still there. And so using language models as part of how we build the software to me is a very different set of dependencies to actually, we are going to deploy Claude in production and we are going to use it to, I don't know, approve applications to buy insurance. We're going to put a language model on our platform that makes decisions about whether to pay a customer's insurance claim or those kinds of things. And to me, that's a very scary proposition.

Lucas Dohmen: Yeah, but that's only true if you're not outsourcing your knowledge and your skills to the LLM, right? Because then it becomes both, right? Because if you are no longer able to, touch the code without the tooling, then it is both, right? And I think that's something that a lot of people fall into, right? You see like big names talking about like, "I do not even look at the code anymore" stuff. And like I... reject the technology for other reasons, for a lot of reasons. But I see that even people that start very cautiously using technology like that, they become much more dependent step by step. And because as humans, we trust things that work 90% of the time, right? And then the other 10% of the time, we're like, oh, bad luck. And then over time, it's just like, okay, just do it, just do it, just do it. And then you are no longer able to do it [yourself]. And then you have those people that are like, oh, Claude is down, I cannot work today, right? And I think that's a problem.

Dylan Beattie: There is another interesting parallel, which actually this is what I'm going to be talking about in Berlin in a couple of weeks' time, is it's people saying, oh, you know, I don't even look at the code anymore. And that's a very provocative statement right now. But for 20 years, we have been shipping software based on packages that we installed, that we didn't look at. You know we couldn't if you do a you know "create react app" you get like hundreds of thousands of lines of code that you didn't write it's just there it's yours now you've got all the node packages and all these things installed and, we have always sort of worked on the assumption that the packages must be good because everybody else is using them, and therefore if there was a problem somebody would have found it. And certainly there's one of those, we know about the problems we found because we found them. We don't know how many problems we haven't found, but, um, you know, and there are supply chain attacks, uh, you know, NPM particularly, I think just because it has ended up being way more significant than I suspect anybody believed it was going to be. You know, the extent to which JavaScript has taken over the world when it comes to backend, front end, all kinds of deployment scenarios, I find that a little bit surprising maybe. But then we also, you know, last year we started seeing, and the thing I'm talking about in Berlin is about sustainable open source. And one of the things that's been happening is high profile projects changing their licensing and saying the next version of this, if you're a big company that makes a lot of money, it's not going to be free for you anymore. And this is also very provocative it's a lot of very angry conversation um. And that kind of gets to well: No, no look, the code you're running in production right now um, you can still use that code because the version that you took a dependency on was published under an MIT license um you're running version 7 you've just been told you don't get a free upgrade to version 8 but you still have all the code so in theory you can take the code you've already got you can download the source, roll that into your own build process. Now you own it, you control it, you don't have to give anyone any money. Problem is you don't understand it. And that means that if you do have to fix a vulnerability or deliver an enhancement, implement a new feature, you've got a choice of we can pay for version eight, or we can take the time to understand version seven and figure out how to implement this thing ourselves. And, you know, to me, there's a parallel there between code that came from somebody else's package and code that was generated by an LLM. As far as you can tell, it works. And that may be just that you click two buttons on a web page and went YOLO and deployed it. Or it may be that you actually did kind of like, you know, a rigorous analysis and you did a code review on it or, you know, built a test suite of integration tests around it. But the... I guess the kind of underlying point is that we should be prepared for the possibility that we are going to have to support the code in our application without any help, without any support. And that is what it comes down to. And actually, that's not a bad place to be. Because if you have dependencies on cloud services, those could get switched off. You know, if you have dependencies on, you know, closed binaries or something for which you don't have source code, they decide that that's not going to be free anymore. You kind of have to pay for it, or you've got a very expensive reverse engineering job ahead of you. But we do, you know, it's interesting the extent to which people are very comfortable taking a dependency on half a million lines of code they've never looked at because it came from a package manager. But the idea of depending on half a million lines of AI generated code is somehow completely different. And, you know, I appreciate the distinction because it's, you know, is it Linus's law "given enough eyeballs, all bugs are shallow". Or maybe Eric Raymond or somebody just, you know, code that gets used by a lot of people tends to be of higher quality because more people have had a chance to dig into it. And this is definitely, you know, I would prefer to see a world where we have a sustainable open source ecosystem. We are using standards like CSS as far as possible instead of reinventing the wheel because once something's built into a browser, it's not going away anytime soon. And so I think it's safe to take a dependency on that. So a comment from ultrakatel just popped up in the chat there: "It's regarding the comparison between AI and libraries. Isn't AI different because its output is not always predictable or reliable?" Yep, it's a fair observation. I tend to say once it's generated the code, the code isn't going to change. It's just if you ask it to generate the same code again, it won't. But if the code that has been generated solves the problem that you have, then you can either deploy it or you can put it to one side and you can cherry pick the good bits or you can read it and you can understand it and then you can go and write your own. And there's a lot of ways that these tools can make the craft of developing software different. It gives us a bunch of new approaches that we didn't have previously. But yes, the non-determinism is definitely a factor if you're expecting that. Sorry, go on.

Lucas Dohmen: I think Eli also made a good point. You also touched on it a bit, but if we zoom out a bit, using the LLM output in your code is a bit like making a fuzzy copy of an open source project, because that's what it's trained on. It is probably copy-pasted from someone's open source project, but you do not get the advantage that you have that if someone finds a bug in it, you get the update for the thing. And that's something that you're losing, and this is why I think the comparison is not quite fair. Of course, dependencies are not free. Dependencies are a liability. That's definitely the case. But I think we're making it worse by just copy-pasting it into our code base, which is basically what we're doing with the LLM, and even adding some fuzziness and some some undeterminism with it. And the other part for me is I think you are right and like people are too careless in adding dependencies, right? Like in my previous company, we had like. If you take all the dependencies of the dependencies, we had like thousands of NPM packages installed, right? In my current project, we have nine. And when I tell people we have nine NPM packages, they are like, what do you mean nine? I'm like, nine in total, right? That's the amount of packages we have installed, and people can't believe it. And I think that's the power. And I think that's, for me, the one thing that I want people to take away from a discussion like that is, look at your browser today. Doesn't matter if it's a JavaScript library or a JavaScript functionality or if it's CSS it can do so much more than it did even four years ago, let alone 10 years ago right like there are so many things built in and especially if you stop paying attention to what is happening on the web and just let like some bot do it for you then you will also maybe, apply things that we needed 10 years ago but we don't need now, right? Like now we can solve in a much easier way right like you don't need popper.js you can just, use like a really nice anchor positioning css and you don't need to worry about all of that.

Dylan Beattie: It is interesting how the state of you know LLMs and AI assisted coding tools does often reach for patterns which were dominant a few years ago instead of the latest web standards, and I think that's just... it's the training data it's there is, LLMs think that websites are built in React because the data they were trained on, pretty much every website they looked at, is built in React. And so, statistically, the valid inference is that website equals React. You know, I'd love to, let's take an LLM and let's train it on hand-coded semantic HTML. And just, you know, that's what it does. Like, it's a weird LLM, but...

Lucas Dohmen: Yeah, just answering Coder by Heart's question, I meant nine in total, including transient packages.

Dylan Beattie: There is actually, if anybody wants to see a really interesting example, SQLite, which is one of my favorite pieces of software ever, incredibly rock solid, you know, brilliant local embedded database. SQLite ships as one C file. It is one. And some of it is, you know, machine, not LLM generated, but they have build scripts that rationalize it. But the idea is that if you want to use it as a binary dependency, it's one DLL. If you want one object file, one component, it has no downstream dependencies. And if you want to, you can copy and paste it into your project, and now you have a database. And there's a great, great talk from one of the creators of it talking about how they maintain this degree of quality and how they fix bugs. And it's a fantastic piece of software. I think three full-time maintainers over 20-something years. And it's most people have no idea it exists but there's six copies of sqlite running on their phone right now, yeah that's true their browser bookmarks are a SQLite database their contacts in their phones you know that the phone book application is a SQLite database and it's great and it's a really interesting kind of you know antithesis to the whole, npm lots of packages lots of transitive dependencies and everything it's like no it's one big C file and it does all these things so yeah.

Lucas Dohmen: One thing that I was thinking about from a bit ago, going to the browser standards also has advantages for, recognizability for people. My favorite example is the Material UI thing, where they replaced normal input fields with an underline thing. And then they recognized years later, okay, people do not know that this is an input field. They are entirely confused. And I think modern CSS allows us to do small variations of the existing form fields, for example, but without giving up on the recognizability of the field. Like, okay, it now has your pinkish color, which is nice, but it's still recognizable as a form field and you're not going super creative and nobody understands that this is a form field. I think that's also an advantage of sticking with...

Dylan Beattie: The convention that sort of causes me the most pain is we decided a long time ago, radio buttons are round and you can pick one and checkboxes are square and you can pick as many as you want. And the number of websites that I have seen where they've used checkboxes, but then they've written some code to make them behave like radio buttons. And so one, it's confusing because you think you can pick more than one, you know, flavor in your milkshake. Like, I'm going to have a blend smoothie today. I'm going to have apple and carrot. And then you're like, oh, you mean I have to choose apple or carrot or ginger? I can't have all three. And you're like, well, if you'd had the radio buttons, I wouldn't even have had to, I'd be like, I get to pick one from this list because that's, and, you know, it's, because that is so kind of ingrained for me, because that's how user interfaces have worked for my entire career. I don't know if there are people out there for whom that's not true, but it drives me nuts when people get that one wrong.

Lucas Dohmen: Yeah, that's true. So it makes it a bit easier to stick to the things that people have learned over decades of how certain UI elements work. And I mean, there is room for innovation, right? Like if you have one input field where you have a really great idea, go ahead, like test it and see if people really like it. But stick to the standard stuff, both in the code way, but also in the UX/UI way in most cases, because people don't want innovation for their text field. They just want to enter their stuff, right? So use your innovation in other places in your application.

Dylan Beattie: And also like, you know, someone's like, hey, we built a better text field. I'm like, brilliant. Here is a list. I want you to go away. I want you to try this in traditional Chinese. I want you to try it in Hebrew. I want you to try it in Arabic. I want you to try it in Korean. I want you to try it with a screen reader. I want you to try it on a mobile phone. I want you to try it on a dashboard on a car. When you've solved all of those problems, come back and we'll talk. And they're like, what? And it's like, you have no idea what a text input type equals text is actually capable of. Because you are probably, you know, and I say this with respect. You are probably a western european. Every document you've ever read in your life reads from left to right starts at the top of the page it goes down and you've always been able to see with your eyes and click with your fingers and you know all you need to do is find somebody for whom one of those things is not true and suddenly your homebrewed text box replacement is like oh, oh look at that in Japanese the underline still on the bottom but the text flows downwards that's not gonna work.

Lucas Dohmen: Yeah exactly. I mean it's also interesting like I worked with developers before that were surprised that for example a form can be submitted without JavaScript right like they did not know that this is possible, right? Like they were, surprised because they're like huh how do i make JSON out of this and i'm like, let's go back a few steps. Yes, exactl. So, we did not get into the question at the beginning about CSS-in-JS. Like, we are a bit over time, but, like, I would like to take, like, five more minutes to just talk a bit about organizing CSS. So, I think, on the one hand, I think we need to categorize the approaches that we know, right? Like, there is this whole approach of nesting, basically, that was introduced by Sass and now is available in CSS. So if you want to make sure that something is only true if it's in a certain container, then nowadays you can have native nesting in CSS and it works well okay, I would say, in browser support. I'm currently always using a compiler that compiles it to non-nested code still.

Dylan Beattie: So, with Lightning?

Lucas Dohmen: Yeah, exactly. With Lightning or with esbuild, both work really well. The advantage of this is, as soon as the coverage is good enough, I can just turn off the compiler and I'm done. This is different to Sass, right? I would recommend checking that out like i think a lot of people have missed that like like in conversations I see that a lot of people missed that. And then there are two other approaches the CSS-in-JS approach and the utility class approach or Tailwind, let's call it Tailwind. Like it's the the [tool] in the room um I think, the the CSS-in-JS approach most people have realized that this is a dead end right like um it has gone into the wrong direction like it is bad for performance it's hard to maintain. Most people I know have moved away from it right? And i think, it is time to rethink that approach if you are going down that road. Like the utility approach, I think there is a much more like... you can have a mixed approach, like using some utilities, using some classes. My preference is to use as little utilities as possible. But I can understand if you want to have a few things like doing something like a margin helper or something. But going all in, I think is also a weird approach. If you have a CSS component that is wrapping in some class, then it's something you can also delete later. Deleteability for me is one of the major factors. When I don't want this component anymore, can I delete one folder and it's entirely gone? Then it's nice. And that's my main approach to CSS maintainability. What's yours?

Dylan Beattie: The thing that has always frustrated me about utility classes is that they... They take the, all of the drawbacks of inline styles and actually make them worse because like you say, you got a button and you need to just move it a little bit. And so you have a one button that needs 10 pixels of left margin. And so inside the tag, you could say style equals, you know, margin left 10 pixels. Um, utility classes, and I will give you a class called margin left 10 or margin left 10 PX, which is the same, you know, class is the same length of style. So you haven't saved any typing there. And the name of the utility class is about as long as the stylesheet rule was in the first place. And it only does one thing because it's not like, you know, because classes work well where they're like, you know, H1 class equals logotype. It's obviously, it's nothing to do with what it looks like. It's to do with its function. We've got a heading on our website which has a special job. And so that allows us to target that. You know, H1 equals big green underline. Well, if that says big green underline, you might as well have done it by using a font size and a color and a text decoration. And if you then go in later and say, well, actually, big green underline now is pink italic, and it's still called big green underline, because that's the abstraction that you get out of class names, is you can say, well, the logo type now is going to, it's not the old font anymore, it's the new font. The abstraction doesn't leak across the boundary there. But with a lot of utility classes, you don't get the abstraction because the class name is so tightly coupled to what it does, and you don't get the brevity. And so instead of learning native CSS, because you know how to write the style by hand, what you've learned is somebody else's set of arbitrary descriptions for all of these visual concepts. And so it's like, well, you don't really know. And, you know, I know people who particularly tailwind, people who find it incredibly productive because they can just find a class that does what they want and they drop it in and it does what they want. And I'm absolutely, I am sympathetic to people who are like, they have a website. It's almost right. They don't have a material, like a design system. They don't have a design team. They have not got like a, you know, sort of top down holistic semantic HTML. They just, this button's in the wrong place and I want to move it and go home. And, you know, I think utility classes work very well in those scenarios, but I think those scenarios are symptomatic of an approach to developing web applications, which I do not enjoy. If I can get away with no classes and no inline styles anywhere, then I think that's using the web the way it was designed to be used by targeting everything based on semantics. But in terms of CSS-in-JS and stuff, the new things we've got. So one of them is we have web components now which give you a shadow DOM, so you can have a component on a page which is insulated from the rest of the rendering layout. So you can target styles specifically at reusable components without them bleeding out into the rest of the site. We've got css layers this is another kind of really big deal when it comes to managing specificity, because you can you know say well this is our base and then we've got this layer here which only applies to these components but then we've got this third party widget that needs weird styles so we'll put those in a dominating layer so we know those are always going to take effect on there. We've got much much better support for selectors so you can do something now like i had a really, interesting example the other day i've got a scrolling marquee, so sponsor logos like moving left to right and the marquee tag is gone that's not there anymore. And the problem is that you know if there's only three or four sponsors you don't want them to scroll at all because it'll fit, and if there are 10 sponsors then it should take 10 seconds to go across the page and if there are 20 sponsors it should take 20 seconds so they don't move too fast, and you can now using CSS you can write a rule that says look this thing doesn't move, but if if there are five images inside it then i want you to apply this animation and this is the animation timing but if there are 10 images inside it you apply this animation timing and if there are 20 you apply this timing, and it's a little bit of a hack because it's based on you know does this thing have a 10th child but it works and it's very easy to see why it works and it's very very kind of self-contained. And it means that the code which is rendering it does not have to emit special classes based on how many logos are going to appear in this component and so on. And the one thing which is still, to me, painfully absent from CSS is the ability to render something in a smaller font if it's got a long word in it. Because this is where the relationship between styling and content management comes in. You know if you're dealing with so you've got... German? a list of rock bands. Well yeah German is a good example actually because German compound words can end up very very long but uh you know like like rock bands uh you know you've got a band called Muse, that's four letters. You can show that in a nice big font without messing up the layout but then you have a band called "...And You Will Know Us by the Trail of Dead", and if you try and... The developer should not be making decisions about the names of the bands that are going to be on the ticket website. But you do have a problem there. And at the moment, the only way to solve that problem is that the code which renders it has to put classes on the output and... Based on the length of the text and then the CSS you got to pick up on those things and you know it would be it would be very nice to have a facility that would allow you to do selections based on the length of the inner HTML. Yeah, I. agree Yeah and it wouldn't be something i'd use every day but it would be something that i used about once a month and yeah.

Lucas Dohmen: Definitely. And one thing I would want to add to the whole tailwind and stuff debate is one thing you should consider is, is your problem really a tooling problem? Should you have a different tool or are you missing an expert on CSS in your team? If you are a bigger company, hire people that know CSS really well. They are unfortunately very underappreciated and then replaced by very mediocre tools, right? And i think having someone like one person on the team that will help you like architect your CSS. You have an architect for your JavaScript. You have an architect for your back end. Uou have no architect for CSS and you're confused why your CSS is hard to maintain, that's... sorry...

Dylan Beattie: Let me recommend if I can recommend a book at this point. It's called "Architecting CSS" it's by Martine and Michael Dowden and it is basically... It's a couple years old now, so there's a few of the newest shiny features aren't covered in it, but that is a very good kind of, this is the landscape of CSS if you are approaching it from a software engineering perspective as opposed to a front-end design perspective. And anybody who is trying to kind of engineer their way out of a hole, whether it's CSS-in-JS or they're trying to move away from Tailwind or they just want to consolidate a lot of disparate styles and approaches, it's a good book. Well, well worth picking up a copy of that.

Lucas Dohmen: Awesome. I will put in the show notes for the people that want to check it out, and I think at this point we will wrap it up. We are a bit over time already and thanks a lot for your time Dylan. It was really nice thank you, and yeah to everyone who listened thank you for listening um if you are listening on Software Architektur im Stream"... switching between English and German it's really hard... Then also check out Maschinenraum if you don't want to miss any future episodes and yeah if you want to meet us in person come to Software Architecture Gathering we will both be there and we happy to chat with you and, yeah answer any additional questions and everything.

Dylan Beattie: And it means you get to go to Berlin and Berlin is awesome and It's one of the most fun cities to visit and i'm looking forward to it immensely.

Lucas Dohmen: Awesome all right so take that from Dylan so have a nice day and see you soon. Bye.

Dylan Beattie: Bye bye.