Subscribe
Share
Share
Embed
Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs
I want to talk a little bit about this big discussion of where HTMX fits into the world of development front end versus back end. And just in broad strokes, you could think of front end as the react angular view world and back end as the Laravel, rails, many, many others, Django. But it's kind of a you could think of it as front end back end. You could think of it as, maybe I switch that back end front end, or server, and client. So where's all the work happening?
Lazarus:Is it happening mostly on the server or is it happening on the client? And that's, you know, front and back. This has been a discussion. It's just a big discussion, and I think for sort of background knowledge on it, I've heard a lot of different talk on it. There's a great podcast called Mostly Technical.
Lazarus:It's from the Laravel world, but Ian Landsman and Aaron Francis discuss on one of theirs, and I'll link the episode in the show notes, but they talk about just a mental model for where to think of this. And I think there's a, there's a primogen and Theo videos that do the same thing. They're also talking about what's the mental model for how people approach development. Where is all the work done? And I think those are both really great balanced and reasonable takes for background knowledge for this whole discussion between the 2.
Lazarus:They're both perfectly valid ways to do it. But let's step back a little bit because in a more obvious way, you can only have one source of truth for your data. Right? You can't have if you are starting to have 2 sets of truth, 1 on the back end and 1 on the front end, 1 on the server, 1 on the client, you're gonna run into problems. Is the user an admin?
Lazarus:You can't have the 2 different answers to that question. Are they on a free trial? Can't have 2 different answers to that question. If you try to have 2, you're going to end up trying to sync every single action at all times because you don't know what information is important. There might be a tiny little flag on the user that determines everything about the client side, everything about the server side.
Lazarus:You cannot mix those up. You have to have a single source of truth. So which would you choose for your source of truth, The server or the client? The front end or the back end? And what kind of question is that?
Lazarus:Obviously, you would have to be insane to pick anything other than the server. The server, that's the cloud. That's where that needs to have it. If if the source of truth was the client, you would log in on a different device and they wouldn't know who you are. They wouldn't know anything about you because it was on the other client.
Lazarus:That's the client cannot be the source of truth. The server is the single source of truth. There isn't really another way to think about that. There's no debate. That's why that's in the database.
Lazarus:That's what servers do. That's the promise of the cloud. You can log in from anywhere on any device, all this kind of stuff. Your source of truth is the server. So if that's true, and it is, why would you go through the insane process of duplicating and syncing every single thing in 2 places.
Lazarus:Why would you do authentication on the client side and keep all that user data in a complete model on the client side? There's no reason to do it. You should it's a waste of effort. And yet, that's what the client side first are forced to do. They have extremely complicated processes of hydration and I can't even get into it because and try to look it up sometime.
Lazarus:Try to look at the the mental model that people have to construct to make a client side app that tries to be the source of truth for, or tries to mimic, or sync, or whatever it is. It's riddled with security problems. You have all these different OAuth options. Same thing. You try to do routing on the client side.
Lazarus:You try to do I mean, it's the amount of stuff that you need you should always be checking with the server for any form of sanity. You still need all the data. You still need to go to the server. The server completely wins that, and it isn't even close. So that's why I think long term, the server side tools are going to it's not a battle.
Lazarus:There's a room for client side. There's a room for server side. But when you're talking about really being able to build something that is consistent, that is easy to maintain, things that are server side are just going to win this discussion because that is the single source of truth. It you can query the data from there, and you can use the client side. This is where HTMX comes in.
Lazarus:This client side doesn't need to know anything. It just needs to display to the user what they need. You can decide. So let your server side shine and forget all the stuff. Forget building an entire model of your business logic of all your stuff in 2 places.
Lazarus:You already have to do it for your server no matter what. There's no way around that. You are building all that logic to query the database on your server. That's going to happen. Why do it twice?
Lazarus:So just if you build stuff from the server side first, if you need to do some, you know, animations and sort of, obviously you can use Ajax through HTMLX to load stuff in and you need to make things kind of move in a fancy way so that you get some of that some of that nice, react goodness or, or whatever it is. And obviously this whole episode is just a little bit reductive to the client side stuff. There's more important reasons. There's plenty of use cases where it's extremely good to have, you know, a client side first situation. But it's so overused right now, and most apps, I would say, we're in the vast majority, would actually benefit I think from from being server side first.
Lazarus:And that's kind of what this is all about.