this simplicity is incredible, similar to good old times, rendering pure html, loving it. A breath of fresh air. just yesterday spent 1,5h in a meeting about redesigning a frontend application. the redesign supposed to happen with simultaneous switch to a new design system. but the new design system is still in progress and their timeline to finish is Q2 next year. so we gonna do a redesign but with old design system. and then migrate to a new design system later at some point. this is the burden of huge corps. so frustrating. even for a simple admin-ui change you need involve frontend people and discuss how things gonna look like, which data backend API supposed to provide. I guess only during that meeting alone you'd probably have already functioning CRUD UI based on htmx. I wanna try htmx for our apps just as a hidden ui for internal team usage to simplify certain tasks like maintenance that otherwise would need to be done via direct DB connection. it'd be so wasteful to include everyone just to discuss simple CRUD+some custom actions :(.
Basically my policy in the office right now is, does it need to face consumers? If so, API to whatever frontend. Otherwise, HTMX. We had success with a HTMX frontend for an internal tool that took a fraction of the time that fiddling with vanilla JS would require. There’s new caveats like we didn’t have the best organisation of our components and pages in that one off project but the same trouble comes with using React. (As for why not the consumer facing side, there’s a chance we’ll need to change that dramatically but the underlying business logic stays pretty much the same)
Need a video on how you can approach complex form validations with this approach? Complex form validations felt so horrible with htmx when i last tried it as it lead to a lot of sphegetti code handling form validation states for each element
Thanks a lot for content like this! You are one of the few, who post content about replacing frontend frameworks to server rendering without worsening user experience, thanks, please continue!
But this will fire several API requests. One for fetching IDs and then separate request for each ID. In "cool" javascript frameworks for example you can do all of that in one request: fetch the IDs and returns initial html and then stream down the data for each graph. One request vs potentially 10 requests. This is the argument js defenders make for using "cool" javascript frameworks.
@@ivantarjan7360 Sure but that request will be bulky and much slower. The power of streaming approach is that you send the data for individual chart to a client as soon as it is available as opposed to waiting for the data for all the charts to be fetched and send it back at once.
@@ivantarjan7360 Yeah, definitely. But, need to write a lot of code to accomplish that (both on the client and the server). Now image you need the same functionality in 100 endpoints. Having framework take care of all of that would be nice. Also, this is not limited to javascript either. You can do this in Blazor out of the box for example.
also loving how simple the backend code looks. how is db package imported and used without instantiating the service, connection etc the whole mumbo-jumbo?
"No Anthony, this is slow, makes several unnecessary requests and does not scale" This is usually the argument of JS framework fanboys. Every JS framework fanboy argues as if every application being built out there is at the level of Facebook or Instagram, yet the truth is many of us in our lifetime will never build an application for more than 100K users.
To be fair, that very argument, that we'll likely never encounter TRUE scale, could be used to say that we should go ahead and use the big clunky js frameworks so long as shipping to vercel remains the route with the highest dev velocity. The main benefit I see to using Go or something even faster on the backend is for saving costs in both scenarios: You can buy a weaker VPS and get the same results at the small scale, and then you will obviously ALSO save money once you move to something that's charge per compute.
I love your content! Wow, I've learned so much about Go thanks to your full application examples. However, could you add more zoom? A lot of us consume your content from mobile devices. 😁
I agree, often the problem is the entire ecosystem. The dispute vanilla js vs frameworks is often pointless as the big elephant in the room is no touched. Instead you could generate your html on the server.
This is really great but I think it would be possible to avoid an individual request for every card, still using just HTMX. Put the hx-get for /marketplace/trade on the _container_ of the trade cards, now sending back the whole array of id's, and then return the whole list of loaded cards and swap out the loading ones all at the same time. I care less about multiple requests to the server than I do _multiple requests to the database_
Thanks a lot for the great content Anthony! In levenue, do you have a view with a table with many rows that needs sorting/filtering? If so, how do you handle this?
What do you think about maragudk/gomponents ? I have been using that instead of templ because I like being able to write everything in 100% go. I'm curious what you think about it.
yes, gomponents are much better as you can fetch inside the gomponents and do all the go stuff inside the function, which is not possible with templ. The only down side is ugly syntax
thanks Anthony! i'm looking forward for the framework asap! i've kinda a boilerplate at the moment with GO/templ/htmx/tailwindcss/hyperscript(opt-in) that works fine, similarly to framework like nextjs it automatically detects routes using the file in the pages folder and other stuff, it's kinda primitive but i believe that is the HTMX time
Lol he is literally showing how he is building an actual real world product with this stack. A lot of people wouldn’t even do that and would just show you some shallow todo app or something. Yet it’s still not enough apparently 🤦🏻♂️
![ทุกครั้งที่หลับตา (Lucid Dream) - AYLA's [ Official MV ]](http://i.ytimg.com/vi/4i1OBAQyv58/mqdefault.jpg)
this simplicity is incredible, similar to good old times, rendering pure html, loving it. A breath of fresh air.
just yesterday spent 1,5h in a meeting about redesigning a frontend application. the redesign supposed to happen with simultaneous switch to a new design system.
but the new design system is still in progress and their timeline to finish is Q2 next year.
so we gonna do a redesign but with old design system. and then migrate to a new design system later at some point.
this is the burden of huge corps. so frustrating.
even for a simple admin-ui change you need involve frontend people and discuss how things gonna look like, which data backend API supposed to provide.
I guess only during that meeting alone you'd probably have already functioning CRUD UI based on htmx.
I wanna try htmx for our apps just as a hidden ui for internal team usage to simplify certain tasks like maintenance that otherwise would need to be done via direct DB connection. it'd be so wasteful to include everyone just to discuss simple CRUD+some custom actions :(.
Basically my policy in the office right now is, does it need to face consumers? If so, API to whatever frontend. Otherwise, HTMX. We had success with a HTMX frontend for an internal tool that took a fraction of the time that fiddling with vanilla JS would require. There’s new caveats like we didn’t have the best organisation of our components and pages in that one off project but the same trouble comes with using React.
(As for why not the consumer facing side, there’s a chance we’ll need to change that dramatically but the underlying business logic stays pretty much the same)
I also use HTMX with Go to build my app. I never did any JavaScript or web dev before and I'm really happy with my decision of not using react
Need a video on how you can approach complex form validations with this approach? Complex form validations felt so horrible with htmx when i last tried it as it lead to a lot of sphegetti code handling form validation states for each element
Thanks a lot for content like this! You are one of the few, who post content about replacing frontend frameworks to server rendering without worsening user experience, thanks, please continue!
But this will fire several API requests. One for fetching IDs and then separate request for each ID. In "cool" javascript frameworks for example you can do all of that in one request: fetch the IDs and returns initial html and then stream down the data for each graph. One request vs potentially 10 requests. This is the argument js defenders make for using "cool" javascript frameworks.
You can make an endpoint in the API that receives de ids as query params to do a bulk fetch, turning it into two requests to API and db instead of 10
@@ivantarjan7360 Sure but that request will be bulky and much slower. The power of streaming approach is that you send the data for individual chart to a client as soon as it is available as opposed to waiting for the data for all the charts to be fetched and send it back at once.
@@IvanRandomDude true, in that case you could use the goroutines to send server side events every time a query returns the data
@@ivantarjan7360 Yeah, definitely. But, need to write a lot of code to accomplish that (both on the client and the server). Now image you need the same functionality in 100 endpoints. Having framework take care of all of that would be nice. Also, this is not limited to javascript either. You can do this in Blazor out of the box for example.
Yes
How you are creating the line chart without js? Most of the example I have seen is using some js
"want to build with a small amount of people" 100% - I love this video - thank you
also loving how simple the backend code looks.
how is db package imported and used without instantiating the service, connection etc the whole mumbo-jumbo?
"No Anthony, this is slow, makes several unnecessary requests and does not scale" This is usually the argument of JS framework fanboys. Every JS framework fanboy argues as if every application being built out there is at the level of Facebook or Instagram, yet the truth is many of us in our lifetime will never build an application for more than 100K users.
To be fair, that very argument, that we'll likely never encounter TRUE scale, could be used to say that we should go ahead and use the big clunky js frameworks so long as shipping to vercel remains the route with the highest dev velocity.
The main benefit I see to using Go or something even faster on the backend is for saving costs in both scenarios: You can buy a weaker VPS and get the same results at the small scale, and then you will obviously ALSO save money once you move to something that's charge per compute.
I love your content! Wow, I've learned so much about Go thanks to your full application examples. However, could you add more zoom? A lot of us consume your content from mobile devices. 😁
I agree, often the problem is the entire ecosystem. The dispute vanilla js vs frameworks is often pointless as the big elephant in the room is no touched. Instead you could generate your html on the server.
This is really great but I think it would be possible to avoid an individual request for every card, still using just HTMX. Put the hx-get for /marketplace/trade on the _container_ of the trade cards, now sending back the whole array of id's, and then return the whole list of loaded cards and swap out the loading ones all at the same time. I care less about multiple requests to the server than I do _multiple requests to the database_
I hope that browsers support natively what HTMX does. It should be already supported by them.
really nice. tried using that stack once but was to painful. skill issue? yes
No skill issue. Its just not documented properly
you look good brother. Really really enjoy your truthfulness. What type of headpohones do you use please?
How about saving settings like filter in the URL?
Thanks a lot for the great content Anthony! In levenue, do you have a view with a table with many rows that needs sorting/filtering? If so, how do you handle this?
What do you think about maragudk/gomponents ? I have been using that instead of templ because I like being able to write everything in 100% go. I'm curious what you think about it.
Gomponents is better. Much simpler. No special proxy compiler and LSP
yes, gomponents are much better as you can fetch inside the gomponents and do all the go stuff inside the function, which is not possible with templ. The only down side is ugly syntax
Hi Anthony! How did you create these charts?
thanks Anthony! i'm looking forward for the framework asap! i've kinda a boilerplate at the moment with GO/templ/htmx/tailwindcss/hyperscript(opt-in) that works fine, similarly to framework like nextjs it automatically detects routes using the file in the pages folder and other stuff, it's kinda primitive but i believe that is the HTMX time
Could you share the code?
I think it's a great solution for startups
making goth framework? hell yeah
What is the point of always streaming and never sharing the Github repos???
In cant share this repo or I go to jail
@@anthonygg_ htmx is a controlled substance. be careful
@@anthonygg_ 🤣🤣
Lol he is literally showing how he is building an actual real world product with this stack. A lot of people wouldn’t even do that and would just show you some shallow todo app or something. Yet it’s still not enough apparently 🤦🏻♂️
@@anthonygg_ lock him up
very cool! how are you creating those plots?
That's my question too, lol
this is probably the go-echarts library
chartjs?!
pretty much the standard!
thanks for teaching sir love from India ❤
damn, so beautiful!
So true JS is a nightmare ecosystem
more htmx
What is the coupon code for 60% off on fulltimegodev?