The Truth About HTMX

Fine, I'll talk about HTMX.
Shoutout Ethan for the great examples • The BETH Stack: Build ...
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4seOne for the awesome edit 🙏

[@samuelgunter]

HTMX stands for HyperText Markup Xanguage

[@Michael-Martell]

I think it’s xylophone.

[@alichamas63]

It's actually Xero

[@agoodmansaid]

😂😅

[@haakonness]

Xactly

[@vectoralphaAI]

Its actually HTML Extended.

[@Descent098]

I think Theo was pretty spot on and put my perspective in better words than I would. I'm someone who mostly does devops, and messing around with infra who hates front end frameworks because they're overbuilt for what I build (mostly CRUD apps for business that do simple things like show the files in a directory in a nicer UI that need a refresh button). I've never bothered to learn react because it's way too much of a buy-in for my work. Unfortunately this often meant writing js with long-polling to do my small set of updates to the DOM. HTMX fits nicely into that niche with less network hits, less parsing client side (JSON and then re-parsing DOM) and with a good bit of readability and simple syntax to boot!

[@JAt0m]

Yeah, it's excellent for b2b type software.

[@IvanRandomDude]

More options is always good. I never understood people who are pissed off that there are more tools and ways to do things. Now it's your job as "engineer" to pick the best approach and tools for your use case.

[@t3dotgg]

For your use case and your team*, otherwise fully agree

[@saralightbourne]

@@t3dotgg well yeah but some of us still don't have a team so…🤧

[@michaelmannucci8585]

Sometimes you’re the one on a team and what was chosen wasn’t a good option lol

[@xdarrenx]

That is because a lot of devs are indeed an imposter and have learned to code like this: problem a = answer b, problem z1 = answer z2... etc. etc.. If u do this a lot u can indeed be an effective dev, just like how chatgpt looks convincing, it has "memorized" a lot of paths, this is not true engineering. A true engineer knows HOW and WHY answer b is correct. So instead of problem a = answer b, a true engineer will see problem a = answer, b1,b2,b3 and thinks in terms of pros/cons between each variant. Hate on me for being so direct, this is what IMO should be engineering, not being someone who is good in memorizing answers to problem, but actually understand the answers . A lot of devs are just not good engineers, and a lot of them will deliver good work, because actual good engineers made good libraries, because it can work, but correlation !== causation.

[@jesustyronechrist2330]

They are pissed off because they feel they missed the ship. It's stupid and childish, but most of us are.

[@StashX]

What's the tool you use for the diagrams? EDIT: Found it, it's called excalidraw

[@whereIsJerome]

For a small / independent dev coming from the backend who wants to create good user experiences, but not have to deal with the mental load of learning two different frameworks, HTMX is a god send. I'm currently reading the book on hypermedia dot systems. For the first time on my three year long web journey, my goals actually feel attainable.

[@subodhchandrashil9229]

Exactly

[@KangoV]

We have lots of dashboards written using react. These are internal only. These are all being rewritten with htmx. JS/react Devs are moving to backend. We are moving souch quicker with our product.

[@semyaza555]

​@@RajinderYadav This sounds like cope. I've been using frontend frameworks since Backbone.js. Different problems require different tech. There is no such thing as a silver bullet.

[@imperi42]

Total cope. Just learn typescript and next.js and leave your ignorance behind. Stop building clunky & crappy interfaces. Level yourself up.

[@fukszbau]

​@@imperi42 next.js has the shittiest dev experience ever.

[@FirdausAziz]

What I like about HTMX is I can do everything I need to do inside Django. No longer do I need to use/handle DRF, create separate "frontend".

[@shao7620]

I don't see how any of this is controversial. You perfectly explained the issue I had with JS in general. JS-land is kinda wild if you look at it from the perspective of a Python guy who just wants an interface to a ML App. Just picking the right Framework was a pain and then new things I had to learn kept piling up.

[@orderandchaos_at_work]

The appeal of HTMX to me is that it logic and state is all backend, where it often belongs. React enabled a lot of logic that should never have been in the frontend to bleed in to the browser.

[@dealloc]

This was very prominent back when jQuery, Backbone and Knockout were introduced. It made sense though; provide an API from backend then load state from backend and store it in the client. There's good reasons to do this, if optimistic updates is what you're after to make actions feel snappier than waiting for a roundtrip. Some actions (especially destructive ones) are best represented by loading indicators, others not so much. The source of truth should always come from the backend, though and you should be able to invalidate stale state.

[@coldestbeer]

Laravel can do that

[@orderandchaos_at_work]

@@coldestbeer Symfony > Laravel* * I don't actually know anymore PHP is a distant memory haha

[@oncedidactic]

“State belongs backend” is the part I never understand, can you explain your pov? To me there a million use cases with ephemeral state that should never touch backend until it “matters”, so you need the logic driving those on the frontend

[@Slashx92]

Session, context and global stare comes to mind. And we created insane behemoths like redux toolkit to deal with it. I love the idea to just use htmx and vanilla js or some libs in the front for nice animations and transitions

[@Maduin1337]

Great take Theo! This is exactly how I feel as a primarily backend dev. More often than not, super interactivity isn't a demand, and this is the reason why I started toying around with htmx. To use our companies backend stack to deliver fullstack apps, where it makes sense. Good video as always!

[@zevo92]

I feel like you've that a great job explaining this, even to me (I'm not a react/next/js expert). The explanation was very elocvent. I also like the light you shed on the "hate react" problem, that in fact there are people using React that don't want to use it not because it is bad or anything, they just don't want to use it, hence the hate that gets miss-assigned to the tool. Great job sir!

[@something00witty]

Cool to see a comparison between next and htmx. I've been keeping an eye on htmx for the last 18 months, but a lot of that time has been me reading/thinking about their essays and going "wow, what a great alternative". My web experience is super limited so it's very nice to see people with a lot more knowledge than me starting to discuss its relative meritcs in the web ecosystem.

[@derrickortiz8432]

I love you. This has been my experience verbatum as a back end person. When I left web development, AJAX was still pretty new and now that I'm back in the game, i'm overwhelmed with the number of front end sledge hammers out there. I don't know what to learn and I don't have a ton of time to learn it. More so, I only need a handful of features. Thank you for this video validating my position in the industry. It helps me understand that I'm on the right track and that my struggle is understood by others.

[@BosonCollider]

HTMX + Hono on a cloudflare worker is a very nice full stack javascript setup imho. You get lightweight reusable JSX server components on the edge without ever having to bring in react, and state management is a lot easier when you just have MVC with a relational database holding the state

[@rodrigosmergerequest]

I agree with almost everything said, one extra point I would add: you can use HTMX + React, if you use webcomponents....Let's say you have an web app that is mostly crud, but have one really important element you want to have an extra degree of front end sofistication(map, calculator, dashboard etc), you could do 99% of the page using htmx and then just do this one component in React, Svelte or Angular ... That would be a great DX for everyone involved, I think.

[@deNudge]

Or just a dedicated plain vanilla JS vue component :-) which should be feasible for most OOP thinking backend engineers.

[@chbrules]

I've always been more of a backend dev, but I was essentially forced into full stack. I am so sick and tired of JS libraries and such. HTMX seems like a breath of fresh air. Bring us back to a simpler time where devs were devs and men were men.

[@flyguy8791]

This was an awesome watch Theo, I came here from your twitter/x post about htmx. I tend to be primarily a back end engineer but have gotten used to working in the space where your front end should just react to your data changes, but I don't always want to have to build a complex front end. HTMX seems like a breath of fresh air in getting a lot of the reactivity without having to build a complex front end,

[@johnnader1134]

This year I brought in HTMX to build a couple new systems for a client. A significant factor for this choices was the team's python skill set and the moderately complex UI requirements. It is ridiculously easy to learn and apply. The HTMX+Django pairing greatly simplified development without sacrificing the front-end user experience. Django templates with HTMX provides a direct ORM binding to UI components, eliminating the need for building a REST/GraphQL layer dedicated to the UI. Theo does an excellent job of visualizing where and how HTMX fits into the client/server balancing act that teams deal with on each project.

[@thejokersandstorm203]

Absolutely spot on. Django and HTMX are a dream combo. I've sprinkled in some Hyperscript too :)

[@everenjohn]

I love your visualization about HTMX vs Backend + ReactClient! I totally explained that to my employers when imagining using it and also said that React would be used with createElement as a renderer in specific use cases. Doing this will cover the entire spectrum in my books, and that is totally enough.

[@ricardosandoval3848]

Thanks Theo, I've spent the last week obsessed with the idea of htmx, go, tailwindscss. I mostly use next, ts but I think I'm turning to the back-side

[@schism1986]

Loving the more casual/relaxed look. The longer stache suits you brother! Happy you're back at it! LFG!!

[@avid459]

I don't know why he does this mandatory downplay of htmx and svelte(as in previous video) by saying they are only good for todolists and simple apps. Unless you are building complicated interactions like google maps, docs or sheets, you can pretty much do everything in htmx. But you would be crazy to choose react for building google maps or docs anyway. You would want something more custom and handcrafted by an elder dwarf.

[@himurakenshin9875]

This was a really balanced overview but most important, the usecases you gave where one will choose next js or htmx at a given scenario is insightful.

[@GGGGGGGGGG96]

HTMX looks for me like a buch of jQuery-Plugins which uses html-attributes in order to be reusable. 10 Years ago I wrote a lot of such plugins to use them in many projects (Tabs, Modals, ajax-content-loaders with URL-State, and so on). HTMX is not a replacement for NextJS (for my opinion 😀), it is just a nice way to build dynamic UIs and do Ajax-Requests when you already have a server-side template-language (like Twig in Symfony).

[@GGGGGGGGGG96]

By the way, I cant believe you can do a project with HTMX and not write any JavaScript-Code. In a simple todo-list-example it is possible for sure, but in reality they will be many cases when you have to customize things.

[@orderandchaos_at_work]

I think it's a useful wake up call to newer devs who don't have the experience of building websites the old fashioned way.

[@GGGGGGGGGG96]

@@orderandchaos_at_work I think every web-developer (whether backend or frontend) should have in-depth knowledge of JavaScript - knowledge about the dom, the dom-api, event-handling and ajax. This is where every web-developer should start and it is not difficult. I would never hire any developer in a company for web-applications without knowledge about this things.

[@stagfoo]

I think another super important thing is reducing overall complexity of a project, only one set of tests, only one set of deps that need auditing, way less dot files to manage. plus because the only requirements of the htmx contract is html strings your choice of programming languages is much larger then before you want to try dart, lua , nim , go even swift

[@dougsaylor6442]

This is the single best explanation of htmx - and the historical context around it - I've seen so far. Thanks!

[@aoshifo]

So, I've been a front end dev for 8+ years (including working on those html templates) and with htmx I want to go more backend (or fullstack or whatever), because htmx makes just so much sense to me. This is the next step in the evolution of web dev.

[@Pepsiaddicto]

Rails had this in 2010. Phoenix Liveview is a modern "version" of this that uses websockets to send down the html in diff form.

[@flyingsquirrel3271]

This take is spot on and very well explained! As a certified JS hater I am super excited about the idea of building something useful using just htmx and a small amount of vanilla JS without any of those crazy complex and bloated frameworks with heaps of custom tooling and stuff.

[@iatheman]

Really happy with HTMX simply because I can a void 90% of JavaScript insanity.

[@griffadev]

We have some internal CMS tools that started out as pure backend html forms and became a jQuery + FE templates (handlebars) mess as more dynamic UI was needed, I can see htmx replacing most of it really nicely

[@magne6049]

handlebars.. shivers🥶

[@sokacsavok]

Yep, it will make just as much of mess...

[@roymcclanahan]

15 years backend before acquiring modern UI frameworks and I absolutely love the React space. Not to mention that many of the overcomplications and inefficiencies of React are being solved by things like SolidJS. I will be sticking with Next and looking forward to an iteration that works well with SolidJS. This is likely just because, though my history was in backend, I love the control I get over frontend behavior with React-like frameworks. I can see scoping future projects to be good fits for HTMX in the future, but those use cases are just not what I am tasked with at the moment. Everyone at my company wants UI to sparkle and shine along with a solid backend, so scaling those kinds of frontend features likely won't be as easy with something like HTMX. Still need a total backend/frontend suite with sophistication in both arenas for me to solve my current problems. Just my situation I guess.

[@t3dotgg]

This is the right mindset

[@amigurumifriend4014]

This is great!

[@chonkusdonkus]

Have you tried something like svelte? I'm also a backend dev who sometimes has to write front end stuff and react literally feels like the Java of front-end frameworks, I would rather flip burgers than write react full-time, whereas svelte is a literal joy to work with.

[@flipperiflop]

The diagram gives a pretty nice idea of the separation of the layers, but also how it can easily overlap. I started as a front-end guy long time ago, just when jQuery came to the field, and have built a lot of Ajax functionality using it, and looking at HTMX does remind me a bit of that. Over the years when doing more backend work, I've wanted to use nextjs, but I really do not understand how anyone can use a service to trigger cronjobs, or what kind of ways there is to integrate worker queues to application. It's the background work that seems iffy in the JS land. But as nice as nextjs is, I think I would rather go with Denos fresh framework, or sveltekit. They have learned from all the work that react and nextjs have done, and iterated on it.

[@gosnooky]

I'm currently prototyping a NestJS module to interact with HTMX because I'm one of those people. It's when I need a simple GUI for some mainly back-end service, but I don't want to embed an entire React SPA stack into the codebase for what amounts to a trivial web app of limited single-use functionality. All I need is some cohesion, and to have a back-end codebase with minimally-invasive HTML markup within src. Some simple HTML snippets alongside controllers and services would do that nicely. I'm really excited about HTMX.

[@krishna9438]

I had doubts with htmx but this video clears things up: the historical context and what problem it solves. Appreciate that Theo.

[@mattburgess5697]

It’s always important to understand these things as solutions to specific problems. People often don’t “get it” because they simply don’t have that specific problem. But it can be useful to know what some of the solutions are so that if the problems come up you can be ready.

[@AntiGoogleEmpire]

I'm one of those backend devs who just cannot wrap their mind around css and therefore like to leave the frontend aside. So since I'm already willfully ignoring frontend, I'm hesitant to learn a full fledged frontend framework. So I'll be hapyp to look into this

[@everyhandletaken]

You and me both! Working on a fairly involved VueJS project, that I unfortunately inherited, at the moment & it is a wild ride.. finding it so hard to debug, it’s a totally different world, with so much complication 🤯

[@nchomey]

You're going to need to know css if you use htmx - its just a mechanism for easily requesting and swapping html fragments into the page. HTML needs CSS so as to not look like a black and white grid. The main difference from react/js frameworks is the html part - you deliver fully formed html rather than json, which gets converted into html by the client side framework. Either way, you need css

[@thiscris_]

Lol, these guys are so lost

[@AntiGoogleEmpire]

I mean obviously I can deal well enough with CSS to know that I’m not going to be a very good frontend dev so that’s why I never bothered to dive deep into Frameworks like react. Obviously I know some CSS and it will be enough for a tool that only does one job and if I needed more, I would make sure to work with a fronted dev who knows their tools. It’s considered a strength to know what you’re good at at what you suck at

[@sora4222]

As a data engineer that has had to build entire UIs not for a front end user but for other engineers or for a team of data scientists having to touch on something front end was always such a hassle. When a project would come to the point where it could be considered for frontend we would consider anything else even just a cli. I learned React and then NextJs specifically for having a language model to be able to chat to the user. What you describe makes me really excited, it will mean that I get something fast, pretty enough and I don't have to beg one of the front end developers to give it a little bit of their time or spend hours trying to learn how to design something which is not what I am after.

[@vcool]

As a data engineer, besides HTMX, you can use a Python tool like Django or Streamlit or Gradio etc. to build a UI if you ever need one. There are many such tools in Python, some of which are easy to use.

[@DelightfulPager-ro4nw]

​@vcool Genuine question, as someone that uses Django and then bootstrap + cobbles together vanilla JS for front end...How does what you say deal with ajax and not having to reload the full dom?

[@infocyde2024]

@@vcool++ for Streamlit. If you are in a hurry you can skip worrying about client side vs server side as it is abstracted and you can focus on the immediate problems at hand. That being said you need to import streamlit extras and a few other things typically, and that's when you start noticing you are kind of limited. I've done some playing with FastAPI and HTMX, this seemed like a good intermediary step. Probably Django in that mix would be a sweet spot. Lastly would be something like Angular or React with FastAPI if you really need to support a lot of users concurrently and have a GUI that really stands out. All depends on your use case but for 90% of internal apps the tools you mention should get the job done.

[@trashcan3958]

As a rust/ python dev. Htmx is exactly what I have been looking for.

[@howardgil499]

Thx for this the context on how these frameworks came to be helps a lot in understanding when to use them

[@Andres-Estrella]

great video, the visuals really helped in landing your point home

[@dz4k.com.]

One thing I would like to have seen: it's actually super easy to write an htmx app and add JS on top, so you can go even further in the "client" direction without overlapping between backend and frontend. htmx triggers DOM events for basically everything it does, so you can extend it. You can also write react/vue/whatever components and wrap them in custom elements so they Just Work. If you want to write somehting like Figma, for example, you can build the outer shell and the list of documents with htmx, and have the actual editor be one big web component built in a suitable JS framework. Whereas with react, it seems like for every npm package "foo" there needs to be a "react-foo" wrapper library.

[@robgreen13]

I'm a back end person. I used the original AngularJS for the little bit of front end I did. Then I didn't upgrade to Angular as it was too much of a shift. I didn't have time to learn React (thankfully my colleagues did) and I even wrote a little bit of a front-end framework myself that did what I needed so that I would not get caught out by endless upgrades to ever more complex frameworks. I'm keen to check out HTMX for my next front end task, which will be some sort of diagnostic tool into the back end to diagnose its state and find issues and optimisations.

[@nathanbrown19]

I came up with a similar solution to HTMX a few years back, but never finished it... so happy to see a similar (but much better) solution getting such acceptance. After starting fullstack over 20 years ago and turning more frontend over the last 15 years, I'm about to jump back to my routes with Astro and HTMX, and super excited to see how it turns out!

[@punkweb]

Django + HTMX is a perfect match

[@lindblomdev]

God damit! I honestly didn't think much of you earlier, maybe it was envy. But after seeing this though, you actually seems quite great. Awesome job on explaining your take, and it's a solid one imo 👍

[@Skillthrive]

Great video, Theo! The backend/frontend diagram really helped explain the benefits of HTMX!

[@daljksdhkajsadasd]

This is spot on! I love that you formulated something that has been fuzzy in my brain.

[@sylarfx]

The main differentiator for me here is if you really want to call server for every interaction with your app. For simpler apps seems OK, but I can imagine it could be quite heavy for more interactive apps especially when you use serverless, the costs could stack up rather fast.

[@oncedidactic]

This is my take as well, I love htmx in theory but it forces intermediate states onto the backend for no benefit, just more network traffic and trivial processing.

[@razvan683]

Well as I see it it's not much different than server side loading if you want your component to load on the client just mix react with htmx. Use react for local loading and htmx for heavy server side components same thing as nextjs correct me if I am wrong

[@AndersBaumann]

I have built commercial sites in HMTX. Just a pleasure to work in. If done right the result is a site that is just as responsive and fast as React, Vue and the other bloated fastfood frameworks.

[@BenjiBoy13]

The application that I am currently building fits perfectly with HTMX use cases, and I am LOVING the experience. It feels so reactive. It looks like I am using react behind the scenes. I have always been a backend engineer, and although I know a bit of react and angular, I am not a fan of downloading a bazillion npm packages just to get a white page with a counter on it!😅

[@Daddyjs]

what do you mean download a billion npm packages just to get a page with a counter on it. You Litterally can do that with react by its self. what kinda app are you building!

[@BenjiBoy13]

@epicdevv It's an exaggeration of course, what I mean is that React is a Javascript library that in order to work it depends on many other libraries which in themselves depend on a dozen other libraries so you can compile your JSX into a single JS file the size of Jupiter, with a counter that increments its value on the click of a button. Just by downloading the core library of react the node_modules folder becomes gigantic.

[@jas0x139]

@@BenjiBoy13 This is why I hate the npm ecosystem and want to get away from it as soon as possible. I have a programming folder where I have projects in various languages. Just ran a du -sh */ on it and Javascript folder sitting at 14GB. That's disgusting.

[@chris94kennedy]

tbh this sounds like you're using create-react-app (re bloat)

[@kabukitheater9046]

it's just alpine js but with dank twitter memes.

[@cristianbilu]

You are 110% wrong

[@FunctionGermany]

​@@cristianbiluyou're welcome to elaborate

[@vintagewander]

You mean dank X memes

[@trungvinh6701]

But it have no javascript

[@benshaw6209]

Alpine works well with HTMX. It serves a different purpose.

[@nskeip]

This approach was widely used in the beginning of 2010’s: when you make ajax request and sever just renders a piece of html. And it required like 10-20 lines of not hard jquery. And it worked for small tasks.But now ANY task you want from frontend turns into “we need React” or something similar. Meanwhile the fronted has little-to-no logic, it just transforms jsons into 😂

[@froreyfire]

HTMX makes it possible to use languages and frameworks for all your web dev which don't have a frontend story. For example - I am being a bit exotic here - the SWI Prolog libraries, which I like a lot. Previously your only options were to either stay very oldschool or to use a JS framework on the frontend. With HTMX I can create a well-behaving interactive website almost without ever leaving Prolog.

[@bridgertower]

Such a good explainer. Thanks Theo

[@BreytnerNascimento]

Beyond regular backend people, I as a data scientist / ML engineer already do a lot of backend stuff to serve ML models and data, but I always needed to use something like Power BI or Tableu to serve visualizations, but now I can do lots of cool stuff by extending just myFastAPI app a little bit further.

[@MattMcT]

Dude! This was an amazing video. Thank you so much for this one! 🍻🔥👍🏼

[@neociber24]

For me thinking about the backend without frontend is weird, I had been fullstack for a good time, I can't really find an use case for HTMX

[@sergenalishiwa9097]

In my case, I do blazor. Combined with ssr I will not need the sockets.

[@jd4codes]

Excellent explanation of what HTMX is. Thank you!

[@cristobaljavier]

Great explanation man, hope you are doing good.

[@davidtansey1395]

Theo, I am curious to know what is the software you are using to diagram during the stream?

[@adrishray9179]

Very well explained. Thank you

[@HaraldEngels]

HTMX is great. I have no issues with JS but developing websites since 1996 I have seen a lot of trends come and go. I remember the time when JS was defined as evil and no serious developer wanted to use it on a professional website. Only AJAX changed that. What is done nowadays in JS (especially with the SPAs) is creating bulky, over-engineered, often slow and unreliable websites with crazy dependency hell issues. The whole tooling became also overly complex. I'm sure that the pendulum will swing back and HTMX is the perfect tool for realizing a healthier more future-proof stack where developers can focus more to the solutions than keeping stacks up and running.

[@LoneIgadzra]

There is also a very important UX point that I disagree with. Latency to Australia may be a downside, but keeping the HTML on the server means much less processing for the client which actually makes a far better UX in many cases. React is very heavy for rendering large amounts of data compared to just swapping the same HTML. This often feels snappier despite any server latency. (Most SPA's have very noticeable server latency anyway, so I'm not sure what the benefit is.) Bottom line is I enjoy coding both ways, but with server rendering I can bang out CRUD (and even much fancier things as this HTMX moment proves), much faster and with less repetition and usually a better UX that doesn't break the browser. I don't hate either, what I hate is not being able to get things done because I have to implement it twice and figure out an API when I could just call a function. I'm surprised HTMX is the thing. I think turbo streams or DOM patching by specifying what to replace in the response is a bit easier to understand. One HTMX example I saw had an updating counter that knew to refresh itself when some other server response returned a custom event. In this case, why not render the counter on the server along with all the other bits that changed and just swap it all at once? And of course the JS ecosystem is just dumb.

[@qlebevillon]

HTMX It's a bit like going shopping and buying a new bag every time.

[@MarcosVMSoares]

U can do interaction with server like react just using liveview on elixir or something similar in rails(hotwire) htmx seems a another option in a different way

[@shakerlakes]

Great talk! What's the drawing program that you're using? Thanks!

[@xbsidesx]

Good comparisons and video, thank you!

[@charliesumorok6765]

1:20 The menu can be done with CSS using :focus-within and the send button can be done with a small piece of javascript.

[@yugiohsc]

No one learns CSS properly these days. It makes me sad

[@brianmeyer3050]

The summary of how interactive, server side web pages worked the last... 20+ years sounded a lot more awkward than it is. Theo just described how a WordPress theme works, where we just enqueue JS to make it interactive. And that is front-end work. A pattern literally everyone watching this video should understand.

[@MrManafon]

Absolutely. These things existed, and we did them for decades. Its an entire spectrum. Htmx seems to just be a framework for what we were already doing anyway.

[@FranzAllanSee]

​@@MrManafoni think react guys can only look at things in react way 😅 Where are the jquery veterans?! 😂

[@SandraWantsCoke]

I am from year 2036. Everyone is using PHP again. React is dead.

[@jesustyronechrist2330]

You gotta understand, this guy probably was like 12 back when everyone was using Wordpress and Jquery. Just like you never had to learn machine code, young devs now don't have to learn the hacks, the optimization, the other things. Everything is "good enough" for 95% of use cases.

[@FranzAllanSee]

@@SandraWantsCoke people never stopped using php. Like it or not, Php is and forever will be the king! 😁

[@arcanernz]

Two problems with htmx that I see is (1) any existing services that delivers json needs to be rewritten or have a translator in front. (2) I’m not sure how styles will be shared if the backend servers are in a different codebase. I think an all in one solution like nextjs/nuxt would be critical for htmx to work properly.

[@joelbiffin]

Ruby on Rails has been able to do interactivity with Templates for a few years now - all of the db updates and reads sync directly to the browser with basically no js

[@cristianbilu]

Rails is using the JS framework Turbo created by the rails team, so there is no "basically no js". There is a lot of js for this to work.

[@joelbiffin]

@@cristianbilu same with htmx though - there is always JavaScript, it's just how much your average application dev has to write and maintain

[@kruceo]

Solid take and incredibly clear way to describe htmx and next.js and the problem they solve.

[@nicolesmileyface]

great job on the video, welcome back :)

[@nexxdev3837]

What is the group listening app you worked on ? It sound very interesting.

[@jasonhurdlow6607]

I identify as one of those back-end focused people who resents the overkill/mess that is React. HTMX definitely has my attention. Now to convince the managers....

[@zacharylarson1245]

What's that font that you're using in the diagrams? It's really awesome! Would love to use it ... :)

[@jk-pc1iv]

youtube algorithm got me here this morning and wow what a good talk that was. thanks man

[@Spiun666]

I want to try htmx out. The missing piece for me with htmx is organizing the backend. I guess any implementation of server-side components could serve as a model. There is also routing for partial responses vs complete page. Would be happy to see some example architectures.

[@stevenvaught9429]

Just put chunks under an /api path. The API is just normal HATEOAS, and anything else is for getting an actual page

[@Spiun666]

@@stevenvaught9429 How do I share components/templates and logic common between the full-page render and the partial rendering

[@Fluxiton]

Livewire doesn't send the whole content just the updated dom same as htmx

[@grimm_gen]

At me previous job we worked in a Rails backend with a React Frontend, I liked it!

[@JoffeDall]

Theo, this was a very good video and a great take, good job!

[@elcontrastador]

That was an excellent overview…kudos

[@tnetroP]

I'm not a professional web developer but I am currently looking at a tech stack for a personal project and had resigned myself to learning Javascript. But HTMX looks very interesting. I could use Go for my back end and HTMX to help with the front end. One of the main reasons people seemed to learn JS was because it could be a single language used on the front end and more recently also on the back end. Looking at it long term, if you can use HTMX for front end instead of hand coding JS then it opens up a lot of options for back end languages instead.

[@Xe054]

Serious question: where can I get that shirt?

[@abdelhameedhamdy]

The translation layer could be a BFF layer (Backend for Frontend paradigm)

[@nicolascanala9940]

Livewire (at least the one from Laravel) doesn't send a whole new template. It looks for the part that changed in the template and just sends tiny bits of html to update it :)

[@JimmyC0]

then it's identical to what htmx is doing, right?

[@spicynoodle7419]

​@@JimmyC0yes but more platform independent

[@nicolascanala9940]

Pretty much! Though it's custom tailored to Laravel, written on top of Alpinejs & has its own "MorphDom" algo, which is more performant and flexible. Also it's more secure, not opening you up to XSS attacks@@JimmyC0

[@rhaikh]

@@JimmyC0yes, theo seems wrong about this, turbo is also a nearly identical solution. These options are better for their respective "home" frameworks though and are less agnostic

[@davidszkilnyk3106]

As a Go Dev that finds the front ends environments a complete mess. I found htmx a welcome change. But please we need a nice a ui library (even with a splash of JS) to tie things together. Going back to bootstrap has me scratch my head there has to be something better?

As always, great video, Theo.

[@gonzalooviedo5435]

This world become incredible competent, after follow a lot of youtubers, I found you, damn, another guru guy. Thanks for your incredible content

[@johanvandermerwe7687]

Well done Theo! This really put things in perspective!

[@fbscarel]

Excellent video, thanks for that!

[@kiyov09]

Good explanation, good video. Thnx Theo.

[@trenxee1165]

1:02 Yes you absolutely can do that with server side templating languages. They're called fragments. It's old hat.

[@arthurdias354]

Seems like HTMX fits a niche of backend-first applications* but if you think thoroughly about in the way interactivity is becoming the standard, (almost web/mobile app) have some sort of animation in order to make the app feels smoother to the user when interacting with it so

[@u9vata]

What I really hope is that web browsers would support htmx as built-in (and ignore the script tag for it by parsing part of it). This would not only enable higher performance with literally no downloads other than useful content - but also would make it possible to have javascript disabled and get very nicely interactive pages for people who run with disabled javascript!

[@shelterit]

I just made a htmx and bun framework, and it has been a revelation in terms of the amount of js code that we no longer need, cleaner and much purer templates, and another bonus is how it forces Devs to think about cleaner html with less CSS framework specifics. The only challenges left are user state stuff, and how htmx directives are hooked together in more complex interactions. Oh, and there's a lot less exception handling!

[@ccj2]

If this means that my front end days are finally sunsetting and I can go back to focusing on APIs and infrastructure, then I’m here for it!

[@gardnmi]

Most projects/products start at the backend with a CLI interface, so the faster we can deploy a front end web app the better.

[@TheNewton]

What's going on in python-land, Microsoft has added python to Excel to create custom forumlas or python libs. Though it seems the runtime has to be hosted by them on azure.

[@FeckOffTeaCup]

I'm more of a backend person who never learned React. HTMX is looking amazing for most of what I want to do.

[@fueledbycoffee583]

In python land we have jinja! Pretty good. But i only use python for APIs. Not a big nodejs fan. I love decorator pattern when coding apis in python. is so easy to add guards and middleware to routes

[@ant1fact]

Thanks for spreading the word :D