Note: Using Alpine to handle server responses makes the raw response object data visible in the browser inspector as seen in the video and this is not always desirable (e.g. in an information aggregator app that has a lot of copycats for example) - definitely better to have HTMX handle server state in that case and to have HTML/HTMX fragments returned without any object data visible, and use Alpine to handle app state only (turning modals on and off, light mode/dark mode etc.). Very good tutorial other than that.
Thanks for the tutorial! Can you do a follow up with adding some client side logic (like a search bar you mentioned at 11:00) and show how we can synchronise the state stored in alpine after HTMX updates the content of the page
Awesome as always I'd love to see something on handling auth with go (or fastapi) and htmx (plus maybe alpine?) and how you handle sessions, or jwt etc. Also, how do you decide when a project already using htmx would benefit from using a proper js framework? I imagine there's a lot of overlap, e.g. I can imagine a todo list being solely htmx based
Sorry, I have to complain about this video. This is going to be confusing and misleading for newbies. The x-data you put the json in is out of date when the tr is inserted by the htmx response. This is not a sane way to mix alpine and htmx together.
I was thinking the same, for example, if you want to implement client side search like he suggested in the video, alpine would not be aware of newly added items in the list unless it sends the request to the backend (which is the thing he is trying to avoid in the first place)
@@danjamin123 The practical solution would have been to re-load the "Alpine component" as the target with the updated complete data. The reason to mix in Alpine is to control interactivity (filtering short lists, events, etc) and instead this mixed metaphors a bit in a way that isn't intended. I think I understand his intent, but it doesn't show the intended use.
Note: Using Alpine to handle server responses makes the raw response object data visible in the browser inspector as seen in the video and this is not always desirable (e.g. in an information aggregator app that has a lot of copycats for example) - definitely better to have HTMX handle server state in that case and to have HTML/HTMX fragments returned without any object data visible, and use Alpine to handle app state only (turning modals on and off, light mode/dark mode etc.). Very good tutorial other than that.
Great to watch another Go tutorial from you. Thanks very much.
Thanks a lot!
Thanks for the tutorial! Can you do a follow up with adding some client side logic (like a search bar you mentioned at 11:00) and show how we can synchronise the state stored in alpine after HTMX updates the content of the page
There we go, I have been waiting for someone to do this combination
Thanks a lot!
i follow though all the step here. this is gold content. hope to see more complex go echo project with tailwind css, ui library and db
Awesome, thanks - I'll be preparing more Go soon!
Awesome as always
I'd love to see something on handling auth with go (or fastapi) and htmx (plus maybe alpine?) and how you handle sessions, or jwt etc.
Also, how do you decide when a project already using htmx would benefit from using a proper js framework? I imagine there's a lot of overlap, e.g. I can imagine a todo list being solely htmx based
the best 💗
Thank you!
I would love to see a video with Alpine Ajax with Go as well. If it's possible you can combine it with HTMX and an SQLite database.
Thanks, I'll have a look at the Alpine-Ajax example!
Appreciate you bro!!
Thanks a lot!
Awesome content!!
Thanks a lot!
Thanks for the nice tutorial
Thanks for watching!
Please consider doing a tutorial on how to make a Django app deploy to an offline server?
Great video bro, one question, which do you consider is a better option to work with alpine, alpine ajax or htmx ? Thanks a lot
Thanks!
Thanks for watching!
ah, the good old HAG stack
Can't beat the HAG!
Can you do full api crash course with go? Please not todo app. Something in real world like blog. And real life folder structure not just in main.go.
I'd like to do this, hopefully in the near future!
Sorry, I have to complain about this video. This is going to be confusing and misleading for newbies. The x-data you put the json in is out of date when the tr is inserted by the htmx response. This is not a sane way to mix alpine and htmx together.
So what can you recommend?
I was thinking the same, for example, if you want to implement client side search like he suggested in the video, alpine would not be aware of newly added items in the list unless it sends the request to the backend (which is the thing he is trying to avoid in the first place)
Yeah, I don't understand why he didn't just use range and loop through the Todos list.
Why did he have to parse it into JSON and all that stuff? 🤔
@@danjamin123 The practical solution would have been to re-load the "Alpine component" as the target with the updated complete data. The reason to mix in Alpine is to control interactivity (filtering short lists, events, etc) and instead this mixed metaphors a bit in a way that isn't intended. I think I understand his intent, but it doesn't show the intended use.