What the hell is HTMX?

🐦Twitter: / typecraft_dev
If you're unfamiliar with HTMX, then you're not alone. HTMX is a web development library that allows you to create complex, high-performance websites. In this video, we'll give you a brief introduction to HTMX and how it can help you in your web development career.
HTMX is amazing and I think it is the future of web development. If you're interested, check out hypermedia.systems

[@ranarisonluckas9745]

Thanks nerd!

[@albinmiftari1832]

You mean daddy?

[@pappu2185]

​@@albinmiftari1832😢

[@Stefan-bs6ty]

We have adopted htmx a couple of months ago and can confirm that our productivity skyrocketed. I totally agree with your statement "The client should be dumb". "Modern" frontend frameworks add so much complexity that it hurts. The first time you tell people what a browser is actually capable of *besides* JS is always mindblowing.

[@typecraft_dev]

Love it. Can’t wait to dove deeper

[@BodomsScythe]

@@typecraft_dev 🕊

[@CodingWithLewis]

I gotta give HTMX a try. I never realized how much time I wasted doing conditionals in my React code

[@typecraft_dev]

Can’t wait to build something substantial with it!

[@KuroManX]

now you gonna do it on the server

[@adamwarvergeben]

Didn't you make an Video about HTMX a few months ago...?

[@DalpakaNBA]

yooo lewis sup

[@UwU-dx5hu]

What is this clown doing here

[@dreamsofcode]

Nice video, dude! Hyped about htmx. Would love to see more on it ;)

[@typecraft_dev]

Thanks!

[@himurakenshin9875]

Less things to learn on client side and able to try new languages in the backend. Its a win.

[@BlackxesWasTaken]

The funny part is that in order to enhance and achieve the "get back to the roots"-ish behaviour and methods to use html we used JavaScript to build a little library which helps building simple reactive frontends with backends spitting out raw html as it used to back in the day As soon as the complexity of the frontend increases we would still need to get back to writing JavaScript in order to granularly adapt results to the frontend

[@typecraft_dev]

It’s true. But that’s because HTML never added more functionality (for server communication at least) so JS is the easiest way to implement this behavior ironically. BUT this is a far better pattern then the heavy single page apps

[@sleeepey]

This is the best explanation of htmx I have seen, and in under 4 minutes! well done

[@typecraft_dev]

Hey thanks!

[@p07a]

algorithm blessed me with your channel. subscribed. love the quick, to-the-point pace. no more 20 minute videos. thanks nerd!

[@typecraft_dev]

Thank you!

[@hassanaljuboori7620]

I like the fireship style of delivery😂

[@aspiring_millionaire]

Wow! This is the greatest video introduction of what htmx is, it's clear, concise, straight to the point and very fun to watch! referring to your video lol, not htmx :)

[@typecraft_dev]

Thanks!! I had fun making the video

[@JoshMedeski]

Oooo, I’m ready to start exploring this new tool. Thanks for the great explanation!

[@typecraft_dev]

you got it!

[@thepisewigeon]

I really like the way you explain stuff :)) Great vid

[@typecraft_dev]

Glad you liked it!

[@daffy1981]

After having my first JS written in 98' I'm so tired of continuous flow of frameworks, but this one looks a pretty new paradigm. Will need to check out ... (or maybe I still stick to plain HTML5, as there is no silver bullet)

[@hansdietrich1496]

I'd love to see htmx become integrated into HTML6.

[@ansidhe]

This sounds like kids discovering flare jeans 😉😂 but I’m all happy we’ve finally reached this stage 👍🏻 SPAs are all great for their specific functional niches but world would be a much happier place if server-heavy websites and especially internal-use CRUD apps were built using SSR. Not everything needs to be Figma 😉

[@pr.loremarguimaraes7284]

You've just convinced me to take HTMX seriously. Liked, subscribed. Thanks!

[@typecraft_dev]

Welcome aboard!

[@JFromAcc]

Good lord. I just listened to another KZbin video on the same and damn near stabbed myself in the eye. I won't say which one, but this is fantastic. Thank you.

[@joaquinnunezgarcia9279]

In terms of separation of concerns this is going a step back by coupling frontend and bancked work. But if you are not concern about this and want a full stack approach, this is good

[@lolikpof]

For someone who has very little experience with html/css and javascript, what would you recommend learning, if I'm only interested in learning one framework, svelte or htmx? I'm actually a data scientist and mostly use python, but would like to learn one good framework, but only one. Thanks :3

[@typecraft_dev]

If you want something more mainstream go with svelte. If htmx is something that speaks to you, feel free to go there too! HTMX is lighter in concepts than svelt/react/etc…

[@games4us132]

btw how htmx can help with GraphQL or OData apis ? and what about UI libraries? Backend developers should send us fullblown components to swap?

[@VANTYCSolutions]

Awesome! thank you for this information.

[@typecraft_dev]

My pleasure!

[@alivenumber5]

Whew you got me PUMPED on it. Hard agree. The client should be UI interactivity only. In my day job I found myself replicating similar principles in a microcosm of our React framework. We went from sending one large chunk of data to the front and having a heavy front-end to many smaller requests based upon user interactivity. Guess which one was snappier! The idea that we can offload all that data handling to the client is a falsehood when you still need data from the back-end anyways.

[@vectoralphaAI]

I have given up on JavaScript and have switched fully to HTMX. Its so much easier and overall better.

[@thegrumpydeveloper]

I’m wondering how fragments of ui split across front and backend is going to make things easier. Global mutable state causes challenges. Global split mutable state seems even harder. At least with json and apis the two were independent. An api that returns ui coupled to a frontend seems to add more tight coupling. At least conceptually.

[@upsxace]

Not everything is state -_- With HTMX you have an event-based approach, you don't use state.

[@ryanleemartin7758]

It's good old web 1.0 stateless request / response. get->handler-> db call -> html template -> response. post-> json->handler->db update->response. Where's the added global mutable state? I must be missing something.

[@danielhalachev4714]

That's exactly what I'm asking. How do you build a cross-platform system, which has a webpage and a native app for Android/Windows/Linux without Electron and without a REST API returning JSON.

[@ryanleemartin7758]

@@danielhalachev4714 you'd have a json api service for those other clients. It's not about eliminating json apis.. It's about simplifying web clients.

[@elkadiriabdellah1119]

when u using htmx u will get a lot of requests from client to server and those request can atchive that easy by javascript, problem is if u have alot of traffic that will do problem is servuer from requests i guess

[@typecraft_dev]

This video is based on the ebook found here: hypermedia.systems

[@paulstaszko31]

I bought the hardcover book, I really enjoyed reading it and am happy to support the authors. It will be a real trophy on my shelf

[@darkwoodmovies]

I don't think anyone is going to use this directly, but I'm excited to see how React and its derivations use this to improve over time.

[@punkweb]

I use this directly... why the fuck would you use this with react?

[@darkwoodmovies]

@@punkweb "Use this directly" meaning open an html file and start adding your s and stuff with HTMX. I never said use it WITH React. That said, I realize now that this is a library and not a browser-supported technology, which makes my other statement (how React and its derivations can embrace this tech under the hood) irrelevant. So nvm

[@punkweb]

@@darkwoodmovies I think you've missed the point. You don't just start using htmx in an html file. You use it with something like django or php where you're already server rendering html.

[@punkweb]

You set up backend endpoints that return html and use htmx to call them and swap out/in parts of the dom.

[@darkwoodmovies]

@@punkweb Aah I see, hmm interesting. Feels a bit old school but I suppose that's the idea :)

[@joey2545]

Very interested in learning more about HTMX. I work primarily in Rails so I wonder how it compares to Hotwire and if I should try HTMX with Rails?

[@typecraft_dev]

omg I think htmx is perfect with rails

[@Vinylll04]

This will definitely be great for making new custom web apps but that doesn’t mean don’t learn JavaScript and your frameworks since many companies or jobs cannot keep up with these new changes quickly

[@eddyk564]

I don't understand the example you gave. Based on the example, the frontend would make a request to "/users/1" and whatever would be returned would be based on what the backend was designed to return. The "hx-target" is just the element ID that you want to put the data that was returned in, right? How is that any different from using fetch(), getting the data, and then putting it into the HTML?

[@shrin210]

What if you want to change the UI/data in Navbar? Then you need to create a Root state then pass it to the children to update the UI. In this you do not need to any of that and it will directly apply UI to Navbar

[@crispi_shots]

Instead of fetching json data and then parsing it on the client and putting into html You simply retrieve the already built html.

[@eddyk564]

@@shrin210If you want to change the data in the navbar you just type- document.querySelector(#navBar).innerHTML= (and just put what you want it to look like here).

[@eddyk564]

@@crispi_shots Isn't that what the HTML tag is doing anyway with hx-get (or whatever it's called)? It's clearly a request to the backend/server. The hx-target is just the ID of what you're changing.

[@gradycdenton]

If a data API changes then it breaks the front end in a SPA. Your fetching code has to understand the shape of the data it is expected to get back from the endpoint. Either you have full-stack type safety or you have to look up the API documentation. The front end is tightly coupled to the back end. In HTMX, you just fetch the endpoint and display it. Your front end doesn't have to understand anything about the resource on the back end. Since all the buisiness logic is on the back end, you are free to change said logic without breaking the front end. @@eddyk564

[@nanonkay5669]

This is definitely the future

[@typecraft_dev]

I agree!

[@ryanleemartin7758]

Always has been

[@danielhalachev4714]

Although I like the idea, I'm not sure how it's going to work in practice. The current REST API architecture used everywhere has two important benefits - it returns pure data, without any representational characteristics, and this way the API can be used by both web browsers and mobile and desktop apps. If you want to build not just a website, but also a native app without using Electron, you will have to transform the HTML response to pure data. The problem can be solved by still creating a REST API and creating another API on top, which returns HTML, which HTMX can use. But where is the simplicity, which HTMX promised? Another thing, which I don't understand yet is how can you reuse data, returned by the server. Let's say, for one component, for each item you have to add a certain class to the item tag, but for another component you will need a different class. Now what? Build different endpoints in the API or modify the response with JS to add the necessary classes? I haven't researched the technology in detail, so I may be talking nonsense, but that's what's in my mind so far.

[@gofullstack]

If I have my API return HTML doesn't it mean I can no longer use this same API on my mobile/desktop app?

[@typecraft_dev]

You could have different namespaced endpoints for mobile/desktop apps. You could also use hyperview if you want the same hypermedia paradigm. Also HTMX isn't a one-stop solution, I think the idea is to use the simplest tools for the job, whichever job that may be

[@gofullstack]

@@typecraft_dev Gracias

[@danxdev]

​@typecraft_dev so maintain two sets of apis one so that we can use htmx on a website and then another to handle the same data calls for everything else?

[@ascourter]

Great video! htmx is awesome!

[@typecraft_dev]

Thanks I agree. I’ll have to build something with it

[@everyhandletaken]

PWA’s.. it was nice knowing you..

[@autohmae]

Now what to do about offline ? I guess we put the logic in the service worker ? Or maybe it's just not a use case it's trying to solve ?

[@roysupriyo10]

There is absolutely no difference between the JS libraries and htmx. They all use the same dreaded JavaScript. You only write the frontend differently which i would argue that the react or the standard 'framework' setup is more modular and readable as well as easier to maintain because of good organisation. This just looks like another tailwind css library i have to learn to only get limited functionality

[@paulstaszko31]

If you're open to having your mind blown, read the hypermedia systems book. The fact that htmx is written in js is a funny little implementation detail. It should have been done directly in the html spec decades ago.

[@ryanleemartin7758]

That's like saying there's no difference between a studio apartment and a skyscraper.

[@yuhanlian991]

3:20 i have been saying this for so long!

[@typecraft_dev]

Me too!

[@games4us132]

so you basically tell that with htmx now backend developer should know how to design html web pages with paddings, margins, flexboxes and so on?

[@emerelle3535]

I'm also excited about htmx, but not creative enough for coming up with content I could show on a website. :P There is already everything made. :P

[@filthyfrankblack4067]

Now if we could get PHP on the front end we would have come full circle.

[@typecraft_dev]

😂

[@paulstaszko31]

Htmx is the future and the past rolled into one

[@typecraft_dev]

It is my everything

[@enterusername7746]

HTMX is great but falls short for some tasks. For exampe if I want to hide and show a part of my website. It is overhead to male a roundtrip to the server and load the whole part again and again for each toggle.

[@ryanleemartin7758]

Totally but that's where javascript comes in. There's this misconception that if you use htmx then you can't or shouldn't use any javascript at all.

[@AndersBaumann]

I used to think the same thing. But there is actually little overhead in the server roundtrip, and it keeps things very simple. If you need to update multiple places at the same time, then return a larger portion of the screen that includes both places. Very simple and you will be surprised how fast it works. I have implemented a web site with a SPA-feel using this technique. The site has less than 500 lines of JavaScript and they are mostly used for setting up DataTables components.

[@codecaine]

Well explained

[@tim7517]

I'm techincally a Blerd, my ninja

[@Woeden]

Looks amazing, guess i'm fullstack now

[@typecraft_dev]

Hell yeah brother

[@n8o_]

Still waiting to see a live example of this

[@typecraft_dev]

maybe I can help with that!

[@hansdietrich1496]

Looking at this now, I wonder about two things: a) why did it take decades to realize, how all this JS BS can be thrown out of web development again and b) when will these attributes get standardized, so that browsers implement them natively and we even get rid of the last bit JS to make this work?

[@mp6086]

Isn't returning html from the server coupling it was supposed to eliminate? If we decide to change the UI structure, that has to be done in the API, or am I missing something?

[@CYXXYC]

3:28 Caching, where/howto?

[@typecraft_dev]

With the html “cache-control” header. Sorry didn’t go into detail on it in this video

[@Aimsport-video]

Then in 3-years… how do we reduce the massive number of calls to the server?

[@typecraft_dev]

Doesn’t that already happen?

[@Aimsport-video]

@@typecraft_dev not to the fine granularity of UI updates.

[@kahnfatman]

Define free, great, smart... I know JS sucks and being abused but I am truly skeptic and not ready to jump on another techwagon. Good luck guys.

[@typecraft_dev]

I think the great part about htmx is that it isn’t a “tech wagon”. It’s very lightweight and isn’t meant to be used as a framework

[@nickpatella1525]

I don’t think this is what the web needs. Can you stream data with it? Will this not open new vectors for XSS attacks?

[@typecraft_dev]

SPAs are still extremely useful in certain situations (like data streaming, etc...). But for the most part, websites (blogs, stores, etc..) don't need to be SPAs. I'd argue something like htmx is a far easier way to build/maintain those kinds of apps.

[@EDC.EveryDayCode]

Ok u mention data streaming. what i think is nuts is that Steam company uses people's own hardware to store 70Gb games, and this is just normal. I Think that's nuts and I think this is how most pc gamers would do things. What if u want 50-500 games, do they just archive it then redownload b4 they want to play? that seems like a step backwards from disks. lol! I was listening to a programming podcast and apparently it is a very big lift to get games to stream like we do all our video apps. @@typecraft_dev

[@luckrunner]

First of all, avoid the opinions of most JS programmers. Anyone who is not sarcastic will be fundamentally skeptical. They will talk about how HTMX handles JSON, they will say that it is not secure. They will even cite PHP to illustrate that you are using a new templating system. Forget the haters. The thing works, and serves the purpose. The learning curve is small and, unlike other models such as Angular, Vue and React, it requires project planning with another level of maturity. Just as today, immature programmers make fun of PHP (which brought home the bacon for many developers and therefore deserves its place of respect), in the near future JS will be treated like mullets and fanny packs.

[@hammock6871]

Oh cool, someone has reinvented jQuery again

[@skr4u]

after a long time in more than a decade with the mess of react, angulat, vu...... etc... , this HTMLX seems logical

[@fakdapeditz4937]

Yeaaa now implementing my backend projects in web will be much easier

[@typecraft_dev]

Hell yeah brother

[@OM-bs7of]

Htmx cant be used for building standalone apps though, as seen with ionic. There are pros and cons with all technologies. It is important to never disregard any specific technology

[@chrishyde952]

how is the htmx example not equally coupled to the api response, like the js fetch example is?

[@cenkakay3506]

nice framework grandpa

[@typecraft_dev]

Get off my lawn!

[@antinityfx]

i though this was fireship until i heard the voice lol

[@flogzer0]

Daddy rambled about the good old days, skip to 2:30

[@typecraft_dev]

sorry, daddy gets carried away

[@jamelelhadjhamlaoui8753]

why the front should be dumb and we should make everything in the back ?

[@semikolondev]

Makes thinking of the famous "The Thirty-Million Line Problem" so much bloat and layer these days even in the web.

[@typecraft_dev]

True

[@EDC.EveryDayCode]

frontend should be dumb... as I'm learning React 🙄. It probably should be, but there are so many approaches to web dev it's really annoying. Like I've heard u can build sites really fast with Hugo / static site generators... this seems like apple to orange comparison tho. here's some buzzword ideas for your next videos: JSX, XML, AJAX, Wasm, websockets, vue, react when will it end???

[@typecraft_dev]

I agree its confusing. But from my experience. The best applications have the mantra "the frontend should be dumb". Even the best React apps are made better when complexity is taken out of them. Its just a philosophy for web development. But I think its the right approach. (react is great btw)

[@yousef_beta3a]

I thought that Elon musk rebranded html .....

[@typecraft_dev]

😂

[@DavidConnerCodeaholic]

Yeh but this is basically exactly what Angular the JS was supposed to be. Also, what about the WASM? And does the DSL of HTMX limit the expression of logic in the UI? I like HTMX, especially given the it “just works” for things like SEO: no alternate static site req - which is suspect to begin with if your robots know that they’ve landed on “planet namek”

[@Stefan-bs6ty]

You think too much in SPA world. When talking about htmx, you shouldn't make a connection to Angular or WASM at all. Because htmx is just an extension to good old server-side rendering: It helps you replace parts of your frontend state, in a very smart manner. But that's about it.

[@sootynemm]

bring back car phones!!!!!!!!!

[@typecraft_dev]

It’s all I want

[@TriNguyenKV]

I love htmx; I loath modern js frameworks that adds too much overhead. Make the web simple again is great! Love htmx and alpinejs. Simple, elegant and just work!

[@typecraft_dev]

Agree 100%

[@naranyala_dev]

golang + htmx

[@coben6669]

It may be useful ony on simple frontend apps, but why use htmx on simple frontend while you can use already battle tested template engines? Can't see a point of using this.

[@S-Lomar]

💞💞😍🥰🥰🥰🥰💕💕💕💕🥰🥰🥰🥰🥰🥰🥰🥰

[@QueeeeenZ]

As a frontend developer, I don't like htmx. I don't see how you could create a large complex app with it.

[@roelvaneyken211]

You write the app on the backed, instead of in the frontend.

[@QueeeeenZ]

@@roelvaneyken211 htmx is for all the javascript haters

[@edhahaz]

What HTMX does it does better, but what it can't do React can. On the web the framework that does it all will always "win".

[@shitinsideyou]

you call yourself "daddy" ? what a cringe... you have watched too much of fifty shades stuff.

[@liquidcode1704]

nah u wrong, http obviously mean "hop to the page" lmao