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.

The real value of this is the simplicity. it removes ALL THAT CRAZY REACT COMPLEXITY! No need for it, so nice.

@games4us132

3 ай бұрын

ah yes, now you finally can make your own fansy ui components from scratch.

hx-select is for a different use, you should use hx-target for replacing the content of element with the response

@KodapsAcademy

7 ай бұрын

Good point, and thanks for pointing it out :)

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.

@clearthinking5441

5 ай бұрын

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

5 ай бұрын

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

@clearthinking5441

5 ай бұрын

@@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.

@chewbaccarampage

5 ай бұрын

@@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.

@chewbaccarampage

5 ай бұрын

@@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.

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.

@fifty-plus

3 ай бұрын

All that is old is new again, we've been doing this for many decades but now it's cool again.

Great vid! Your style is great. Any htmx tutorials coming???

this video is surprisingly well done!

This video was extremely well made and I really enjoyed it! Please keep up the amazing content. I just subscribed.

You are gonna become huge man , you have gold content ❤

@KodapsAcademy

7 ай бұрын

Thank you very much :)

You give very quotable descriptions, sir. I'm gonna have to watch this video again to quote you on my study notes.

@KodapsAcademy

7 ай бұрын

Wow, thanks :)

What a great intro. This is exactly what I was looking for!

This is the first short video I’ve watched that succinctly covers how htmx works. Start here.

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 channel. You really do a good job explaining all these new frameworks for me. Thx man!

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.

@nickross4059

4 ай бұрын

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

@AlexanderBorshak

4 ай бұрын

If complexity exists indeed, it cannot be reduced; just moved to another place.

Great video! Front end dev here but might want to give HTMX a shot now

Humble, on point, informative explanation. I drank your words, great job :). Best video on htmx so far

@KodapsAcademy

7 ай бұрын

Wow, thanks for the kind words, I'm glad I was able to be helpful :)

Best HTMX fast explanation i`ve seen ultil now, and more rich information. Thanks for your efforts to explain us :-)

@KodapsAcademy

7 ай бұрын

Thanks, I’m glad you liked it, and I’m glad to be of service :)

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.

Online gambling games have all their state on the server. The front ends are completely dumb. HTMX looks awesome.

Probably the best Htmx explanation. So an instant subscription to your channel.

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."

@KodapsAcademy

7 ай бұрын

It's more of an anti - (js framework), in the sense that it does the opposite of what a framework does :)

@darylbarnes9413

7 ай бұрын

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.

Great explanation!

@KodapsAcademy

7 ай бұрын

Thanks, glad you liked it :)

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?

I like your comparison illustration on Banks vs Arcade Games as analogy! Nice explanation

Easy to understand. Thank you

@KodapsAcademy

7 ай бұрын

I’m glad it was helpful !

Very concise. I like how you seem unbiased and are pragmatic about it. subbed

@KodapsAcademy

2 ай бұрын

Thanks for the kind words :)

I love your style. Black background and in your face videos. Also great content.

@KodapsAcademy

4 ай бұрын

Thanks :)

wonderfully presented. thank you

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.

@KodapsAcademy

7 ай бұрын

Astro would also be a good choice for a mostly static website :)

@dovh49

7 ай бұрын

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.

@dovh49

7 ай бұрын

Also, Marko is another JavaScript based library that is pretty lightweight.

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

Which theme do you use in your code editor?

@KodapsAcademy

7 ай бұрын

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

Really good explanation

@KodapsAcademy

7 ай бұрын

thanks :)

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 great for even the most complex projects

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.

@KodapsAcademy

23 күн бұрын

HTMX is blind to the server side templating engine, as long as your server responds in valid HTML you are good to go :)

Every time I see HTMX my brain automatically jumps to XHTML

Brilliant explanation!!

@KodapsAcademy

7 ай бұрын

Thanks :)

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!

Nicely summed up

I have created website thats as complex as facebook with htmx only for my client, the experience and speed is so good and fast

Great value. Htmx sounds great.

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

how can we handle http errors using htmx?🤔

Great video!

wow, thanks for sharing

@KodapsAcademy

7 ай бұрын

Glad to be of service :)

@HuynhLuong227

7 ай бұрын

@@KodapsAcademy keep going, look so cool about htmx

You use hx-select, when I’ve only ever used hx-target! any idea what the difference is? Can’t figure it out

hi there, is it ok to use the graph at minute 6? for training purposes

@KodapsAcademy

2 ай бұрын

If you mean the bank vs. arcade game one, no problem :)

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?

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.

Does HTMX provide reactive values?

@JeffCaldwell-nemo_omen

7 ай бұрын

If you mean in reaction to something the server responds with, yes.

The beauty of HTMX

Htmx is like php where we return html response to render in UI. We cycled back from the beginning 😅

In a different video someone else mentioned that htmx is great for something like php.

@KodapsAcademy

7 ай бұрын

For any serverside language, really, but yeah definitely PHP :)

Great vid had to sub 🤷‍♂

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.

@CristianMolina

7 ай бұрын

Maybe, there are plugins that handle websockets and server side events

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..

@KodapsAcademy

7 ай бұрын

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

excellent explain

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

I am trying to use Axum Rust server + HTMX for my website.

This reminds me of 2006 with improvements

With htmx my web application lives another day without having to implement a JavaScript build step to the deployment.

great video.

How is this different from the approach blazor has?

@user-pl4pz2xn2c

3 ай бұрын

its not made by microsoft

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

HTMX baby, wow

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"

@KodapsAcademy

7 ай бұрын

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.

I believe the server always 'rulled'...but thml pages are more than delivered templates from the server. how do you account for styling ? there will always also be 'hover effects' dropdowns...etc... that live inside the html page....so i dont agree there is no need for javascript....

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.

ITs like desktop application develo and I love it

I've found interest in htmx from both prominent devs in the creator-space + the htmx dev/s themselves (those damn influencers), and I understood the absolute-basics that there was html tags () that control http requests for you...but I didn't realize that the http calls are supposed to return html to the client?!?! What?! I'm a java dev and we use 'REST' in the _traditional_ way where - all of our HTTP requests are essentially ~jSoN~ data wrappers that return data in a nice, beautiful, JSONified object... But storing view data in the server? I DONT GET IT Why should my endpoint return item1item2 as opposed to { {item1}, {item2} } (where these are objects)

@KodapsAcademy

5 ай бұрын

It makes a lot more sense if you think of HTML as a variant of XML :)

React + HTMX Hybrid for the win. Survival instinct is gonna kick in!

Hello I know HTML and CSS should I learn JS to understand HTMX or not?

@KodapsAcademy

3 күн бұрын

No, although it is a JS library you don’t need to learn JS to use it

@user-dh1zd7cq3y

3 күн бұрын

@@KodapsAcademy Thanks for fast reply

@KodapsAcademy

3 күн бұрын

Glad to be of service :)

It's a good thing for old programmers that still hate js. Let them make hypertext-driven REST APIs and create the living hell.

@rzyr

7 ай бұрын

Old programmers have too much of a react brain to get ised to this. Htmx is for the new, nonconformist ones

@adambickford8720

7 ай бұрын

@@rzyrif you think 'old' mean react, you're young.

@buc991

7 ай бұрын

@@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.

@a-yon_n

7 ай бұрын

I have seen people using React on the server side to prerender contents to HTML and respond it for HTMX, that’s so hilarious.

@ammarakrambhutta5273

5 ай бұрын

​@@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.

so now, with htmx, backend devs should "draw" all ui components and know how they behave in browsers?

@KodapsAcademy

3 ай бұрын

Nope, you’re missing the point. Html is being used to communicate the state, not the style of the UI

We are backing to ASP?

good stuff

We did this in 2006 when I started my first dev job. Everything somehow is repeating.

So, it is the anti Express framework?

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.

very good explanation and content. Downside: too many annoying animation and transition effects going back and forth, hurting the eye!

1 > "This is why you could say that (although it is a JavaScript library) HTMX is (in fact) an "anti JavaScript Framework". 2 > A JavaScript framework essentially manages the state on the client and updates the HTML based on that state." I don't agree with either the points. "JavaScript framework essentially manages the state"? No it does not. Quesiton we should ask before saying this is why are we using a "JavaScript framework". In a nutshell we are using it to manipulate UI elements, state management is an implementation detail. Also, state is state either it is in HTML, JSON or even in the URL. If a framework choose to delegate state to backend it does not make it an "anti JavaScript Framework". Saying "JavaScript framework essentially manages the state" because every framework do it is wrong.

@KodapsAcademy

7 ай бұрын

> Saying "JavaScript framework manage the state" because every framework do it is wrong. Sorry I still don't get your objection here ?

i agree but so dived into next right now, can't take it where php was in 2000.

@KodapsAcademy

7 ай бұрын

Next is also a very good choice :)

Aren’t APIs that can support various clients more robust, rather than having an API that only supports browsers that run HTML?

@KodapsAcademy

7 ай бұрын

An API that respects the Accept Header can allow for both HTML and JSON. It doesn’t have to be either or :)

@branislav3800

7 ай бұрын

@@KodapsAcademy Good point 😄

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.

@MrLoggfreak

7 ай бұрын

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.

@n4bb12

7 ай бұрын

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.

@MrLoggfreak

7 ай бұрын

@@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

Make Ajax request and replace content, that is how things where done 20 years ago I guess

Its backend wont work at all with mobile apps

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.

HTMX Router?

@KodapsAcademy

7 ай бұрын

I'm not quite sure I get your question?

@Septumsempra8818

7 ай бұрын

@KodapsAcademy could htmx benefit from a router? Add a caching pattern and we now have a smooth SPA.

@KodapsAcademy

7 ай бұрын

@@Septumsempra8818 HTMX doesn't need to add a router (and it wouldn't fit with the philosophy of the library, I think), it just relies on server-side routing. The Smooth SPA experience is also provided in part by the animations features of HTMX

@Septumsempra8818

7 ай бұрын

@KodapsAcademy I've had two main problems with page loads: 1) I'm struggling with caching and cache invalidation. It's allows pages/app to be more responsive . 2) transitions work well when there is no scroll. Once I scroll down a little htmx scrolls to top and does the view transition, resulting in herky jerky movement. I was assuming that a router can make some of these issues easier?

Here we are again, thin client vs fat server and vice versa.

Great video, although i like htmx philosophy, the json response from the server is 100 x more versatile, nowadays our apps are connected with several servers , and the api makes it just good to connect them together, i can't imagine having to deal with html responses

@KodapsAcademy

7 ай бұрын

The API can send back different formats based on what the Accept header is set to in the request, i.e. Accept: text/html for HTML and Accept: application/json for JSON, for example, so it does not need to be one or the other.

@mehdiyahiacherif2326

7 ай бұрын

@@KodapsAcademy sure , but the API is the standard way to communicate better services nowadays, wjat can i do withan html template response

@KodapsAcademy

7 ай бұрын

@mehdiyahiacherif2326 but if the API responds to the Accept header you don’t need to limit yourself to html, the api can do both. But yeah, granted, other than for HTMX nothing else will consume HTML from an API

So basically HTMX is what PHP was in the past but with a far better DX… I don’t think it’s quite as revolutionary as people are making it out to be.

@KodapsAcademy

7 ай бұрын

It's also better UX, but yeah it's a small library doing a fairly simple thing :)

@chang112x

6 ай бұрын

PHP has livewire, inertia, and much more... so it is far better than htmx

I like HTMX

First step to use the anti js framework: import a js file

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.

@KodapsAcademy

6 ай бұрын

Stuff like Dark mode or opened/closed state can stay on the client, the “HTMX way” concerns business logic not really pure UI state :)

What I don’t like about htmx is how it locks you into web and you can’t use the api for mobile.

@johnyepthomi892

7 ай бұрын

Follow your use case and decide based on it. Use anything that makes sense to you rather than forcing yourself to use something that may be detrimental to your use case.

@user-fr2fm3ri3w

7 ай бұрын

@@johnyepthomi892 I really like swift and flutter after coding in react for a year and I liked how I can make a simple sveltekit project and hook it into a mobile app for extra animations and stuff

@chpsilva

4 ай бұрын

Also, REST endpoints can serve both content types so, win/win ?

How it’s anti js if it’s also js.

@KodapsAcademy

7 ай бұрын

It's not an anti js / framework its anti- / js framework, i.e. it is the opposite of how client side frameworks function

@codyclay88

7 ай бұрын

The way I see it, HTMX is really an “anti-SPA” library, not really “anti-JS”. HTMX is all about driving developers towards a “hypermedia architecture” where the server takes the wheel, as opposed to a “client-server” architecture that we find in SPA apps, where the client does all the driving and really only relies on the server for data.

I've never until now considered htmx to be closer to the HATEOUS objectives than JS libraries. I thinks it's time I stopped observing it from a distance and actually do something with it and reflect later