I'm trying to do research on how to build a full stack app with HTMX. I'm just now learning to try and build a website. I thought that the t3 stack / React would be the way to go, but I'm glad I kept looking before starting to learn React. This seems like such a better tool to build out a reactive front end to essentially connect users to data in a database. The searching function is slick and looks easy to implement. Whenever I learn more about HTMX, I think it's the way I want to build out the website. I'm subscribing in hopes that a tutorial for a full-fledged app, with auth and a DB, is made soon!
I've been building out a side project using HTMX and GO which has been amazing. I am a very traditional FED, and being able to get something to the screen so quickly has been a dream. I am still a little slow with it, but I encourage everyone to give it a try. Its a great tool to solve problems with very little overhead.
@@pavelstastny7892 I definitely will. I have some code for it and I'll publish it possibly next week or the week after. When I do I hope you'll tell your HTMX+Alpine friends (or just any friend) to get the word out!
@@ThanHtutZaw3 Correct. I compared it to React but there is no React in the HTMX example I showed. The only JavaScript that I wrote in the example is the Astro code and it runs only on the server. You could replace that with Go, as an example, and then the only JS code at all would be the HTMX library on the client that implements the hx-* attributes.
Thanks Papa Jack. HTMX is going to disrupt literally every major framework. I already converted 2 internal sites to HTMX and everyone is amazed at how fast we can build with it!
I started making web pages back in 1998 with Netscape Navigator but hadn't done any development until starting to learn to code two years ago. HTMX feels like it is where web dev should have gone from where it was in the 90's vs something like React or the other frameworks I've been learning up until now and your videos have been a huge help! I watched the video you did with Jason and am in the middle of an Astro/HTMX/Supabase project now which has been easier than building in React for my app. Is Astro the best compliment for HTMX in your view?
If you want to write your server in JS/TS then yes, Astro is the way to go. But you can use any server pairing with HTMX. You could use Go, Rust, Python/Django, etc. anything that serves HTTP.
also java spring-boot is an option for back-end. REST Api calls gives total control@@jherr really good job advocating and spreading cutting-edge tools frameworks .Thanks Sr , keep make us sharper
Great overview. My first impression is it looks like declarative jQuery. A decade ago this partial HTML approach was how I’d make my PHP & jQuery site dynamic. Have there been any patterns from React that are difficult to recreate with HTMX? I notice there’s no loading spinners or concept of suspense. Having small partial HTML payloads would help make this quick, but if you’re on say airport wifi the wait is likely longer and you probably want some cue to show the user.
This was just a taste. There is hx-indicator for spinners. Basically htmx is 99% about AJAX stuff. So it's not going to handle hiding/showing the hamburger menu. For that folks seem to either hand code it or use Alpine.
@@PatrickGWSmith I would like to think that such simple things could be declarative. There is the new accordion, maybe that has some built-in behaviors. My guess is that web platform purists would say there are Web Components for such things.
@@PatrickGWSmith Browsers can do that already: Either with the and tags, or, if you want to connect it to the hash value, use a link with a hash and css with :target. You can also (mis)use radio buttons or checkboxes and CSS like .trigger:checked ~ .target.
Worked on an old React codebase and got rebuked by the complexity that it can introduce. Feels good to see stuff like HTMX. I feel AlpineJS deserve some love too. When it comes to API similar to React to me Solid is the best.
I strongly disagree with the statement 'React is fantastic for a large project.' It's quite the opposite. React can be challenging for large projects, and a much better option is HTMX. Choosing HTMX can significantly reduce complexity. Just stick with HTMX and skip React; you'll sleep soundly at night. Let the React die-hards dig themselves into a large hole of complexity while you bring your product to market faster with a simpler tech stack like HTMX. I am still puzzled as to why some developers are still sticking to SPAs such as React and Angular; maybe it's for legacy applications. However, for new applications, I think it's wise to skip all these unnecessary meta-stacks. It's like avoiding junk food. Anyways, great video.
I agree. I'm working now on a really large react codebase (this app could actually be split into multiple products and they still would be big). Complexity is skyrocketing, managing state is terrible. And performance issues... Oh boy. Loading times, bundle sizes, rerenders, watching out for references so the hooks wont render a million times, etc. React seems like it could scale well, but it's the opposite. I've never worked on a HTMX app this size. I still feel like you could introduce a lot of mess (for example no clear way how to organize partials/components). But I see that it could potentially reduce complexity and scale well. We'll see. As a mostly FE dev I'm looking forward to HTMX.
Agreed. React, at the end of the day, was built for the UI and state of a single page. I'd mostly only use it for something like a dashboard with lots of things changing in one view in response to user input. In which case, you could also use regular JS or other smaller, simpler frameworks.
Ok, points taken. I would love to hear more about what you've experienced in large React apps that has made them unmaintainable. Huge singleton Redux stores? useEffects run amok?
Those size comparisons feel iffy to me and at least deserve some context. That initial load may well have an excellent ROI: 1) How much bandwidth to interact with the same, say, 30 "pages" in one 'session'? 1b) Tangentially, whats the cpu cost difference? Crowdsourcing your ui rendering makes a difference. 2) How much for future sessions? Often times large libs can be hashed and aggressively cached so over the course of a month (typical business app) i'd expect the delta to be pretty large 3) The big frameworks got the memo and are looking at things like code splitting/deferred loading as well. Whats the delta once they all have some kind of 'micro kernel'?
#1 would be wildly different based on the type of app. Also, you might be leaving off the table the impact of a CDN here. Some types of requests can be CDN cached and that would reduce CPU loads on the server and give that "crowdsourcing" effect. #2 Regardless of caching these libraries still need to be parsed on loading. In addition HTMX doesn't have the hydration hit that React (etc.) have. #3 Certainly the JS frameworks are getting smaller, and the apps are getting smaller because of compilers. But that's not happening with React at the moment. I'm a React fan. I'm in the middle of creating a course on NextJS. I like it. But I also think that it works well for certain types of apps and is over-powered for others. So it's good to have different tools for different types of apps.
@@jherr I'm not sure how serving data is ever more expensive than serving data surrounded by markup once you ignore that initial load. The question is, do you ever get your roi? If the users are on the internet and hit 3 pages? Probably not. A data heavy business app used all day? Almost certainly. You can't just compare 2 page loads.
@@adambickford8720 Sure, but two can play the argument in the extremes game. What is the ROI of NextJS in a completely static CMS site with large content pages (e.g. a news site). The pages are literally twice the size they need to be because of the serialized DOM (sent unconditionally even when built and even when entirely static). And you get the ~150K of React/Next infra code. And that code does run on every page load and stalls JS's single thread (and browser interactivity) in hydration. In this specific case NextJS is not a good choice. There is no single best system for developing web sites and applications. Each systems makes trade-offs which make it more or less suitable to specific purposes. But the existence of one approach doesn't obviate the need for any other approaches. We didn't give up on nails and hammers when we got screws. Different requirements, different tools.
@@jherrThats my point, actually. I'm not sure what you're even arguing against? I'm not championing any specific tech or frameworks, they all have pros and cons. But this idea of comparing server vs client side rendering payloads isn't as simple as loading a single page and making a conclusion. My entire point was to consider the context and not just conclude in absolutes.
@@adambickford8720 Fair enough. It is a rough measure to be sure. I'm just not sure what a more fair comparison I could do in a similar amount of time would be. That being said, my point, which I clearly did not communicate well, was that isomorphic JS frameworks (e.g. React/Next, Vue/Nuxt, etc.) primarily communicate with the server using JSON (or VDOM in the case of Next/RSC) and that the client JS size would scale with the size of the application (and yes, lazy rendering, code splitting, etc.) Where HTMX communicates between the client and the server using HTML and the size of the JS is fixed.
Then use React, or Vue, or ... That's actually one of the nice things about Astro in particular is that you can add React support with one command then create a React component and drop it into the page to provide that kind of dynamic behavior as well.
JS/TS application server. You need to have a server to be able to demonstrate HTMX since HTMX extends the functionality of the server. This channels viewership is primarily JS/TS programmers, so I chose a JS/TS application server. You can use whatever kind of server you want with HTMX.
In SEO terms it's SSR'ed. The server renders the initial page. Then if you use hx- to get more content that is fetched from the server that returns it as HTML, and the HTMX JS does the work of taking that HTML and updating the current page with the contents.
You could use dhadcn with this. The interactive components would need to be marked as client islands, or be within client islands. But you can render shadcn all you want if you bring in React or Preact into your Astro project.
interesting @@jherr the only negative part I see with island mode is the isolation between astro language (server) with client (react, preact): i8n, global state... Maybe with astro+qwik it handle better.
@@electroheadfx I don't think Qwik handles that part of it any better. Not that Qwik isn't cool, it really is. But it would still be an island element even though it would do resumability thing.
@@statuschannel8572 i disagree, the app was written way back 2015 and its getting larger and larger and its not easy to migrate to latest versions because our users dictates priorities.
So to make a simple counter you have to store the count state in the server and each time it increments a get request has to be made to the server? 😑😑 What kind of a very efficient server is that
Correct me if I'm wrong, but the way I understood it was that you send the counter value to the server and the server increments it and send the incremented value back to the page. So the "state" management is not on the server. I mean if you really need a 'state' you can also use local or session storage I guess.
figured it out by swapping the whole form with the new value count then retrieve it via post an increment it can I just swap the input tag? because I can't seem to figure it out
With NextJS the result in terms of JS download size would be about the same. The vast majority of the download size is the React core which goes to the client, RSCs or not, to support hydration and rendering.
@@jherr thank you for your answer. I tend to see FE apps as standalone apps that are separate from any BE. In your example you use Astro and htmx in this context feels just like a template engine. Can't yet see how can it live outside of BE but I guess documentation covers it.
@@metamodern7648 So in that model what does the BE server do? Is it JSON API server? If so, no, that doesn't really fit in this model unless it's behind the Astro|Go|Django|Rust|PHP server instead of something like a database. You need to shift your thinking entirely out of the backend produces JSON, frontend consumes JSON model. This is not that.
@@jherr in that model BE is usually an nginx or apache server that just serves the FE app. And the FE app sends requests to any other BE service. Sometimes it uses its own nginx as proxy if architecture requires it for example. So, no my mindset is not json communication between be and fe, it's the opposite, with less boundaries. If FE app doesn't need a server (like a simple local storage todo) then it only gets served with nginx in prod deployment(and usually there's a build stage where you produce index.html and rest of js). That's what I meant in my previous comment, that with your example using astro it's hard to see a standalone htmx app. Maybe it's just because I'm very far from technology and I should just try:)
@@metamodern7648 Yeah, I would recommend just trying it. I'm not sure what you mean by when you say what you are proposing isn't JSON, it's the opposite. I guess I'm also a little confused because none of this has anything to do with nginx or what environment stuff is deployed in. HTMX is simply a library you can drop into any page that looks for these hx- attributes and when triggered it will make a fetch call to the endpoint you specify (wherever that is), get the HTML and then it will merge it into whatever target you want it to go into.
i get bored that there are too much things. everyday new hs library inventing although already there are too much. i hate frontend thing because of this.
React is fantastic for small projects but for large projects, you might want to use something like HTMX: a very simple way to not send 2MB of Javascript to all your users.
sorry for being so harsh in this opinion, but this obfuscate the power of HTMX because one of the great things it does is to reduce your JS footprint to almost none, but you used Astro and things get confused, it would have been better if you use something else as a backend to show examples.
@@jherr Good point, in that case I'm not sure HTMX is be the best choice. Anyhow, following the spirit of the author, it doesn't matter what language you choose for your backend.
@@DAEMonRaco So the language behind HTMX doesn't matter as long as it's NOT JavaScript/TypeScript? I'm so confused. Is your point that I should have used Go? Because HTMX is really a way for Go devs to not have to learn JS?
@@jherr I'm not saying you can't use JS or TS, you totally can, but it illustrate it better if you choose a different language for your backend. Golang is a great choice, but as far as I understand Python is great too. Or any other for that matter. Again, I'm not against JS or TS, but mixing them, for someone starting with HTMX, could blur the lines where something is, in this case Astro, and when it's HTMX doing its thing.
@@DAEMonRaco But we aren't actually mixing client/server JS/TS here, actually. In this example the JS we write only runs on the server. We don't write any client side JS, we use the htmx markup. The only JS on the client is HTMX and all we are doing is adding an astro integration to add that to the page.
For videos like this it's why I stopped watching this guy, and I was one of his earliest subscribers. Using a framework on top another for a basic showcase. Always following the latest shiny new toy of FE. This just highlights what's wrong with FE nowadays.
The thing about teaching HTMX is that HTMX is an extension of your server. So you have to have a server to demonstrate it. It's not like React where you can teach the fundamentals with components in JS. You have to have a server, since the server is 80% of the equation. HTMX is just the glue that binds the client closer to the server. And Astro seems like the logical choice since it's JS-based, which is most of what the viewers of this channel know. And it's a remarkably simple server where the components use a JSX style, which again, is what most folks know.
Absolutely fantastic! I'd love to see a tutorial for a full-fledged app, with Auth and a DB!
Yes please!! You'll be the first one!
th-cam.com/video/cpzowDDJj24/w-d-xo.htmlsi=ww6c6eOw8D7Fh8RB is a great one that dives into auth, DB, and a full app using Bun!
I'm trying to do research on how to build a full stack app with HTMX. I'm just now learning to try and build a website. I thought that the t3 stack / React would be the way to go, but I'm glad I kept looking before starting to learn React. This seems like such a better tool to build out a reactive front end to essentially connect users to data in a database. The searching function is slick and looks easy to implement. Whenever I learn more about HTMX, I think it's the way I want to build out the website.
I'm subscribing in hopes that a tutorial for a full-fledged app, with auth and a DB, is made soon!
Yes, I'd love to see the fullstack LoB app with astro, htmx, orm, auth, midleware, logger, etc. can stack together.
I've been building out a side project using HTMX and GO which has been amazing. I am a very traditional FED, and being able to get something to the screen so quickly has been a dream. I am still a little slow with it, but I encourage everyone to give it a try. Its a great tool to solve problems with very little overhead.
What is FED? 😮
front end devoloper?
@@recursion. Yes front-end developer
Even nicer if you mix htmx with a good templeate engine like a-h/templ.😊
Nah, you’re clearly a BED
Once I got comfortable with Go, Templ and HTMX, I cry everytime when I have to go back to React
A lot has been written in the comments about the alpine + htmx combination. And I was very interested to see this
why pay for components while shit is free
For someone who has no experience with this stuff, I've struck gold finding this video. Thank you!
Used htmx with Astro and Alpine.js and it's a blast! Love this stack ❤
Yeah, if this video does well and there is a lot of interest I'll follow up with Alpine. They are a great pairing.
Yes, please do.
@@pavelstastny7892 I definitely will. I have some code for it and I'll publish it possibly next week or the week after. When I do I hope you'll tell your HTMX+Alpine friends (or just any friend) to get the word out!
I am confusing . So this stack doesn't need React ?
@@ThanHtutZaw3 Correct. I compared it to React but there is no React in the HTMX example I showed. The only JavaScript that I wrote in the example is the Astro code and it runs only on the server. You could replace that with Go, as an example, and then the only JS code at all would be the HTMX library on the client that implements the hx-* attributes.
Thanks Papa Jack. HTMX is going to disrupt literally every major framework. I already converted 2 internal sites to HTMX and everyone is amazed at how fast we can build with it!
htmx is for all the backend devs who hate frontend
Hi Jack, first contact with that and, wow, so simple, so right, I'm going to learn more about it. Thanks for the content. It was a great lesson
I'd like to see a full enterprise app with auth and all that stuff using HTMX
IMHO, it's not designed for that.
Wow.! Interesting.!
i was wondering when the nextjs course is going to be launched.?
Working on it right now!
I started making web pages back in 1998 with Netscape Navigator but hadn't done any development until starting to learn to code two years ago. HTMX feels like it is where web dev should have gone from where it was in the 90's vs something like React or the other frameworks I've been learning up until now and your videos have been a huge help! I watched the video you did with Jason and am in the middle of an Astro/HTMX/Supabase project now which has been easier than building in React for my app. Is Astro the best compliment for HTMX in your view?
If you want to write your server in JS/TS then yes, Astro is the way to go. But you can use any server pairing with HTMX. You could use Go, Rust, Python/Django, etc. anything that serves HTTP.
@@jherr Go / HTMX seems like a powerful combo too but I haven’t learned Go yet. :)
also java spring-boot is an option for back-end. REST Api calls gives total control@@jherr really good job advocating and spreading cutting-edge tools frameworks .Thanks Sr , keep make us sharper
Great overview. My first impression is it looks like declarative jQuery. A decade ago this partial HTML approach was how I’d make my PHP & jQuery site dynamic.
Have there been any patterns from React that are difficult to recreate with HTMX? I notice there’s no loading spinners or concept of suspense. Having small partial HTML payloads would help make this quick, but if you’re on say airport wifi the wait is likely longer and you probably want some cue to show the user.
This was just a taste. There is hx-indicator for spinners. Basically htmx is 99% about AJAX stuff. So it's not going to handle hiding/showing the hamburger menu. For that folks seem to either hand code it or use Alpine.
@@jherr I’m hoping browsers get more and more powerful so that hiding/showing is something that can be done with HTML & CSS!
@@PatrickGWSmith I would like to think that such simple things could be declarative. There is the new accordion, maybe that has some built-in behaviors. My guess is that web platform purists would say there are Web Components for such things.
@@PatrickGWSmith Browsers can do that already: Either with the and tags, or, if you want to connect it to the hash value, use a link with a hash and css with :target. You can also (mis)use radio buttons or checkboxes and CSS like .trigger:checked ~ .target.
Worked on an old React codebase and got rebuked by the complexity that it can introduce. Feels good to see stuff like HTMX.
I feel AlpineJS deserve some love too.
When it comes to API similar to React to me Solid is the best.
I’m full tilt curious about this now I’m going to play with it now!
Astro mentioned lets gooo 🚀
with htmx/alpine video please, thanks, its a new area with astro now !
For entry level flask/django its helpfull for me to develop frontend
I strongly disagree with the statement 'React is fantastic for a large project.' It's quite the opposite. React can be challenging for large projects, and a much better option is HTMX. Choosing HTMX can significantly reduce complexity. Just stick with HTMX and skip React; you'll sleep soundly at night. Let the React die-hards dig themselves into a large hole of complexity while you bring your product to market faster with a simpler tech stack like HTMX. I am still puzzled as to why some developers are still sticking to SPAs such as React and Angular; maybe it's for legacy applications. However, for new applications, I think it's wise to skip all these unnecessary meta-stacks. It's like avoiding junk food. Anyways, great video.
Yeah. React is for simple projects. Does not scale!
I agree. I'm working now on a really large react codebase (this app could actually be split into multiple products and they still would be big). Complexity is skyrocketing, managing state is terrible. And performance issues... Oh boy. Loading times, bundle sizes, rerenders, watching out for references so the hooks wont render a million times, etc. React seems like it could scale well, but it's the opposite.
I've never worked on a HTMX app this size. I still feel like you could introduce a lot of mess (for example no clear way how to organize partials/components). But I see that it could potentially reduce complexity and scale well. We'll see. As a mostly FE dev I'm looking forward to HTMX.
Agreed. React, at the end of the day, was built for the UI and state of a single page. I'd mostly only use it for something like a dashboard with lots of things changing in one view in response to user input. In which case, you could also use regular JS or other smaller, simpler frameworks.
Ok, points taken. I would love to hear more about what you've experienced in large React apps that has made them unmaintainable. Huge singleton Redux stores? useEffects run amok?
My company maintains a massive in-house React UI library for consistent UX across 1000's of deployed apps. How would you accomplish this with HTMX?
Reminds me of how I used to work with beloved jQuery
Those size comparisons feel iffy to me and at least deserve some context. That initial load may well have an excellent ROI:
1) How much bandwidth to interact with the same, say, 30 "pages" in one 'session'?
1b) Tangentially, whats the cpu cost difference? Crowdsourcing your ui rendering makes a difference.
2) How much for future sessions? Often times large libs can be hashed and aggressively cached so over the course of a month (typical business app) i'd expect the delta to be pretty large
3) The big frameworks got the memo and are looking at things like code splitting/deferred loading as well. Whats the delta once they all have some kind of 'micro kernel'?
#1 would be wildly different based on the type of app. Also, you might be leaving off the table the impact of a CDN here. Some types of requests can be CDN cached and that would reduce CPU loads on the server and give that "crowdsourcing" effect.
#2 Regardless of caching these libraries still need to be parsed on loading. In addition HTMX doesn't have the hydration hit that React (etc.) have.
#3 Certainly the JS frameworks are getting smaller, and the apps are getting smaller because of compilers. But that's not happening with React at the moment.
I'm a React fan. I'm in the middle of creating a course on NextJS. I like it. But I also think that it works well for certain types of apps and is over-powered for others. So it's good to have different tools for different types of apps.
@@jherr I'm not sure how serving data is ever more expensive than serving data surrounded by markup once you ignore that initial load. The question is, do you ever get your roi?
If the users are on the internet and hit 3 pages? Probably not. A data heavy business app used all day? Almost certainly. You can't just compare 2 page loads.
@@adambickford8720 Sure, but two can play the argument in the extremes game. What is the ROI of NextJS in a completely static CMS site with large content pages (e.g. a news site). The pages are literally twice the size they need to be because of the serialized DOM (sent unconditionally even when built and even when entirely static). And you get the ~150K of React/Next infra code. And that code does run on every page load and stalls JS's single thread (and browser interactivity) in hydration. In this specific case NextJS is not a good choice.
There is no single best system for developing web sites and applications. Each systems makes trade-offs which make it more or less suitable to specific purposes. But the existence of one approach doesn't obviate the need for any other approaches. We didn't give up on nails and hammers when we got screws. Different requirements, different tools.
@@jherrThats my point, actually. I'm not sure what you're even arguing against?
I'm not championing any specific tech or frameworks, they all have pros and cons. But this idea of comparing server vs client side rendering payloads isn't as simple as loading a single page and making a conclusion. My entire point was to consider the context and not just conclude in absolutes.
@@adambickford8720 Fair enough. It is a rough measure to be sure. I'm just not sure what a more fair comparison I could do in a similar amount of time would be. That being said, my point, which I clearly did not communicate well, was that isomorphic JS frameworks (e.g. React/Next, Vue/Nuxt, etc.) primarily communicate with the server using JSON (or VDOM in the case of Next/RSC) and that the client JS size would scale with the size of the application (and yes, lazy rendering, code splitting, etc.) Where HTMX communicates between the client and the server using HTML and the size of the JS is fixed.
Yay, maybe next alpine?
Yeah. CHAD
AlpineJS+HTMX work so well together
@@lagcisco yup, astro(ts)+htmx+alpine+tailwind is so powerful stack
bro, for large projects also htmx.
Superb stuff!
Nice I use angular and if I would do what will do in htmx in angular I Ned more than 2 our and alot of file but htmx be good for larger scale project
7:18 Why isn't the div on line 9 showing when count > 0? Are the some hidden logic here?
What should i add when it needs more clientside complicated features? Something like drag and drop or realtime spredsheets or grid tables?
Then use React, or Vue, or ... That's actually one of the nice things about Astro in particular is that you can add React support with one command then create a React component and drop it into the page to provide that kind of dynamic behavior as well.
Hrm. My first question - what is "Astro"?
JS/TS application server. You need to have a server to be able to demonstrate HTMX since HTMX extends the functionality of the server. This channels viewership is primarily JS/TS programmers, so I chose a JS/TS application server. You can use whatever kind of server you want with HTMX.
I am newbie
Can I use Ant Design in htmx?
Ant Design is a React library as far as I know it. And that's not going to be super compatible with HTMX, no.
Just a quick question: Eagar to know if this HTMLX renders like SPA or a server-rendered HTML??. POV: SEO
In SEO terms it's SSR'ed. The server renders the initial page. Then if you use hx- to get more content that is fetched from the server that returns it as HTML, and the HTMX JS does the work of taking that HTML and updating the current page with the contents.
The only issue with this stack is that I can't use shadcn-ui without react ?
You could use dhadcn with this. The interactive components would need to be marked as client islands, or be within client islands. But you can render shadcn all you want if you bring in React or Preact into your Astro project.
interesting @@jherr the only negative part I see with island mode is the isolation between astro language (server) with client (react, preact): i8n, global state... Maybe with astro+qwik it handle better.
@@electroheadfx I don't think Qwik handles that part of it any better. Not that Qwik isn't cool, it really is. But it would still be an island element even though it would do resumability thing.
We have react app deployed in and users are complaining that they need at least 10 seconds just to display the page
skill issue! don't blame the tool if a page takes 10 seconds to load!
@@statuschannel8572 i disagree, the app was written way back 2015 and its getting larger and larger and its not easy to migrate to latest versions because our users dictates priorities.
So to make a simple counter you have to store the count state in the server and each time it increments a get request has to be made to the server? 😑😑 What kind of a very efficient server is that
Correct me if I'm wrong, but the way I understood it was that you send the counter value to the server and the server increments it and send the incremented value back to the page. So the "state" management is not on the server. I mean if you really need a 'state' you can also use local or session storage I guess.
Nice!
Can someone please tell that if it is possible to make the counter example without global variable, and if it is possible to make then how?
figured it out by swapping the whole form with the new value count then retrieve it via post an increment it
can I just swap the input tag? because I can't seem to figure it out
If there a reason why swapping out the whole form isn't working?
@@jherr yeah I figured it out after I commented and thank you for replying, great video gave me a good preview of htmx
what is that font?
Probably JetBrains Mono.
Isn't react server components a fairer one-to-one comparison to htmx?
With NextJS the result in terms of JS download size would be about the same. The vast majority of the download size is the React core which goes to the client, RSCs or not, to support hydration and rendering.
@@jherr My bad, you're right
Why is there a feeling that such simple technology won't be able to handle large applications?
That's a great quesiton. That hasn't always been the case. I don't really know why folks seem to expect a level of technology. Simple stuff works.
@@jherr thank you for your answer. I tend to see FE apps as standalone apps that are separate from any BE. In your example you use Astro and htmx in this context feels just like a template engine. Can't yet see how can it live outside of BE but I guess documentation covers it.
@@metamodern7648 So in that model what does the BE server do? Is it JSON API server? If so, no, that doesn't really fit in this model unless it's behind the Astro|Go|Django|Rust|PHP server instead of something like a database. You need to shift your thinking entirely out of the backend produces JSON, frontend consumes JSON model. This is not that.
@@jherr in that model BE is usually an nginx or apache server that just serves the FE app. And the FE app sends requests to any other BE service. Sometimes it uses its own nginx as proxy if architecture requires it for example. So, no my mindset is not json communication between be and fe, it's the opposite, with less boundaries. If FE app doesn't need a server (like a simple local storage todo) then it only gets served with nginx in prod deployment(and usually there's a build stage where you produce index.html and rest of js).
That's what I meant in my previous comment, that with your example using astro it's hard to see a standalone htmx app. Maybe it's just because I'm very far from technology and I should just try:)
@@metamodern7648 Yeah, I would recommend just trying it. I'm not sure what you mean by when you say what you are proposing isn't JSON, it's the opposite. I guess I'm also a little confused because none of this has anything to do with nginx or what environment stuff is deployed in. HTMX is simply a library you can drop into any page that looks for these hx- attributes and when triggered it will make a fetch call to the endpoint you specify (wherever that is), get the HTML and then it will merge it into whatever target you want it to go into.
i get bored that there are too much things. everyday new hs library inventing although already there are too much. i hate frontend thing because of this.
Back to jQuery and PHP 😂
React is fantastic for small projects but for large projects, you might want to use something like HTMX: a very simple way to not send 2MB of Javascript to all your users.
You can also use HTMX for large projects. Tooling is dumb. HTMX is from 2013, so it's not new.
what? 0:01 React is good for large projects?
What? (Skeletor meme)
First like❤🎉
sorry for being so harsh in this opinion, but this obfuscate the power of HTMX because one of the great things it does is to reduce your JS footprint to almost none, but you used Astro and things get confused, it would have been better if you use something else as a backend to show examples.
This channel viewership is primarily JavaScript/TypeScript developers.
@@jherr
Good point, in that case I'm not sure HTMX is be the best choice.
Anyhow, following the spirit of the author, it doesn't matter what language you choose for your backend.
@@DAEMonRaco So the language behind HTMX doesn't matter as long as it's NOT JavaScript/TypeScript? I'm so confused.
Is your point that I should have used Go? Because HTMX is really a way for Go devs to not have to learn JS?
@@jherr
I'm not saying you can't use JS or TS, you totally can, but it illustrate it better if you choose a different language for your backend.
Golang is a great choice, but as far as I understand Python is great too. Or any other for that matter.
Again, I'm not against JS or TS, but mixing them, for someone starting with HTMX, could blur the lines where something is, in this case Astro, and when it's HTMX doing its thing.
@@DAEMonRaco But we aren't actually mixing client/server JS/TS here, actually. In this example the JS we write only runs on the server. We don't write any client side JS, we use the htmx markup. The only JS on the client is HTMX and all we are doing is adding an astro integration to add that to the page.
For videos like this it's why I stopped watching this guy, and I was one of his earliest subscribers. Using a framework on top another for a basic showcase. Always following the latest shiny new toy of FE. This just highlights what's wrong with FE nowadays.
So... instead of Astro what would you have used? Or just nothing at all and not even talk about HTMX?
React sucks! A big workaround disaster
Not sure why you added the astro overhead to this htmx tutorial but ok
Because you can!
Astro is actually amazing especially with alpine
@@JEsterCW exactly
The thing about teaching HTMX is that HTMX is an extension of your server. So you have to have a server to demonstrate it. It's not like React where you can teach the fundamentals with components in JS. You have to have a server, since the server is 80% of the equation. HTMX is just the glue that binds the client closer to the server.
And Astro seems like the logical choice since it's JS-based, which is most of what the viewers of this channel know. And it's a remarkably simple server where the components use a JSX style, which again, is what most folks know.
Astro actually works pretty nice with HTMX. If your backend is typescript, astro seems like a good choice for templating.