Wrapping Up

[00:00:00]
>> Hopefully you like, subscribe, do all those things on Twitch. And there you go, that's really the entirety of the HTMX course. Hopefully that was not too much of a brief introduction, but enough to show you that there's quite a bit of things you can do with such a simple library.

[00:00:13]
And again, the entire non-GZIP size of HTMX is like 40k. Its GZIP size is, I think, 12k I've been to websites recently that all it was was a simple marketing page. And it's GZIP size was 370k. And its actual size was two megabytes. Two megabytes of JavaScript did show some colored squares plus a buy button.

[00:00:33]
Kind of wild to think about maybe, just maybe we've jumped the shark here, just saying, maybe we should consider something different for the simple things.
>> If I put a delay in for the response, does it delay the server's response to other users on the site? I'm guessing no, but I'd like to know for sure.

[00:00:50]
>> You're talking about in HTMX the delay or in Go? Because obviously the Go one, that's an endpoint, we just put it in intentional sleep. You'd never sleep in an endpoint intentionally. I mean, I have no idea why you would do that. If you're sleeping in an endpoint and there's an intention to it, you're doing something kind of wild, right?

[00:01:05]
You're doing something that may be misdesigned there. But if you're doing it on the client side, yeah, it has no effect, right? That's just your standard server client.
>> I've also been-
>> Okay, to be real though, you could put in some small sleeps, maybe some millisecond sleeps here and there.

[00:01:19]
Then when your boss is like, we need to make things faster, what do you do? Start removing some of those sleeps, you know what I'm talking about? Improving endpoint performance, all right? Christmas is around the corner, people plan for it.
>> I've also been told to reduce round trips to the server, and this seems to increase those.

[00:01:38]
Does that slow the site down at all?
>> It could and it couldn't. I don't know if I buy that as an argument yet, in the sense that you get to choose how much data you first frontload as a server as you send down stuff, and then you choose how much interaction or what interaction it takes.

[00:01:55]
If you rendered a website that had friends that you had to go click on, right? You could put all that stuff first on the page, but if you went and hovered over a friend to see a pop-up, do you think that they transferred all that data down before you ever put your mouse over that?

[00:02:10]
Probably not. How much do you want to bet? They're requesting that information. Now, as long as you have nice HTTP caching, you have some acceptance of potentially stale data, how you wish to model that? You could always cash it at a browser level, a lot of these requests long as you use the right verbs and all that.

[00:02:26]
So there are ways you can do things that make sense to make it fast. This is just one way and I'm not saying this solves all problems. Maybe you want to use your own JavaScript requesting/library/rendering to do this. And there are some cases where it makes sense. I can think of something Dax recently built, if you don't know who Dax is, he's on Twitter.

[00:02:45]
He has the spiciest takes of all time. And he built this thing that's super, super fast, super smooth feeling. And it's all about viewing and introspecting data logs from your server. To me, that seems like, yeah, you're gonna want to really think about your caching for that one, cuz you really don't want to just be hitting servers, scrubbing logs causing a bunch of transfer.

[00:03:01]
You don't want to be interrupting production and all that. And you want it to be really, really nice and highly cached. Yeah, I could see you wanting to do it then. Do you have to? I mean, maybe you don't, maybe you want to cache it at a browser, get level and that's fine.

[00:03:14]
And then you can do all of your filtering at that level. It's just one way to do things.
>> Does it make sense to mix HTML and React?
>> People mixed HTML and Reacts, I've seen it done. In fact, the Bethe stack, which is that one that I mentioned earlier is bun, elixir, torso and HTML.

[00:03:33]
What they don't say is they're using react as the server side template engine. So they're still using react just only on the server, so interesting. We call it a React cocktail, okay? And then there's one on the client side that did this cool like eventing and stuff like that.

[00:03:52]
>> Can we get some more examples of projects that would not be favorable for HTMX?
>> Anytime I mean, you could always shoehorn in some amount of HTML. So you can always argue why you shouldn't use HTML. Anytime that I see something that is highly client interactive, and what I mean by highly client interactive, I don't mean a bunch of squares on the screen.

[00:04:16]
So if you went to twitter.com, a lot of this is a bunch of squares on screen, right? Look at that, htmx org guy, right? There saying something who knows what he's even saying? But anyways, a lot of this is a bunch of squares on screen, how much of this needs to be dynamically updated?

[00:04:30]
Well, we have a little notification right here. If you can stream in out of band updates, you kind of already have that thing solved. And so, it's like how much do you need Interactivity. If I can drag and drop and move a bunch of stuff around and create really customized views, maybe that part should definitely not be HMX.

[00:04:45]
You shouldn't try to make that HMX. It'd be crazy to try to make that HTMX. I don't even think it's possible, you'd want a Javascript side experience here, and that would make way more sense.
>> There was a question about how you would get in your autocomplete with HTMX, the LSP?

[00:04:58]
>> How's it going the autocomplete made an I made an LSP, it's pretty straightforward. GitHub, sorry I have it at 4k and I never have it at 4k. HTMX LSP, it pretty much works. Couple of people have been contributing to it really made it awesome. There's still like a bug or two.

[00:05:19]
It's in cargo, so you can cargo install HTMX LSP, but I don't have it, so it's hooked up with Mason. And I believe there is a VS Code client right here. I'm not exactly sure how well it integrates with the VS Code client. It might be in the readme somewhere down here.

[00:05:33]
VS Code, no official support. Emacs, no official supports. There you go. So, I'm just kinda honestly, I'm just waiting for somebody to say, Hey, we got it in Mason, and I'll be like, hey, there you go. You can install it now with Neo Vim, and then if someone wants to do it for whatever it takes to do in VS code, go do it.

[00:05:48]
I'll be potentially building an LSP here soon again for work. So I'll probably learn all about the VS code side. So if it's not done by then I'll just do it for this.
>> This is a little related to the React question earlier, but do you have any thoughts on a JavaScript framework that is a good match with HTMX in general, like Solid or Svelte?

[00:06:08]
>> I don't know how Svelte will do, but I would just assume if you're already using a big framework, you should just use the one you know best or the one you want to learn. Right, I don't think there's a lot of dictation required. You can use Leptos and Rust if you really want to you can use Camel and dream if you want to write you got a lot of options.

[00:06:29]
It's not something that dictates, right? It's something that is trying to be like the opposite of it. It's having as little opinions about how you do anything as possible.
>> Is there a way to preserve state without a form submission? The example, I'm thinking is a tabbed view with multiple steps.

[00:06:47]
I want the user to be able to go through the wizard and then have the previous steps data persist when they go to the next tab or another component, but not Submit anything until the final step is finished.
>> Yeah, you're gonna need to have a bit of JavaScript for that one.

[00:07:00]
That's gonna have to be some level of JavaScript going on. I've never tried to build that one in HTML, so I don't know how much that is. But to me, that sounds like, yeah, you're kind of breaking into potentially, I mean, the problem about that entire thing is that it's hard to represent that state as a URL.

[00:07:17]
You have this whole problem where you're really representing a single piece of content into three separate windows, or four separate windows, or however many are in the sign-up wizard. And so that's difficult. You can use cookies, you could use local storage. You could do a bunch of stuff to be able to recall from wherever.

[00:07:35]
So is it impossible? Absolutely not. Is it hard? Probably not. I just have never tried so I don't, I've never tried to do it with local storage or cookies, so. Sure you can, though.
>> I'd do something like hidden input fields, like a fake form kind of thing.

[00:07:53]
>> Say that again?
>> Hidden input fields, you can have a form on the page with a bunch of hidden input fields that can't keep state.
>> Yeah, you could do it. Yeah, input fields would be really easy to kinda make that happen.
>> Is there a reason you weren't using VEM syntax in your CSS?

[00:08:10]
>> Using which syntax?
>> BEM.
>> I don't know what BEM is.
>> That's that block object modifier. I think, something that's not in the code someone's trolling.
>> I don't do CSS, okay? So we've already talked about this. I call it a Google first language. Well, now I guess it's a ChatGPT first language, or a V0 first language, okay?

[00:08:31]
Don't test me on that, okay? I don't know them. I did a flex list without looking it up. And I did it in both two different directions. I already feel like I have 95% weight there. Appreciate this time. It was fantastic.