The Truth About HTMX
Vložit
- čas přidán 22. 08. 2023
- 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 🙏 - Věda a technologie
HTMX stands for HyperText Markup Xanguage
I think it’s xylophone.
It's actually Xero
😂😅
Xactly
Its actually HTML Extended.
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.
For your use case and your team*, otherwise fully agree
@@t3dotgg well yeah but some of us still don't have a team so…🤧
Sometimes you’re the one on a team and what was chosen wasn’t a good option lol
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.
They are pissed off because they feel they missed the ship.
It's stupid and childish, but most of us are.
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!
Yeah, it's excellent for b2b type software.
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.
Exactly
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.
@@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.
Total cope. Just learn typescript and next.js and leave your ignorance behind. Stop building clunky & crappy interfaces. Level yourself up.
@@imperi42 next.js has the shittiest dev experience ever.
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.
What's the tool you use for the diagrams?
EDIT: Found it, it's called excalidraw
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".
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!
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.
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.
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.
Laravel can do that
@@coldestbeer Symfony > Laravel*
* I don't actually know anymore PHP is a distant memory haha
“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
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
Loving the more casual/relaxed look. The longer stache suits you brother! Happy you're back at it! LFG!!
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!
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.
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.
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
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
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.
Absolutely spot on. Django and HTMX are a dream combo. I've sprinkled in some Hyperscript too :)
This is the single best explanation of htmx - and the historical context around it - I've seen so far. Thanks!
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.
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.
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.
Or just a dedicated plain vanilla JS vue component :-) which should be feasible for most OOP thinking backend engineers.
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,
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.
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.
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!
Great video, Theo! The backend/frontend diagram really helped explain the benefits of HTMX!
Theo, I am curious to know what is the software you are using to diagram during the stream?
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
great video, the visuals really helped in landing your point home
This is spot on! I love that you formulated something that has been fuzzy in my brain.
I had doubts with htmx but this video clears things up: the historical context and what problem it solves. Appreciate that Theo.
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.
As a rust/ python dev. Htmx is exactly what I have been looking for.
Thx for this the context on how these frameworks came to be helps a lot in understanding when to use them
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.
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.
@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?
@@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.
Great talk! What's the drawing program that you're using? Thanks!
Really happy with HTMX simply because I can a void 90% of JavaScript insanity.
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.
Dude! This was an amazing video. Thank you so much for this one! 🍻🔥👍🏼
The take that this is a specific tool for a particular audience and not "The Next Thing" is probably the best one I've seen so far.
What's that font that you're using in the diagrams? It's really awesome! Would love to use it ... :)
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 😂
Rails had this in 2010. Phoenix Liveview is a modern "version" of this that uses websockets to send down the html in diff form.
it's just alpine js but with dank twitter memes.
You are 110% wrong
@@cristianbiluyou're welcome to elaborate
You mean dank X memes
But it have no javascript
Alpine works well with HTMX. It serves a different purpose.
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 👍
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.
This is the right mindset
This is great!
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.
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.
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
handlebars.. shivers🥶
Yep, it will make just as much of mess...
great job on the video, welcome back :)
Very well explained. Thank you
This world become incredible competent, after follow a lot of youtubers, I found you, damn, another guru guy. Thanks for your incredible content
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.
I like that the backend is now handling more of the heavy lifting and the browser is again just a smart terminal
Good comparisons and video, thank you!
youtube algorithm got me here this morning and wow what a good talk that was. thanks man
What is the group listening app you worked on ? It sound very interesting.
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.
That was an excellent overview…kudos
Solid take and incredibly clear way to describe htmx and next.js and the problem they solve.
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!
Theo, this was a very good video and a great take, good job!
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.
1:02 Yes you absolutely can do that with server side templating languages. They're called fragments. It's old hat.
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.
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
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 🤯
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
Lol, these guys are so lost
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
Such a good explainer. Thanks Theo
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!
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).
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.
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.
@@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.
Anyone knows what is the tool that he uses for drawing?
Excellent explanation of what HTMX is. Thank you!
As someone who has done both backend and frontend development, but in latter years much more of the backend, I'm pretty excited about HTMX / Hyperscript opening the door for me to get back into more frontend work without having to spend years slogging through the details of yet another JavaScript framework. Currently working on replacing an Angular frontend for a webapp I wrote some years ago with HTMX / Hyperscript. OK I currently have one JavaScript line of code in there. The best part is not having two separate build systems to deal with. And I feel like HTMX / Hyperscript is truly lightweight so I can easily rip it out if it doesn't work out to say nothing of easy to learn so I can focus on the business logic, not messing around with trying to figure out how to fit what I want to do into the framework when that's not a first class feature of that framework.
Great explanation man, hope you are doing good.
The thumbnail made me chuckle, "we're mid"
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!😅
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!
@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.
@@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.
tbh this sounds like you're using create-react-app (re bloat)
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.
No one learns CSS properly these days. It makes me sad
Good explanation, good video. Thnx Theo.
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.
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.
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
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.
Excellent video, thanks for that!
Django + HTMX is a perfect match
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.
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.
As Theo said, it is a matter of properly accessing the desired outcome. For simple websites, like most consultancy jobs, HTMX will be enough. If you want to build a very interactive page or complex systems, the base cost of adopting frameworks like React or Vue is probably worth it.
HTMX allows for more complex interactions. In a way its a replacement for all those JS frameworks.
@@vectoralphaAI Pure JS allows for all those complex interactions as well. Get my point? You lose on abstraction, which done improperly is evil, but done correctly is the basis of software engineering. Otherwise we'd code in 0s and 1s.
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
I'm more of a backend person who never learned React. HTMX is looking amazing for most of what I want to do.
Thanks for spreading the word :D
really good explanation!
Well done Theo! This really put things in perspective!
As always, great video, Theo.
As a backend developer who has had to spend a lot of time on front end - but who now focuses on cloud and CLIs - HTMX sounds incredible if I ever need to build websites again. I know I don’t want to have to learn React as there are so many other things on the backend I would rather learn with my learning time.
This is exactly why I like HTMX
awesome and super excited with htmx
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.
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.
@@MrManafoni think react guys can only look at things in react way 😅
Where are the jquery veterans?! 😂
I am from year 2036. Everyone is using PHP again. React is dead.
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.
@@SandraWantsCoke people never stopped using php. Like it or not, Php is and forever will be the king! 😁
Was the Frontend team limited to Clientside? I'm used to Frontend teams handling both Serverside and Clientside. Like a node-app would be entirely handled by the Frontend team, while our Backend team just provides a content-API. We've got a SSR site with vanilla JS where if we have a client heavy feature like Search, our client just calls our server to render partial HTML: and this is pretty easily done within the Frontend team with VanillaJS.
I think that more options is always a good thing :D
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.
Excellent explanation. I came in from nothing but know exactly what it is now. I am the guy who loves to do backend but hates to touch frontend stuff. HTMX is a present from heaven.
Serious question: where can I get that shirt?
At me previous job we worked in a Rails backend with a React Frontend, I liked it!
Well explained!
Most projects/products start at the backend with a CLI interface, so the faster we can deploy a front end web app the better.
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
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
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.
@@cristianbilu same with htmx though - there is always JavaScript, it's just how much your average application dev has to write and maintain