The Truth About HTMX
HTML-код
- Опубликовано: 22 авг 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 🙏 
Наука
HTMX stands for HyperText Markup Xanguage
I think it’s xylophone.
It's actually Xero
😂😅
Xactly
Its actually HTML Extended.
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.
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.
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.
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.
@RajinderYadav Mobile development? Probably with HTMX
in the near future. It's hear to stay, being developed quickly, and, has already proved itself to me more than a "shitty half-baked solution".
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".
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.
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!
What's the tool you use for the diagrams?
EDIT: Found it, it's called excalidraw
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!
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 :)
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.
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
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 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.
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.
Loving the more casual/relaxed look. The longer stache suits you brother! Happy you're back at it! LFG!!
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
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
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.
This is the single best explanation of htmx - and the historical context around it - I've seen so far. Thanks!
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,
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.
Thx for this the context on how these frameworks came to be helps a lot in understanding when to use them
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.
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 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!
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.
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.
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
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.
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.
Rails had this in 2010. Phoenix Liveview is a modern "version" of this that uses websockets to send down the html in diff form.
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...
Dude! This was an amazing video. Thank you so much for this one! 🍻🔥👍🏼
I like that the backend is now handling more of the heavy lifting and the browser is again just a smart terminal
Really happy with HTMX simply because I can a void 90% of JavaScript insanity.
Solid take and incredibly clear way to describe htmx and next.js and the problem they solve.
This world become incredible competent, after follow a lot of youtubers, I found you, damn, another guru guy. Thanks for your incredible content
Very well explained. Thank you
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!
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.
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 😂
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 👍
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.
Good comparisons and video, thank you!
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.
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.
Theo, I am curious to know what is the software you are using to diagram during the stream?
Such a good explainer. Thanks Theo
That was an excellent overview…kudos
Theo, this was a very good video and a great take, good job!
youtube algorithm got me here this morning and wow what a good talk that was. thanks man
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.
great job on the video, welcome back :)
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!
really good explanation!
Anyone knows what is the tool that he uses for drawing?
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
The thumbnail made me chuckle, "we're mid"
Excellent explanation of what HTMX is. Thank you!
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.
Yeah, most of what we need from front end (for a big complex app) is just for it to do things like make requests to the backend for filtering, sorting, and pagination, or to post a form and update the page, maybe switch out a class for styling, etc. The rest could just be simple vanilla JS.
Using React/Angular/whatever-the-JS-framework-of-the-week-is-this-week is way too much overkill for that. Tons of bloat and dependency hell and added complexity for things that should be trivial.
But that's how the industry has been going for awhile, like you're stuck organizing and driving an entire convoy of temperamental 18-wheelers just to go down to the corner store to pick up a soda. So it's nice to have a better alternative. Would like to see it get more industry uptake.
For the cases where you're trying to recreate an entire office suite or photoshop or whatever in the browser, sure, pick something else. I agree that the front-end frameworks aren't really good for that either. Maybe a proper application compiled to webasm, if that's developed enough now, but I don't know as much about that.
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 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.
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
Great explanation man, hope you are doing good.
Django + HTMX is a perfect match
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.
Excellent video, thanks for that!
Well explained!
Good explanation, good video. Thnx Theo.
You are spot on. I dislike not react in itself , but the hoopla that goes with it.
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?
I’m mostly front end, but I really want to build up my back end chops. I want to learn htmx so I can learn to lean more on the backend to power my apps.
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
In my case, I do blazor. Combined with ssr I will not need the sockets.
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
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.
What's that font that you're using in the diagrams? It's really awesome! Would love to use it ... :)
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.
Well done Theo! This really put things in perspective!
does anyone know a book that explains all the webdevs at a conceptional level. Basically presenting the concepts (templates, hooks, states, components, ssr, signals, ...) and explain how these are implemented in the different python and js frameworks, rails or c++/go, wordpress?
I think that more options is always a good thing :D
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.
I'm more of a backend person who never learned React. HTMX is looking amazing for most of what I want to do.
As always, great video, Theo.
Livewire doesn't send the whole content just the updated dom same as htmx
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
Only Theo could get me interested in trying out NextJS in a video that I had clicked for learning about HTMX...
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)
awesome and super excited with htmx
Is this like dotnet view components that generate html parts?
At me previous job we worked in a Rails backend with a React Frontend, I liked it!
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 :)
then it's identical to what htmx is doing, right?
@@JimmyC0yes but more platform independent
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
@@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
Great talk! What's the drawing program that you're using? Thanks!
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
9:50 any links to these rich harris talks?