Not having the url change on navigation tabs is bad ux. It's nice to share links plus reloading page will keep navigation state. Seems you could just do similar to how you have it but instead of setting hx-get, set href and use hx-boost=true?
Yea you’re right and tbh I didn’t know about hx-boost. But building it like a SPA makes it clearer what HTMX is doing for the sakes of the demo. I definitely agree that you should store as much state is reasonable in the URL.
@@tom-delalande Makes sense though I would say SPA should update url programmatically on nav for same reason, but in any case it presents a useful instance of how htmx/server side by default provides advantages vs SPA. And using native web behavior (href vs hx-get) means just in case JS is disabled the nav's will still work.
Cool stuff, that said because of how the is done with tabs it could do with accessibility work before it would be shippable, either by updating URL and aria current page. Or using tabs with tabpanel attributes
You’re right that this can be harsher on the server. I think that most of these request are requests you’d have to make anyways. It’s just instead of JSON you’re returning HTML
“The urls are not updating, that’s the point” is not necessarily true, since having a history entry or even a deep link can be very useful. Fortunately, this is very easy to do with HTMX using either HX-Push-Url response header or hx-push-url attribute 🙂
It really depends what you want. You might want a SPA that doesn't update the url. I think in this case with the menu, it's not the BEST example. However, there are times you don't want to save location state, like with your online bank.
@@pkop4I think he says “that’s the point” but I might be wrong. hx-boost is nice but it has drawbacks, the main one is you need to send the entire html page, which depending on your use case might not be what you want 🙂 but I agree that hx-boost is awesome
You’re absolutely right. And to be honest I didn’t know about hx-push-url. But making it a SPA makes it clearer what HTMX is doing for the sakes of the demo. I definitely agree that you should store as much state as reasonable in the URL.
Why not use both? Have React used for the first page loads, routing, and reusable components in code. And in that React code you can add HTMX tags that then use the server to update the components. I think for somewhat larger projects this approach would be quite manageable.
Why not use both? Well, for many reasons, but the 2 main ones: - in order to hydrate, React needs either SSR or manual mounting on a root. So if you don’t use React on the server, it gets very annoying to hydrate on each swap. - ReactDOM is 50kB min+gzip. And that’s just ReactDOM 🙂
We're using HTMX for internal apps. NO JS devs in sight. All the devs can do front end and backend in any language. This saves a huge amount! No client builds is a huge win !
You're getting better at these videos. Keep going man.
I'd pay for an Udemy course of Kotlin and htmx. Just saying.
Not having the url change on navigation tabs is bad ux. It's nice to share links plus reloading page will keep navigation state. Seems you could just do similar to how you have it but instead of setting hx-get, set href and use hx-boost=true?
You can also do hx-get and hx-push-url to get the url changes
Yea you’re right and tbh I didn’t know about hx-boost. But building it like a SPA makes it clearer what HTMX is doing for the sakes of the demo. I definitely agree that you should store as much state is reasonable in the URL.
@@tom-delalande Makes sense though I would say SPA should update url programmatically on nav for same reason, but in any case it presents a useful instance of how htmx/server side by default provides advantages vs SPA. And using native web behavior (href vs hx-get) means just in case JS is disabled the nav's will still work.
Tom is actually a genius!
Cool stuff, that said because of how the is done with tabs it could do with accessibility work before it would be shippable, either by updating URL and aria current page. Or using tabs with tabpanel attributes
Would be nice to see the react examples in a server rendered example like nextjs app router so it’s more one to one with the htmx implementation.
I love the project, will play with it on weekend to learn some htmx (also fira code is great =D)
Do you have a repo with any of these Kotlin & HTMX examples please? Great job on the videos by the way.
I just added the GitHub link for this one in the description
How much does it cost to handle this many ajax calls in the cloud compared to react ?
You’re right that this can be harsher on the server. I think that most of these request are requests you’d have to make anyways. It’s just instead of JSON you’re returning HTML
What are your thoughts on htmz
He did a video on it already! It's called "Use this instead of HTMX".
Another banger from the htmx man
“The urls are not updating, that’s the point” is not necessarily true, since having a history entry or even a deep link can be very useful.
Fortunately, this is very easy to do with HTMX using either HX-Push-Url response header or hx-push-url attribute 🙂
It really depends what you want. You might want a SPA that doesn't update the url. I think in this case with the menu, it's not the BEST example. However, there are times you don't want to save location state, like with your online bank.
Regardless, you still have a very solid point and recommendation.
Think he said "that's a fair point" so acknowledges the drawback, but don't think this tradeoff is even necessary if just using href and hx-boost
@@pkop4I think he says “that’s the point” but I might be wrong.
hx-boost is nice but it has drawbacks, the main one is you need to send the entire html page, which depending on your use case might not be what you want 🙂 but I agree that hx-boost is awesome
You’re absolutely right. And to be honest I didn’t know about hx-push-url. But making it a SPA makes it clearer what HTMX is doing for the sakes of the demo. I definitely agree that you should store as much state as reasonable in the URL.
Good stuff! Keep em coming
This is awesome ❤
Why not use both? Have React used for the first page loads, routing, and reusable components in code. And in that React code you can add HTMX tags that then use the server to update the components. I think for somewhat larger projects this approach would be quite manageable.
Why not use both? Well, for many reasons, but the 2 main ones:
- in order to hydrate, React needs either SSR or manual mounting on a root. So if you don’t use React on the server, it gets very annoying to hydrate on each swap.
- ReactDOM is 50kB min+gzip. And that’s just ReactDOM 🙂
We're using HTMX for internal apps. NO JS devs in sight. All the devs can do front end and backend in any language. This saves a huge amount! No client builds is a huge win !
Yo this is brilliant!!!
Good content! Keep it up!
why___ chatgpt will generate that in any lamg in 30s
nice video, just make the background dark next time
What do you mean? On the website?
@@tom-delalande yep, whenever you switch between the editor and the browser, the white background kills my eyes