We human can learn any complexity. React is not as complex. Typing and IDE help is more valuable in the long run. Until there is vscode extension to help with stringly typed htmx I cannot take it seriously
I love that you mention the "Representational" part of "Representational State Transfer." I've been lingering on and really enjoying that aspect of HTMX's philosophy. HTML responses are a representation of the state of the application on the server that the browser automatically understands. JSOn is not representative of anything to the browser and requires some interpretation by a developer. It's so nice to have a library that doesn't require the recreation of state on the client side and I feel like using it will simplify the entire process of making an app.
Something to mention is that you can configure your API to serve both HTML responses AND JSON responses by the accept header using the exact same end point. This allows you to serve both HTMX clients and JS based clients if needed.
But if you have an API serving many clients you wouldn't want to enforce HTML logic on them (e.g stripe/X/Insta/...). It would be great if there was something like GraphQL where you could also define the HTML response in some form of pedantic models.
@@KodapsAcademy I meant if your different API consumers want to use HTMX. Even though you can respond in either JSON/HTML you cant respond in slightly different variations of html to satisfy the different client needs.
@@clearthinking5441 One can add new mime types, such as application\htmx, if one wanted to serve both html and htmx. The interesting thing is that it allows one to incrementally upgrade to htmx from an existing html based UI. I'm currently upgrading a legacy XML based web application (SOAP) to HTMX and we're using this approach to allow for mixed and incremental prod release.
@@KodapsAcademy BTW thank you for producing this video. We used it at work to inform us on our decision to use HTMX on our aging legacy system. Something I haven't seen talked about is how well suited HTMX is for adding dynamic behaviour to legacy systems with minimal risk compared to a full rewrite using React.js. It seems that this maybe the niche role that HTMX can fill.
HTMX also greatly reduces the complexity of an application. So, it is good to reach out for it until you actually really need a lot of state on your front end and I mean a lot. I use MPAs for my offline first applications in JavaScript and it greatly reduces the complexity of my applications, I use an HTMX-like library when I need a little more interactivity. I haven't needed to resort to using a true front end library yet as this paradigm works very well and reduces complexity.
The complexity of front end apps usually comes from state management and many people working on the same project. I don't see how htmx would help with either
JSF with PrimeFaces has been doing something similar for a very long time...including the ability to target DOM items to be updated using selectors. The advantage of HTMX, however, is that it is agnostic of the backend producing the HMTL response, whereas JSF is obviously tied to Java.
First of all. Really enjoying your channel. Thank you for the work put in here for us all. After giving HTMX a lot of thought for a large project and weighing up against JS frameworks like React, Qwik, Solid etc, I decided to go with Qwik. Reason being I need something very app-like with a lot of interactivity. Everything in Qwik is pretty much lazy loaded (which feels a lot like HTMX in a weird way). Equally, I can use React components if I need to with it. Not saying my solution is right for everyone, just sharing my experience. If I was going to build a monolithic, almost static but with a modern browser SPA feel, I would use HTMX like you mention.
You can actually get a significant amount of interactivity with HTMX with much less complexity. But if you are already familiar with React then it makes sense to go that route. It's just a different paradigm and takes time to get used to.
Excellent video and analysis recently I jumped to learn HTMX to experiment, as a web developer i like to try latests technologies to stay relevant and adopt new techniques, but defenetely hate some JS frameworks approach, also things like tailwind CSS that just overcomplicate things, leave you with non-starndard practices and bloated code unecessary costs in project sizes, love the htmx approach, also tryed libraries like AlpineJS wich takes this html first approach, but what I would love to see and I imagine that is posible is to fetch JSON data and parse it with HTMX because there is tons if not the big mayority of APIs out there work in JSON, so implement HTMX in this way require also rewrite a ton of already made APIs
To see how it was I recently started developing some projects using htmx / PHP with Mustache. At the moment I'm finding it a great combo that still maintains SOC.
Great take. Anti-js is the wrong phrase though, it's not "anti" at all, js becomes instead something of a null. Like when Don Draper said, matter-of-factly: "I don't think about you at all."
Yeah I don’t see it as anti-js I see the other frameworks as anti-html and anti-web. HTMX not abusing js to make it do everything doesn’t really make it “anti” javascript it’s just using it more properly.
JavaScript frameworks were mostly invented to be able to deal with a great deal of client side complexity, like what Facebook is doing. But this qualifies as a need in only less than 1% of all the projects ever made (because no one "else" is Facebook). So for most, removing client side complexity saves a lot of trouble and hussle, and avoid all that JS nonsense that keep on piling up over the years
Great vid. We're still using mvc and jstl/jsp and it can drive me insane nested if/else statements (anyone who knows the syntax will understand). When it makes sense, I prefer to do the logic in the backend and set variables with the required information in the response so the info just goes splat in the page. HTMX could be beneficial for us.
Ive never used htmx but all those html properties that refer to *other* html elements that need updating (independent of each other even?), reeks like spaghetti code to me Very well explained ! Thanks
I don't buy the comment about not learning another language. I feel like HTMX like JSX is not HTML and you need to build on top of what you traditionally know.
If we use an old template engine in our application today. Is it simple to just add the tags to it and implement logic on server side or does the template engine need to have support for the technology? I was thinking of old JSP in java world. Because then it will allow for a more easier way to replace the template engine.
Referring to the button example, even with htmx you would need to check if the user is allowed to press the button twice: 1) when generating the html response, 2) when executing the underlying action. That is for security reasons. Nevertheless, both tests can be written in the same language and even be implemented by the same library function. My next big project will probably involve both htmx and Go. Given my set of skills, I view it as possibly the best fit for a financial web application.
The only problem I see here is the frontend development workflow of translating the UX comp into runnable html files in the browser that other frontenders/UX/backenders are able to update and integrate into their scope of responsibilities. Like how would a UX guy request that a backender to continuously update the markup residing on the server side? A lot of at stake here - development workflow, CI/CD, responsiveness and accessibility, among others..
That is a very good point, I think it only works either if 1/ the HTML has no styling and the styling and layout are implemented based on the context (e.g. the parent CSS class) or more likely 2/ the HTML response is basically a view (e.g. via a templating language) where the backend controller provides the data but the front end dev still defines the layout sent to a client, as we would do on any other view. Option 1 might be a bit optimistic but option 2 is basically how pages are made anyway in a PHP/RoR/Python context
My only problem with this is what if my APi serves multiple clients? Now each client needs to use a different API version. Unless you set it up so the client can ask for a certain data format, so GET /api/v1/user.json would return a JSON output while GET /api/v1/user.html would give you the HTML. It's a big ask for existing applications. I'm also struggling to understand how you'd style your HTML or use packages that offer complex behavior like select2. Now I have to introduce those attributes to my HTML on the server? I guess the other approach would be to... post-process my HTML in JavaScript, which entirely defeats the purpose. Gotta look into this a bit more.
Make sens, probably not always cost efficient to run everything server side though. I imagine business logic on front end would probably still be needed in case of use of websocket or p2p.
Great video very interesting. I’m currently wrestling with what tech stack to use for a client app with a web front end but a golang backend. I don’t mean a remote backend though as the app I’m building is local only. I recently discovered htmx and thought wow this is great because it now mean theoretically I can build the front and backend all in golang with the help of wails and stitched together with htmx. But then I discovered shadcn/radix/tailwind/aceternity, which requires react. What I would like to know is if it is possible to use htmx with react? The server part of my app would normally run on the same machine as the client, but it doesn’t have to, could be another machine in the same network. So could we htmx with react in this scenario?
So... old school programmers that use C/C++ for example are more fitted as a back-end part of the equation. So HTMX seems to be a good fit for someone that did C applications and wants to expand their scope of new ways to GUI with their application. Cool :)
The problem with both React/Next and HTMX is that it's stupid and wasteful to put more of the burden on the server than necessary. The beauty of real client-side business logic is that it's a distributed computing system, with the client machine doing a lot of the heavy lifting. Companies are starting to realize that cloud computing just OBSCURES the source of cost and burden in services, so that they grow out of control. So for a while, server-side's inefficiency was hidden. But they can't afford to keep doing that. The amount of data you send back and forth, the amount of work you do server side, should be only the amount that security and bandwidth require. Anything beyond that should be left to the client, which will almost always make the experience better for everyone. Less server burden, and faster response for the user.
I never understood HTMX till now, I just had to sub and wondering if I could get any recommendations on where I could start learning more about HTMX I have a childish queriucity about staff
why does web application are split in two parts? so static assets could be downloaded at the beginning, and user could start interaction using tini-tiny jsons. Even with client side valiation. And even this way, it fricking takes all time for stupid form sumbission when you are on bad wifi or crappy 3g. Good luck with round trip when the whole form is sended back-n-forth because of one stupid input. Banks are created for customer suffering, htmx completelly fullfils this purpose.
I used to use a php framework called QCodo. It was very similar to this in terms of how you code I code most of stuff in php but a lot less javascript code. It was 2010
@@rzyr htmx just adds this same directive syntax in templates just like php and every backend framework 20 years ago, then react appeared to fix this mess 10 years ago, and now 10 years later htmx appears with same old stuff and kids think it’s smth new, well react was created for a reason and soon when you’ll need to scale and support your htmx frontend you’ll understand.
@@buc991there is something called SPA, have you heard of this thing? You can implement that in htmx. Can you tell me which framework using their templating engines have implemented that in the past? So, I think there is also another thing which you don't know about, it's called user experience because of which developers implement SPAs.
There have been server driven frameworks for forever, but this is very cool to focus on individual elements instead of the whole page. How the heck has no one thought of this before? Also, HTMX seems like a much better solution than WASM for most use cases.
well, strictly speaking ... this is nothing new. 15 years ago, you could write an html-returning server in ... assembler if you want and use either jquery or manual ajax to replace part of the page, delivering an "spa" experience. the new thing here is just how convenient and super-easy it is now with htmx. this should work fine for all applications that do not have super-high-frequency state changes (like arcade games). and i guess it will mainstream quickly. the client-side-js scene is to blame for this development - they just stretched it too far with complexity through the roof and megabytes of crap required on the client to do anything. htmx will just deliver tiny amounts of data, with super-fast rendering as the browsers are extremely good at html processing these days.
Client vs server is purely a matter of user experience, not security. You put the same checks in place on the server and never trust the client either way.
True you definitely can But that definitely adds complexity, you add the same checks in both backend and frontend code, you need to build an API interface, and you need to manage state in 2 places (front and backend) and make sure they stay in sync. HTMX does away with all of that and reduces complexity by a lot. Which might make sense for a lot of web-applications.
I like what HTMX brings to the table. We still only have form POSTs. HTMX should become the new HTML. UX-wise it's a step back from what you can do with single page apps. It's not just less complexity, it's less complexity at the expense of end users. I'm just not interested in lowering the bar on that front.
@@n4bb12 depends on the application, if most or all state changes require communication with a backend, which is the case in a lot of webapps especially content focussed sites, it doesn’t really matter much and barely impacts user experience, and using htmx doesn’t mean you can’t sprinkle in little bits of JS where it makes sense. Obviously it doesn’t make sense in highly dynamic applications
I'm not 100% sure because its been a while since I installed it and VS Code doesn't make it very clear which theme is currently active, but I think its Luvia marketplace.visualstudio.com/items?itemName=maciekkoks.luvia-theme
Calling it htm when it is still just more js... what's next phx that attempts to turn js into php... oh wait no all the "backend" js bullshit already tried doing that and made half the "webapps" a nightmare to use. This shit is turning into using a nuke for pest control. Can't we just use the appropriate tool for the job instead of trying to make things that just add layers upon layers of failure points and unnecessary load to things. I don't need a framework to animate a button and I don't need jquery to send a request to an api, guess what js does that out the box. As developer and sysadmin I see this so often. The djano js pm2 docker nonsense is 500mb and takes up half the system resources for something I can do in php and html in 200kb stuffed into nginx running for tens of thousands requests per minute. Stop re-inventing the wheel and pour the effort into making the right tool better instead.
so you're just moving all the logic to the server/client and htmx/css is just for structure and styling. i don't think backend dudes want to mess with frontend state logic, but i could be wrong.
so bassically, "just drop whatever slow in the backend and switch to faster language, as whatever heavyload you usually done in the frontend is now your backend's problem"
It's not at all about performance, in fact I don't think I mentioned performance once :) What I did say was that web applications live on a spectrum, and that applications with a lot of interactions that can trust their customers should run on the client, whereas those with real world implications that can't trust their customers should live on the server.
Htmx is perfect for people who just learn frontend, imho. i mean react just too much for now. Wanna learn react? here next documentation because cra was deprecated for some reason.
The real value of this is the simplicity. it removes ALL THAT CRAZY REACT COMPLEXITY! No need for it, so nice.
ah yes, now you finally can make your own fansy ui components from scratch.
We human can learn any complexity. React is not as complex. Typing and IDE help is more valuable in the long run. Until there is vscode extension to help with stringly typed htmx I cannot take it seriously
I love that you mention the "Representational" part of "Representational State Transfer." I've been lingering on and really enjoying that aspect of HTMX's philosophy. HTML responses are a representation of the state of the application on the server that the browser automatically understands. JSOn is not representative of anything to the browser and requires some interpretation by a developer.
It's so nice to have a library that doesn't require the recreation of state on the client side and I feel like using it will simplify the entire process of making an app.
Something to mention is that you can configure your API to serve both HTML responses AND JSON responses by the accept header using the exact same end point. This allows you to serve both HTMX clients and JS based clients if needed.
But if you have an API serving many clients you wouldn't want to enforce HTML logic on them (e.g stripe/X/Insta/...). It would be great if there was something like GraphQL where you could also define the HTML response in some form of pedantic models.
You don’t need to enforce html on anyone, you can defaut to json and only serve html when it is specified in the accept headers
@@KodapsAcademy I meant if your different API consumers want to use HTMX. Even though you can respond in either JSON/HTML you cant respond in slightly different variations of html to satisfy the different client needs.
@@clearthinking5441 One can add new mime types, such as application\htmx, if one wanted to serve both html and htmx. The interesting thing is that it allows one to incrementally upgrade to htmx from an existing html based UI. I'm currently upgrading a legacy XML based web application (SOAP) to HTMX and we're using this approach to allow for mixed and incremental prod release.
@@KodapsAcademy BTW thank you for producing this video. We used it at work to inform us on our decision to use HTMX on our aging legacy system. Something I haven't seen talked about is how well suited HTMX is for adding dynamic behaviour to legacy systems with minimal risk compared to a full rewrite using React.js. It seems that this maybe the niche role that HTMX can fill.
hx-select is for a different use, you should use hx-target for replacing the content of element with the response
Good point, and thanks for pointing it out :)
This is the first short video I’ve watched that succinctly covers how htmx works. Start here.
First step to use the anti js framework: import a js file
You give very quotable descriptions, sir. I'm gonna have to watch this video again to quote you on my study notes.
Wow, thanks :)
1 minute in and I'm sold. Definitely trying this out when I get the chance.
Aah, and at 5:40 you've explained why I like this concept so much.
Best HTMX fast explanation i`ve seen ultil now, and more rich information. Thanks for your efforts to explain us :-)
Thanks, I’m glad you liked it, and I’m glad to be of service :)
HTMX also greatly reduces the complexity of an application. So, it is good to reach out for it until you actually really need a lot of state on your front end and I mean a lot. I use MPAs for my offline first applications in JavaScript and it greatly reduces the complexity of my applications, I use an HTMX-like library when I need a little more interactivity. I haven't needed to resort to using a true front end library yet as this paradigm works very well and reduces complexity.
The complexity of front end apps usually comes from state management and many people working on the same project. I don't see how htmx would help with either
If complexity exists indeed, it cannot be reduced; just moved to another place.
JSF with PrimeFaces has been doing something similar for a very long time...including the ability to target DOM items to be updated using selectors. The advantage of HTMX, however, is that it is agnostic of the backend producing the HMTL response, whereas JSF is obviously tied to Java.
All that is old is new again, we've been doing this for many decades but now it's cool again.
Online gambling games have all their state on the server. The front ends are completely dumb. HTMX looks awesome.
You are gonna become huge man , you have gold content ❤
Thank you very much :)
Humble, on point, informative explanation. I drank your words, great job :).
Best video on htmx so far
Wow, thanks for the kind words, I'm glad I was able to be helpful :)
First of all. Really enjoying your channel. Thank you for the work put in here for us all.
After giving HTMX a lot of thought for a large project and weighing up against JS frameworks like React, Qwik, Solid etc, I decided to go with Qwik.
Reason being I need something very app-like with a lot of interactivity. Everything in Qwik is pretty much lazy loaded (which feels a lot like HTMX in a weird way).
Equally, I can use React components if I need to with it. Not saying my solution is right for everyone, just sharing my experience. If I was going to build a monolithic, almost static but with a modern browser SPA feel, I would use HTMX like you mention.
Astro would also be a good choice for a mostly static website :)
You can actually get a significant amount of interactivity with HTMX with much less complexity. But if you are already familiar with React then it makes sense to go that route. It's just a different paradigm and takes time to get used to.
Also, Marko is another JavaScript based library that is pretty lightweight.
This video was extremely well made and I really enjoyed it! Please keep up the amazing content. I just subscribed.
What a great intro. This is exactly what I was looking for!
Probably the best Htmx explanation I have seen. Congrats! It's a pity the "bug" on the hx-select instead of hx-target attribute.
Excellent video and analysis recently I jumped to learn HTMX to experiment, as a web developer i like to try latests technologies to stay relevant and adopt new techniques, but defenetely hate some JS frameworks approach, also things like tailwind CSS that just overcomplicate things, leave you with non-starndard practices and bloated code unecessary costs in project sizes, love the htmx approach, also tryed libraries like AlpineJS wich takes this html first approach, but what I would love to see and I imagine that is posible is to fetch JSON data and parse it with HTMX because there is tons if not the big mayority of APIs out there work in JSON, so implement HTMX in this way require also rewrite a ton of already made APIs
I like your comparison illustration on Banks vs Arcade Games as analogy! Nice explanation
Very concise. I like how you seem unbiased and are pragmatic about it. subbed
Thanks for the kind words :)
To see how it was I recently started developing some projects using htmx / PHP with Mustache. At the moment I'm finding it a great combo that still maintains SOC.
I love your style. Black background and in your face videos. Also great content.
Thanks :)
Great take. Anti-js is the wrong phrase though, it's not "anti" at all, js becomes instead something of a null. Like when Don Draper said, matter-of-factly: "I don't think about you at all."
It's more of an anti - (js framework), in the sense that it does the opposite of what a framework does :)
Yeah I don’t see it as anti-js I see the other frameworks as anti-html and anti-web. HTMX not abusing js to make it do everything doesn’t really make it “anti” javascript it’s just using it more properly.
Probably the best Htmx explanation. So an instant subscription to your channel.
JavaScript frameworks were mostly invented to be able to deal with a great deal of client side complexity, like what Facebook is doing. But this qualifies as a need in only less than 1% of all the projects ever made (because no one "else" is Facebook). So for most, removing client side complexity saves a lot of trouble and hussle, and avoid all that JS nonsense that keep on piling up over the years
Great channel. You really do a good job explaining all these new frameworks for me. Thx man!
Simply brilliantly explained, thank you. I want to ask you what do you use to draw in your videos?
I use Excalidraw to create diagrams and Presentify to draw on screen :)
this video is surprisingly well done!
Great video! Front end dev here but might want to give HTMX a shot now
Great vid. We're still using mvc and jstl/jsp and it can drive me insane nested if/else statements (anyone who knows the syntax will understand). When it makes sense, I prefer to do the logic in the backend and set variables with the required information in the response so the info just goes splat in the page. HTMX could be beneficial for us.
Htmx is like php where we return html response to render in UI. We cycled back from the beginning 😅
htmx is great for even the most complex projects
Great stuff..... this is such a total loop... back to the future of 2005... and it's a very good move. no more unstable JS madness!
Ive never used htmx but all those html properties that refer to *other* html elements that need updating (independent of each other even?), reeks like spaghetti code to me
Very well explained ! Thanks
wonderfully presented. thank you
So we have to have two APIs, one HTMX for web and another JSON for other interfaces like Android, Swift, Java Desktop, ... I don't see it.
I don't buy the comment about not learning another language. I feel like HTMX like JSX is not HTML and you need to build on top of what you traditionally know.
If we use an old template engine in our application today. Is it simple to just add the tags to it and implement logic on server side or does the template engine need to have support for the technology? I was thinking of old JSP in java world. Because then it will allow for a more easier way to replace the template engine.
HTMX is blind to the server side templating engine, as long as your server responds in valid HTML you are good to go :)
With htmx my web application lives another day without having to implement a JavaScript build step to the deployment.
The beauty of HTMX
Referring to the button example, even with htmx you would need to check if the user is allowed to press the button twice: 1) when generating the html response, 2) when executing the underlying action. That is for security reasons.
Nevertheless, both tests can be written in the same language and even be implemented by the same library function.
My next big project will probably involve both htmx and Go. Given my set of skills, I view it as possibly the best fit for a financial web application.
Great vid! Your style is great. Any htmx tutorials coming???
Great explanation!
Thanks, glad you liked it :)
This reminds me of 2006 with improvements
The only problem I see here is the frontend development workflow of translating the UX comp into runnable html files in the browser that other frontenders/UX/backenders are able to update and integrate into their scope of responsibilities. Like how would a UX guy request that a backender to continuously update the markup residing on the server side? A lot of at stake here - development workflow, CI/CD, responsiveness and accessibility, among others..
That is a very good point, I think it only works either if 1/ the HTML has no styling and the styling and layout are implemented based on the context (e.g. the parent CSS class) or more likely 2/ the HTML response is basically a view (e.g. via a templating language) where the backend controller provides the data but the front end dev still defines the layout sent to a client, as we would do on any other view. Option 1 might be a bit optimistic but option 2 is basically how pages are made anyway in a PHP/RoR/Python context
Can't the HTMX url's be local file url's? for example an html file updating itself, or a locally stored help message that gets shown on a click?
excellent explain
My only problem with this is what if my APi serves multiple clients? Now each client needs to use a different API version. Unless you set it up so the client can ask for a certain data format, so GET /api/v1/user.json would return a JSON output while GET /api/v1/user.html would give you the HTML.
It's a big ask for existing applications. I'm also struggling to understand how you'd style your HTML or use packages that offer complex behavior like select2. Now I have to introduce those attributes to my HTML on the server? I guess the other approach would be to... post-process my HTML in JavaScript, which entirely defeats the purpose. Gotta look into this a bit more.
Great video, thank you!
Make sens, probably not always cost efficient to run everything server side though. I imagine business logic on front end would probably still be needed in case of use of websocket or p2p.
Maybe, there are plugins that handle websockets and server side events
You use hx-select, when I’ve only ever used hx-target! any idea what the difference is? Can’t figure it out
Great video very interesting. I’m currently wrestling with what tech stack to use for a client app with a web front end but a golang backend. I don’t mean a remote backend though as the app I’m building is local only. I recently discovered htmx and thought wow this is great because it now mean theoretically I can build the front and backend all in golang with the help of wails and stitched together with htmx. But then I discovered shadcn/radix/tailwind/aceternity, which requires react. What I would like to know is if it is possible to use htmx with react? The server part of my app would normally run on the same machine as the client, but it doesn’t have to, could be another machine in the same network. So could we htmx with react in this scenario?
Such a great video!
So... old school programmers that use C/C++ for example are more fitted as a back-end part of the equation. So HTMX seems to be a good fit for someone that did C applications and wants to expand their scope of new ways to GUI with their application. Cool :)
Loved the video thank you sir.
The problem with both React/Next and HTMX is that it's stupid and wasteful to put more of the burden on the server than necessary.
The beauty of real client-side business logic is that it's a distributed computing system, with the client machine doing a lot of the heavy lifting.
Companies are starting to realize that cloud computing just OBSCURES the source of cost and burden in services, so that they grow out of control. So for a while, server-side's inefficiency was hidden.
But they can't afford to keep doing that.
The amount of data you send back and forth, the amount of work you do server side, should be only the amount that security and bandwidth require. Anything beyond that should be left to the client, which will almost always make the experience better for everyone. Less server burden, and faster response for the user.
Easy to understand. Thank you
I’m glad it was helpful !
Every time I see HTMX my brain automatically jumps to XHTML
React + HTMX Hybrid for the win. Survival instinct is gonna kick in!
We did this in 2006 when I started my first dev job. Everything somehow is repeating.
ITs like desktop application develo and I love it
I never understood HTMX till now, I just had to sub and wondering if I could get any recommendations on where I could start learning more about HTMX I have a childish queriucity about staff
Hello
I know HTML and CSS
should I learn JS to understand HTMX
or not?
No, although it is a JS library you don’t need to learn JS to use it
@@KodapsAcademy Thanks for fast reply
Glad to be of service :)
why does web application are split in two parts? so static assets could be downloaded at the beginning, and user could start interaction using tini-tiny jsons. Even with client side valiation. And even this way, it fricking takes all time for stupid form sumbission when you are on bad wifi or crappy 3g. Good luck with round trip when the whole form is sended back-n-forth because of one stupid input. Banks are created for customer suffering, htmx completelly fullfils this purpose.
I used to use a php framework called QCodo. It was very similar to this in terms of how you code I code most of stuff in php but a lot less javascript code. It was 2010
Excellent video.
Thanks :)
so now, with htmx, backend devs should "draw" all ui components and know how they behave in browsers?
Nope, you’re missing the point. Html is being used to communicate the state, not the style of the UI
Nicely summed up
how can we handle http errors using htmx?🤔
We are backing to ASP?
Great video!
hi there, is it ok to use the graph at minute 6? for training purposes
If you mean the bank vs. arcade game one, no problem :)
I use htmx in ritail and warehousing in real world! Damn... how cool I am
Brilliant explanation!!
Thanks :)
Thankyou
Really good explanation
thanks :)
It's a good thing for old programmers that still hate js. Let them make hypertext-driven REST APIs and create the living hell.
Old programmers have too much of a react brain to get ised to this. Htmx is for the new, nonconformist ones
@@rzyrif you think 'old' mean react, you're young.
@@rzyr htmx just adds this same directive syntax in templates just like php and every backend framework 20 years ago, then react appeared to fix this mess 10 years ago, and now 10 years later htmx appears with same old stuff and kids think it’s smth new, well react was created for a reason and soon when you’ll need to scale and support your htmx frontend you’ll understand.
I have seen people using React on the server side to prerender contents to HTML and respond it for HTMX, that’s so hilarious.
@@buc991there is something called SPA, have you heard of this thing? You can implement that in htmx. Can you tell me which framework using their templating engines have implemented that in the past? So, I think there is also another thing which you don't know about, it's called user experience because of which developers implement SPAs.
There have been server driven frameworks for forever, but this is very cool to focus on individual elements instead of the whole page. How the heck has no one thought of this before?
Also, HTMX seems like a much better solution than WASM for most use cases.
very good explanation and content. Downside: too many annoying animation and transition effects going back and forth, hurting the eye!
Great value. Htmx sounds great.
I like HTMX
In a different video someone else mentioned that htmx is great for something like php.
For any serverside language, really, but yeah definitely PHP :)
well, strictly speaking ... this is nothing new. 15 years ago, you could write an html-returning server in ... assembler if you want and use either jquery or manual ajax to replace part of the page, delivering an "spa" experience. the new thing here is just how convenient and super-easy it is now with htmx. this should work fine for all applications that do not have super-high-frequency state changes (like arcade games). and i guess it will mainstream quickly. the client-side-js scene is to blame for this development - they just stretched it too far with complexity through the roof and megabytes of crap required on the client to do anything. htmx will just deliver tiny amounts of data, with super-fast rendering as the browsers are extremely good at html processing these days.
Client vs server is purely a matter of user experience, not security. You put the same checks in place on the server and never trust the client either way.
True you definitely can
But that definitely adds complexity, you add the same checks in both backend and frontend code, you need to build an API interface, and you need to manage state in 2 places (front and backend) and make sure they stay in sync.
HTMX does away with all of that and reduces complexity by a lot. Which might make sense for a lot of web-applications.
I like what HTMX brings to the table. We still only have form POSTs. HTMX should become the new HTML.
UX-wise it's a step back from what you can do with single page apps. It's not just less complexity, it's less complexity at the expense of end users. I'm just not interested in lowering the bar on that front.
@@n4bb12 depends on the application, if most or all state changes require communication with a backend, which is the case in a lot of webapps especially content focussed sites, it doesn’t really matter much and barely impacts user experience, and using htmx doesn’t mean you can’t sprinkle in little bits of JS where it makes sense. Obviously it doesn’t make sense in highly dynamic applications
HTMX baby, wow
How is this different from the approach blazor has?
its not made by microsoft
I am trying to use Axum Rust server + HTMX for my website.
Most of my experience is on the front end; however I'm kind of sick of it. I've been trying to do more on the back end.
So, it is the anti Express framework?
Its backend wont work at all with mobile apps
Which theme do you use in your code editor?
I'm not 100% sure because its been a while since I installed it and VS Code doesn't make it very clear which theme is currently active, but I think its Luvia marketplace.visualstudio.com/items?itemName=maciekkoks.luvia-theme
Calling it htm when it is still just more js... what's next phx that attempts to turn js into php... oh wait no all the "backend" js bullshit already tried doing that and made half the "webapps" a nightmare to use. This shit is turning into using a nuke for pest control. Can't we just use the appropriate tool for the job instead of trying to make things that just add layers upon layers of failure points and unnecessary load to things. I don't need a framework to animate a button and I don't need jquery to send a request to an api, guess what js does that out the box. As developer and sysadmin I see this so often. The djano js pm2 docker nonsense is 500mb and takes up half the system resources for something I can do in php and html in 200kb stuffed into nginx running for tens of thousands requests per minute. Stop re-inventing the wheel and pour the effort into making the right tool better instead.
so you're just moving all the logic to the server/client and htmx/css is just for structure and styling. i don't think backend dudes want to mess with frontend state logic, but i could be wrong.
Stuff like Dark mode or opened/closed state can stay on the client, the “HTMX way” concerns business logic not really pure UI state :)
so bassically, "just drop whatever slow in the backend and switch to faster language, as whatever heavyload you usually done in the frontend is now your backend's problem"
It's not at all about performance, in fact I don't think I mentioned performance once :) What I did say was that web applications live on a spectrum, and that applications with a lot of interactions that can trust their customers should run on the client, whereas those with real world implications that can't trust their customers should live on the server.
Htmx is perfect for people who just learn frontend, imho. i mean react just too much for now. Wanna learn react? here next documentation because cra was deprecated for some reason.
Does HTMX provide reactive values?
If you mean in reaction to something the server responds with, yes.
Aren’t APIs that can support various clients more robust, rather than having an API that only supports browsers that run HTML?
An API that respects the Accept Header can allow for both HTML and JSON. It doesn’t have to be either or :)
@@KodapsAcademy Good point 😄
Great vid had to sub 🤷♂
Welcome aboard :)
great video.