The css zen garden was a beautiful lie
So I want to talk about a concept of locality of behavior today, and separation of concerns. But I think the best way to kind of talk about it is there was a website that came out probably in the early 2000, maybe in the late nineties when CSS, believe it or not, was just kind of getting introduced to the world, of developers and and regular people and, you know, maybe it had been around for a while, but the the concept people were still kind of used to putting in, stuff directly into their HTML and, the concept of a separate style sheet, a cascading style sheet, CSS, was relatively new or at least not mainstream. So there was a website created called the CSS Zen Garden, and it sold a really beautiful promise that I was inspired by. What it did was it took some HTML and every page on the site had the same HTML. And then designers could go and modify the CSS file for that HTML and display that data in so many different ways.
Lazarus:And what it showed was just the power of this concept of the separation between data, your HTML, and your design. So they could be fully decoupled. That was the kind of beautiful promise of the CSS Zen Garden. So designers in the future would be able or at the present time, would be able to work independently from the people who are, you know, building the data of the site. They could have these kind of 2 separate worlds, and this was really a novel concept, and very exciting, because, you know, if you're used to working in in something and you're you make these changes, you you like this idea that it can look however you want.
Lazarus:You just build the HTML once and then you're done, and then you can monkey around with the the design as much as you want after that, and you don't have to worry about it. And that was really appealing, and the CSS Zen Garden really just kind of it sparked a whole just this idea really swept through people. It was such a simple example. There was, you know, you could see the code right there, but the I would say that the the dream that it sold over time in the real world was basically an illusion. In the real world, the zen garden was just such a simple example.
Lazarus:So, sure, it looked completely different, and you had these different images, and you had these different layouts, but it was a single page with, you know, I don't exactly remember. I actually it's probably still up. I really have no idea, and I'm not gonna look it up right now. But but it was just a small page, just a little a little page and it was super cool and it was like the kind of thing you'd see for, like, someone's personal site, like about me and here's my here's the different projects I work on and stuff like that. That was the level of of sort of difficulty of it.
Lazarus:So people were able to do these things and just change the CSS and really make it look different. But there was a whole industry that was inspired by this, this separation of these concerns, and it turned into something a lot bigger and, you know, people sort of thought about it and expanded that concept of separation of concerns, I would say. And I think the the logical outcome of that is this sort of diff the difference between the back end and the front end, And this kind of like JSON layer of communication between them, that you see now. This is kind of, the concept there was it's kind of the same idea where you can you just build your JSON layer, and that can be served anywhere. Doesn't matter what your front end is.
Lazarus:Right? This can be served to, an app, or it can be served to, React thing, or it can be served to, an API just that needs JSON. So I think, and people can correct me if they disagree, but I put those in a similar category. And the CSS sun garden really impacted me at the time, and I spent years trying to achieve that perfection of the Zen Garden, the Zen of just building the HTML, and and then styling it afterwards with CSS and a separate CSS file. If you did the same, then you probably remember that that's not what happened.
Lazarus:So that's not how it works. It does not work to do that. You need special data on every screen. That's what makes the apps great. You need to have okay.
Lazarus:Even just let's start with the CSS Zen Garden. Right? Can you really change the whole layout of a site without changing the HTML? If you've ever done that before, you know the answer is no. You can't do that.
Lazarus:That was the problem with people's experiences trying to do this. They spent years trying to achieve this, and you just can't do it. You end up, you know, you have to move stuff around. You can't just, like, give everything an ID and then control it from the back end. And if you do that, you're it's gonna be a nightmare.
Lazarus:Your CSS file gets bigger and bigger and bigger. You've got custom CSS for every single part. You something oh, this is supposed to be above this other one, but we can't change the HTML. So we'll just float them both, and we'll put a clear down here, and then, you know, we'll wrap that. We can't even wrap it.
Lazarus:We it has to be already wrapped in a div, and we don't have an ID for that one. So okay, we'll just make a few changes to the HTML. Alright. We'll go in and we'll move the HTML around this time, but that will be our final HTML. Right?
Lazarus:So the dream of that, it just never made sense. The worst part was the maintenance of it. Your CSS file, everything was separated from the HTML and the CSS. So you look at your HTML file, and you have no clue what's going on because, okay, here's the section of the site that I want to fix. Okay.
Lazarus:What section of the site? What does this map to? I want to change this. I want to update it. I want to do this.
Lazarus:So, okay. I got to find the CSS file. It's not even linked in the same little partial view. It's at the app level. All the CSS files are contained into one CSS file.
Lazarus:Let's see. We got a minified one. Okay. Here's the regular one. And now I got to find okay.
Lazarus:What's the IDs for this? Okay. Well, the IDs sort of matter, but also I've got classes all over this. So I'm looking through this gigantic messy CSS file trying to find okay. If I want to change it out, how do I what?
Lazarus:Which section of this even matters? If I change something here, do I rely on this class in 20 different places on the rest of the site? Probably because you're trying to reuse code, you know, you don't just don't repeat yourself, reuse that code. So you can't make a change in one place without affecting it everywhere. So I'm not, you know, this this kind of feeling for me is not unique to me.
Lazarus:This is everybody I have ever worked with on CSS. So that's why they came up with that's why they're coming up with better things, better ways to do this. And this is also true, you know, in my opinion, what is kind of happening now, that process that people went through of thinking that the CSS Zen Garden was gonna be the answer, and slowly realizing that it's just not. This is my, you know, other people will disagree, but this is kind of my opinion of what's happening right now with the JSON centric, React, Vue, Next JS, these are all relatively new technologies, so it's kind of silly to say that they're, like, you know, gonna hit their wall or something, but, we'll see. I think the problem that happens, the difficulty that people come across, they have this perfect theoretical world where they have a JSON layer that connects their front end and their back end, and their back end just serves everything up in the same format to everybody.
Lazarus:That's not what you need. You need special data on every screen in your React app. That's what makes apps great is when you have this customized people who know the business, who know the app, they want to put that custom data wherever they want to. That's what makes it good. People who know their business logic customize every single interaction.
Lazarus:That's the art. That's the artistry, and the artisan style of building. You need to make sure that this is giving people the user experience they want. The mobile site is gonna act differently than the website. It's going to need to be served different data.
Lazarus:So this perfect concept of, oh, you just send the data once, no. If you're doing that, I promise you, you're going to have a separate call for your app than you do for your website, as you should. But you're going to think in the beginning that it's all going to be 1, but you need to interact with it differently. You need different fields there. You need less or more.
Lazarus:You just need different data and different actions on every screen, right? So the core of the dream of the CSS Zen Garden, and in my opinion, the JSON layer front end back end separation, the dream never made sense. The worst part of it is the maintenance. Everything in the project is separated. The JavaScript, the CSS, the controllers, the views, the events.
Lazarus:The events might be the worst part of it. The events are happening just things are happening all over the place. They're triggered by this, they're triggered by that. You have no clue when something goes wrong, which event triggered it, why that was happening, where the events are, which there's no there's no natural flow of this stuff. So this complete separation, this dream, this ideal is a debugging nightmare, because it also includes the network.
Lazarus:So on top of everything else, you're working all these things over the network with your events, literally every part of your application has been separated and spread all across the app. It's all been obfuscated too. So, you know, you see something that's just like an abstracted function call, and it's like, what is that? What what does that actually do? What does that where does that put the data?
Lazarus:Where does that, you know, it's very hard to to track these things back. And they've tried. They've made, you know, better and better tools. They have, like, tooling upon tooling upon tooling. They have all these abstractions.
Lazarus:They're like, if you ever look at what the HTML looks like in one of these kind of react style apps, you've got like 37 layers deep of all these abstracted HTML tags at this point. So there is a growing backlash to this just like there was to the CSS, you know, nobody's ever nobody ever blames the CSS Send Garden. This is just me, but everybody knows what the backlash to that CSS in a separate file is. Right? It's tailwind CSS.
Lazarus:That was a revolutionary kind of concept when it was introduced, and still people are still mad about it, That you would take your beautiful CSS and put it in line. This is like heresy to to a whole group of developers that grew up in a certain era and that are maybe we're still trying to do that. But what quickly became the reality is that it was unbelievably easy and fast, and just such a better developer experience. Because you could look at the HTML and see what was happening. You could see what your design was.
Lazarus:You could move stuff around. You could change the design. You could, you know, bundle these these, classes together and just kind of have complete control and not have to figure out somewhere else where is this happening. Right? And people still argue about Tailwind, but realistically, Tailwind has taken over the web.
Lazarus:They are the big one. That's the one Now when people talk about CSS, Tailwind CSS is just part of that conversation. You know, I saw a tweet recently. Taylor Otwell, who's the creator of Laravel, just tweeted happy birthday to Adam Whelan, who's the creator of Tailwind. And it was something to the effect of, you know, happy birthday to Adam Whelan.
Lazarus:Adam Whelan, the creator of the only maintainable way to do design. And it's true. Maintainable is is the key here, and part of that, the huge part, I would say the biggest thing is the locality of behavior. So I see that as like l little o b sometimes, like locality of behavior. It's like an acronym, but I mean it just means that.
Lazarus:It's like locality, where it is. It's local. You can see what's happening right there. If something goes wrong, if your button looks wrong, you're not searching through 10 different CSS files to figure out which one's loaded and which one supersedes the other. Alright?
Lazarus:You can just look at the button, and see all the classes that are on it, and change them. So this is like this is, like I said, it's heresy to certain people. But for those of us who want to just maintain really good apps, build them quickly, it's just been a gold mine. And that's why it's taken so over. That's why it's so popular.
Lazarus:And Tailwind, I think, is just the beginning of this concept, of this kind of backlash to this complete separation, and these I would say, like, if you think of it as, like, the type of people who are diagramming out their website before they build it, and separating out, okay, the designs layer, this layer, this layer talks to this layer. Those people are going to do their thing. That's that's separate. They're gonna have a hard time building apps. I know that, but they're gonna be in big companies.
Lazarus:They're gonna dump a lot of money into it. They're gonna have project managers. They're all they need all that stuff to keep that kind of thing going. For people who are just trying to build apps, possibly as like small team, 1 or 2 developers, The locality of behavior just saves you so much time, and that's that's where HTMLX is part of. That's the world, I think, that h t m x is part of.
Lazarus:They're not the only ones. There's also Phoenix Live View, was kind of an original one that sort of they use web sockets. You keep a web socket open, and whatever changes you make on the front end and back end, they use a similar kind of thing where it all sort of happens. It's all intermingled. The data, the design, the front end, the back end, it's indistinguishable.
Lazarus:Laravel Livewire is an amazing product, and that uses all these PHP classes. You just write back end PHP, and somehow magically it is handling the front end for you. So when you make a change on the front end when your user does something, it updates your your views, your your blade views, your templating language views, so that it can just basically do all these front end things, and it has like a direct connection to the server over AJAX. And it abstracts that away for you, but everything that happens, you can just look at the HTML. You can look at your blade view and your PHP code, and see exactly what the logic is.
Lazarus:What's happening? So all of these, and I'll actually add like 37 signals, has hotwire, which is a big tool like that. It's great. Sends HTML over the wire. Alpine JS is a JavaScript thing that I think works really well with HTML.
Lazarus:It's actually from the same creator as Laravel Livewire. That is basically JavaScript inline, and it's something you could think of it like a simplified version of Vue. You don't need to make a map of your entire, you know, front end models in line. You don't need to make a map to make it work, because you just can sort of sprinkle it in and and use it right in the places that it needs to be used. So these all have this in common.
Lazarus:They're essentially inline locality of behavior products that emphasize and focus on and literally lean into this thing that used to be considered for, you know, web stuff goes back and forth all the time. It used to be locality behavior was the default, then it's terrible. And, you know, you have all the big brains, all the eggheads who are like, that was me at the time, actually, I will say. I'm a computer science major, and and, I was very much, like, from the ivory tower, planning out my app ahead of time with diagrams and all this stuff and separations, and this is going to do this. The real world's so much more messy.
Lazarus:Just look at the code. If you've been doing this for a while, it's all right in front of you. This is the locality of behavior. People are starting to put things in the same file. You have crazy people like Peter Levels, who is on Twitter and, you know, he's an extreme example.
Lazarus:I wouldn't recommend doing everything he does for many reasons, but he's, you know, he's built his businesses multiple with like a single PHP file. That's it. Nothing else. And that's unbelievable, you know, when you compare it to some of the other the framework stuff that's out there and the massive scale of all this stuff. So I wouldn't recommend doing that, but there is this there's more than one way to develop an app.
Lazarus:And this concept of putting your stuff together, it's so good for maintainability for the long term. If you're looking at your code 5 years later, which I hope you are, I hope you're building stuff that has a life to it. That's one of the great things about HTMX is it's not going anywhere. It's not you don't need to the versions are not going to change it that much. Your old, you know, CDN is going to work forever.
Lazarus:You can come back 5 years later. You know, it's new, so I shouldn't really be saying this, but I feel very certain that 5 years from now your HTMX attributes are gonna look almost exactly the same. But most projects are not like that. If you spend 5 years away from your code, and you go back to it, think of some of the projects you've done. What's that gonna look like?
Lazarus:How are you gonna manage that 5 years after the fact? You're gonna try to update the versions. You're gonna do this. You're gonna do that. When you actually go in to make a change, if you were doing something where everything is separated and everything's all over the place, you have to then reassemble in your brain how everything fits together, how it works.
Lazarus:That's extremely difficult to do. If you have used this kind of locality of behavior concept, and and put things in line, put things in the same file, put things in the same folder, just look at the code. It's all gonna be right in front of you. Doesn't matter if you spent 5 years away from it, you can still tell what everything does. It's almost too easy where it's like you can have someone else look at this file.
Lazarus:They can figure it out. So tech folks, I think, like complexity, and there is plenty of space for that. You can find and create as much complexity as you want. For some applications, that's gonna be a good fit, but not for most apps. For most apps, you want to build it fast, you want to be able to fix it fast, you want to be able to maintain it in 5 years.
Lazarus:For most businesses, you want results, you want speed, you want less bugs, you want more maintainability, more clarity. So you want something that's gonna make your life easier for the next 5 years, and locality of behavior is going to help with that, I think. And HTMLX and Tailwind, Alpine JS, LiveWire, all these other ones I mentioned, they're gonna let you build like that. And, if that appeals to you, it's not gonna appeal to everybody. There's plenty of people who are who are really drawn in and excited about some of the setup with, the React as I was, you know, 10 years ago.
Lazarus:I got I went deep down the Angular JS path, got really excited about it. I made a bunch of apps in Vue JS, which I really regret now. Every time I go back to them, it's just an absolute nightmare, and I regret it so many ways. But the root of all that is this kind of big picture battle between the separation of concerns and the locality of behavior. And I think take another look at the CSS CSS Zen Garden sometime.
Lazarus:If you or take another you know, just think about it. Did the promise of the CSS Zen Garden pan out? And if not, why not?
