yeah I 100% agree. it was a mistake on my end! to parse it over and over again whenever a request was made is just not efficient. but this was just a simple demonstration of using HTMX with Go. edit: I've pinned your comment so that everyone can see it :)
@@ransomware9086 thank you for the comment. I think parsing the template in the request is always bad for performance, it's alright for dev purposes. but, for production, the template should be fixed and only the data should change.
Thank you and please. Please make more videos on how to use Golang and htmx for usefull webapps or even just to use htmx instead of a local GUI. It is hard to find a beginner friendly route to start.
I could do it ;) do you have anything specific in mind? like creating a todo list and then making it production-ready and deploying it (I think dockerising the application should be feasible enough?)?
@@FloWoelki none of what you mentioned is actually related to Go or HTMX this is still a ToDo with better devOps tools around it something other than ToDo I think is required, look at making a medical image reading project, a game maybe ...etc something along the lines of having many domains and components to see how this can actually scale or will be complete rewrite
@@GreatTaiwan todo is the perfect app actually. It can have authorization, multiple views (todo list, details view, authorization pages, profile pages), protected routes, utilize HTTP headers, persistence via database, Redis, dynamic assets like images (-> S3 buckets), mounting an SPA to a part of a specific heavily interactive page, I could go on and on. - Medical imaging? Nobody would watch that. - Game? Nothing relevant to htmx/go, just Javascript and a lot of programming patterns. - An over-engineered to-do app? Heck yeah!
@ Nah you can write your backend code in any single language and javascript (especially without typescript) just sucks. So if you need to do some frontend stuff for it its much better than getting a full-front framework like React or using in-line javascript
On 8:12 it says "GO = HTMX Demo" and "{{.Message}}" on my localhost:8080 page. Something changed since I am already using Go version 1.23 maybe? cannot find the mistake in my code
Thank you for this well-made video. My question is, would it be possible to still inject the data in the templates (that easy) if we follow the `Separation of Concern` paradigm and have the BE and FE apps run in separate environments say.. Docker containers for example?
@@theseangle not sure if that's the case. I'd call it inverse ligature or something between. There are actually two signs that are required by the language formal syntax, they are not "joined", only displayed as such to the user of the plugin. While a ligature is actaully a joint sign... so no? Not sure what you're aiming at anyway.
dont parse templates in runtime, parse them during init instead
yeah I 100% agree. it was a mistake on my end! to parse it over and over again whenever a request was made is just not efficient. but this was just a simple demonstration of using HTMX with Go.
edit: I've pinned your comment so that everyone can see it :)
@@FloWoelki no. don't use init, since it adds a side effect to import behaviour. create your own init routine and do it in there
@@ransomware9086 thank you for the comment. I think parsing the template in the request is always bad for performance, it's alright for dev purposes. but, for production, the template should be fixed and only the data should change.
Thanks, very good and understandable guide👍Hope to see more rust/go videos in the future
thank you so much! there will be definitely more content about Rust and Go!
Thank you and please. Please make more videos on how to use Golang and htmx for usefull webapps or even just to use htmx instead of a local GUI. It is hard to find a beginner friendly route to start.
All htmx tutorials are simple. Why no one wants to show how to build production grade apps? Styling, components etc
I could do it ;)
do you have anything specific in mind? like creating a todo list and then making it production-ready and deploying it (I think dockerising the application should be feasible enough?)?
@@FloWoelki Yes that would be awesome
@@FloWoelki none of what you mentioned is actually related to Go or HTMX this is still a ToDo with better devOps tools around it
something other than ToDo I think is required, look at making a medical image reading project, a game maybe ...etc something along the lines of having many domains and components to see how this can actually scale or will be complete rewrite
@@GreatTaiwan todo is the perfect app actually. It can have authorization, multiple views (todo list, details view, authorization pages, profile pages), protected routes, utilize HTTP headers, persistence via database, Redis, dynamic assets like images (-> S3 buckets), mounting an SPA to a part of a specific heavily interactive page, I could go on and on.
- Medical imaging? Nobody would watch that.
- Game? Nothing relevant to htmx/go, just Javascript and a lot of programming patterns.
- An over-engineered to-do app? Heck yeah!
@@FloWoelkiI hope you read my reply to @GreatTaiwan
Don’t see the reason to use htmx. All what was shown can be easily made with simple JS with no need to learn htmx syntax.
Htmx is specifically for people who dont like interacting with javascript
@ if you’re involved in web dev you just can’t don’t like JS or probably you should change the job.
@ Nah you can write your backend code in any single language and javascript (especially without typescript) just sucks. So if you need to do some frontend stuff for it its much better than getting a full-front framework like React or using in-line javascript
@@gigalodon14 Anyway JS is a must-have knowledge and you can’t escape it in web dev. It’s much easier if you like it.
On 8:12 it says "GO = HTMX Demo" and "{{.Message}}" on my localhost:8080 page. Something changed since I am already using Go version 1.23 maybe? cannot find the mistake in my code
Thank you for this well-made video.
My question is, would it be possible to still inject the data in the templates (that easy) if we follow the `Separation of Concern` paradigm and have the BE and FE apps run in separate environments say.. Docker containers for example?
Wow 😮
Thank you very much!❤
You're welcome 😊
Nice video, just the abbreviated variable names make me nuts.🤣🤣🤣
Fair point :D and thank you!
Kuss auf die Nuss
Had me until this != font heresy.
Fair point :D I've also removed this for my personal use and future videos.
It's called ligatures
@@theseangle not sure if that's the case. I'd call it inverse ligature or something between. There are actually two signs that are required by the language formal syntax, they are not "joined", only displayed as such to the user of the plugin. While a ligature is actaully a joint sign... so no? Not sure what you're aiming at anyway.