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!
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.
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.
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.
In the end you will learn a real frontend framework, or go crying back to the backend. HTMX is a shitty half-baked solution that is only the gateway to a real frontend framework. How are you going to do mobile development? Ever heard of Ionic? and you're going to now support both backend and frontend + mobile with htmx ? Don't be silly!
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.
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.
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.
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.
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!
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!
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 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.
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.
“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
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.
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.
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 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.
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.
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!
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.
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.
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.
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
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 😂
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.
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
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
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.
@@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.
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.
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
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
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.
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 👍
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 :)
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
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.
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.
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,
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 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.
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.
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!
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.
🎯 Key Takeaways for quick navigation: 00:00 🌐 HTMX is a trend among developers who prefer not to write front-end code. 01:36 🛠️ Many back-end developers are forced to learn React for basic interactivity. 03:00 🔄 HTMX allows back-end developers to create interactive UI without leaving their comfort zone. 04:10 🌐 A spectrum exists between server and client, depending on application needs. 06:03 ⚙️ Companies should focus on their unique aspects rather than covering the entire spectrum. 08:11 🧰 Next.js lets you go deep into back-end functions while relying on services. 09:52 🔄 HDMX extends the server's capabilities, freeing back-end engineers from React adoption. 11:58 🤝 HTMX bridges the gap between back-end and front-end developers, improving collaboration. Made with HARPA AI
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
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
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.
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.
As a BE dev, for me personally HTMX is a godsend for DIY projects, I can quickly make a dynamic UI that talks to the backend, React is just slower to use, I can manage all of the state on the backend and only worry about user input.
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.
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.
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....
You dont need react to do basic things like having a menu that opens dynamically, or have a loading widget. If you just need simple things like this JavaScript and CSS are more than fine, along with your backend framework.
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.
@@vectoralphaSec 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.
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.
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.
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.
I've consistently resisted the push to learn React or Vue, and I'm relieved to discover that I don't necessarily have to. As a backend developer who appreciates the simplicity and straightforwardness of jQuery, HTMX feels like a significant upgrade. It offers a modern way to enhance web applications without the complexity of a full-fledged JavaScript framework.
Even as someone who rarely agree on Theo's take, I completely agree with him right here. It's a really good abstraction and allows for really interactive websites without actually haven't to deal with pain of doing it in js. Hopefully htmx evolves and matures into a better product and doesn't just devolve into some niche tool only dozen or so people use.
I'm an FE dev through and through but I'm excited to see how HTMX, AlpineJS and Tailwind are shaping up to be a simple but powerful stack for Rails and Laravel devs
00:00 🌐 HTMX is enabling back-end developers to create interactive front ends without needing to switch to traditional front-end tools like React, allowing for seamless integration of back-end and front-end languages and tools. 01:09 🔄 React faces pushback from developers who feel compelled to adopt it for basic interactive functionalities, like menus or content updates, leading to a gap for those wanting a better front-end without changing their backend-focused mindset. 02:04 🧩 HTMX simplifies front-end updates by enabling HTML to contain instructions for JavaScript to manipulate the back-end, reducing the need for extensive custom client-side code. 03:14 🏗HTMX exemplifies a full-stack solution by allowing server-side code to generate and update HTML sent to users, bridging the gap between backend and frontend without requiring extensive client-side scripting. 04:24 🛠 The evolution from back-end dominance to a closer integration of front-end and back-end technologies, as seen in the GraphQL era, highlights the ongoing shift in how applications are built and the interactions between the two realms. 05:22 🔗 The advent of GraphQL introduced a distinct separation between frontend and backend teams, fostering a layer for interaction but also slowing down iteration speed compared to the closer relationships in earlier API design approaches. 06:03 📊 Focusing on a specific area of expertise unique to a company rather than covering the entire spectrum of backend to frontend can enable specialists to scale down expertise without mastering the full breadth of technology. 07:27 🔄 Challenges arise when backend changes impact frontend architecture, requiring constant re-architecting and causing friction, which frameworks like Next.js addressed by enabling a frontend developer to define specific backend functions. 08:55 🔄 Next.js empowered frontend engineers to delve into backend concerns as needed, relying on services like Vercel and AWS Amplify, blurring the boundaries and allowing for faster iterations without an extensive backend team. 10:48 🌟 HTMX targets backend-focused developers by providing a solution that enables robust frontend experiences without the need to adopt tools like React, allowing for a focus on backend excellence without compromising frontend usability. 11:31 🛠 HTMX bridges the gap between frontend and backend expertise, potentially fostering better collaboration between the two domains and reducing the need for frontend developers to adopt tools like React for certain functionalities. 12:12 📈 HTMX represents a potential evolution from earlier eras like the Rails era, enabling a smoother integration between backend and frontend, offering a promising future for simplifying complex backend/frontend interactions.
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.
Jsx was enough to pass on react. Why not just learn ajax straight up and continue on? I have taken several looks at htmx, and this video helps me identify why it sparked my interest
I think HTMX is an interesting solution, it's simple and elegant. But I think it goes in the opposite direction of Elm, where there is a clearly defined application state, clearly defined state transitions and a clearly defined function that translate any state into a view. Elm's way is the golden path to QA, while HTMX is a way that leads to inconsistent states and views. If people use it while knowing and understanding this risk, that would be OK.
Great explanation..... It's just so crazy to me that this needs to be explained at all! This is the normal way the "www" works, and has been since about 1995! We got ourselves lost writing tons of JS spaghetti for 10-15 years.
These fullstack frameworks like phoenix or rails has now option to update (inject) data to already generated html thru websockets and it's very fast and easy :) HTMX is a nice alternative tho :)
LiveView is very different from HTMX, Hotwire and other options in its details. LiveView is unique and only possible due to being on the Elixir stack. In short Elixir's compilation makes it possible for the framework to take care of replacing the dynamic parts of your HTML without the developer having to denote them in HTML. The framework knows what they are and it can change them for you. It's hard to express how simple LiveView is in box implementation and also experience.
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.
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.
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.
In the end you will learn a real frontend framework, or go crying back to the backend. HTMX is a shitty half-baked solution that is only the gateway to a real frontend framework. How are you going to do mobile development? Ever heard of Ionic? and you're going to now support both backend and frontend + mobile with htmx ? Don't be silly!
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.
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".
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 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.
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.
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!
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 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!!
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
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
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.
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.
This is the single best explanation of htmx - and the historical context around it - I've seen so far. Thanks!
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.
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.
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.
Rails had this in 2010. Phoenix Liveview is a modern "version" of this that uses websockets to send down the html in diff form.
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.
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!
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.
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.
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...
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 😂
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.
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
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
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.
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.
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
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.
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!
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 👍
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.
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.
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
Thx for this the context on how these frameworks came to be helps a lot in understanding when to use them
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
This world become incredible competent, after follow a lot of youtubers, I found you, damn, another guru guy. Thanks for your incredible content
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.
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 like that the backend is now handling more of the heavy lifting and the browser is again just a smart terminal
1:02 Yes you absolutely can do that with server side templating languages. They're called fragments. It's old hat.
This is spot on! I love that you formulated something that has been fuzzy in my brain.
I'm more of a backend person who never learned React. HTMX is looking amazing for most of what I want to do.
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 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.
Livewire doesn't send the whole content just the updated dom same as htmx
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.
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.
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!
Dude! This was an amazing video. Thank you so much for this one! 🍻🔥👍🏼
great video, the visuals really helped in landing your point home
Theo, I am curious to know what is the software you are using to diagram during the stream?
Django + HTMX is a perfect match
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.
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
🎯 Key Takeaways for quick navigation:
00:00 🌐 HTMX is a trend among developers who prefer not to write front-end code.
01:36 🛠️ Many back-end developers are forced to learn React for basic interactivity.
03:00 🔄 HTMX allows back-end developers to create interactive UI without leaving their comfort zone.
04:10 🌐 A spectrum exists between server and client, depending on application needs.
06:03 ⚙️ Companies should focus on their unique aspects rather than covering the entire spectrum.
08:11 🧰 Next.js lets you go deep into back-end functions while relying on services.
09:52 🔄 HDMX extends the server's capabilities, freeing back-end engineers from React adoption.
11:58 🤝 HTMX bridges the gap between back-end and front-end developers, improving collaboration.
Made with HARPA AI
neat
What prompt did you use to do so?
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
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
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.
great job on the video, welcome back :)
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)
Theo, this was a very good video and a great take, good job!
Anyone knows what is the tool that he uses for drawing?
As a BE dev, for me personally HTMX is a godsend for DIY projects, I can quickly make a dynamic UI that talks to the backend, React is just slower to use, I can manage all of the state on the backend and only worry about user input.
youtube algorithm got me here this morning and wow what a good talk that was. thanks man
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.
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.
The thumbnail made me chuckle, "we're mid"
9:50 any links to these rich harris talks?
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....
You dont need react to do basic things like having a menu that opens dynamically, or have a loading widget. If you just need simple things like this JavaScript and CSS are more than fine, along with your backend framework.
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.
@@vectoralphaSec 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.
Very well explained. Thank you
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! 😁
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.
I've consistently resisted the push to learn React or Vue, and I'm relieved to discover that I don't necessarily have to. As a backend developer who appreciates the simplicity and straightforwardness of jQuery, HTMX feels like a significant upgrade. It offers a modern way to enhance web applications without the complexity of a full-fledged JavaScript framework.
Even as someone who rarely agree on Theo's take, I completely agree with him right here.
It's a really good abstraction and allows for really interactive websites without actually haven't to deal with pain of doing it in js.
Hopefully htmx evolves and matures into a better product and doesn't just devolve into some niche tool only dozen or so people use.
It's already mature and far more than a dozen people are using it. The Github Repo has something like 18000 stars right now.
I'm an FE dev through and through but I'm excited to see how HTMX, AlpineJS and Tailwind are shaping up to be a simple but powerful stack for Rails and Laravel devs
Most projects/products start at the backend with a CLI interface, so the faster we can deploy a front end web app the better.
00:00 🌐 HTMX is enabling back-end developers to create interactive front ends without needing to switch to traditional front-end tools like React, allowing for seamless integration of back-end and front-end languages and tools.
01:09 🔄 React faces pushback from developers who feel compelled to adopt it for basic interactive functionalities, like menus or content updates, leading to a gap for those wanting a better front-end without changing their backend-focused mindset.
02:04 🧩 HTMX simplifies front-end updates by enabling HTML to contain instructions for JavaScript to manipulate the back-end, reducing the need for extensive custom client-side code.
03:14 🏗HTMX exemplifies a full-stack solution by allowing server-side code to generate and update HTML sent to users, bridging the gap between backend and frontend without requiring extensive client-side scripting.
04:24 🛠 The evolution from back-end dominance to a closer integration of front-end and back-end technologies, as seen in the GraphQL era, highlights the ongoing shift in how applications are built and the interactions between the two realms.
05:22 🔗 The advent of GraphQL introduced a distinct separation between frontend and backend teams, fostering a layer for interaction but also slowing down iteration speed compared to the closer relationships in earlier API design approaches.
06:03 📊 Focusing on a specific area of expertise unique to a company rather than covering the entire spectrum of backend to frontend can enable specialists to scale down expertise without mastering the full breadth of technology.
07:27 🔄 Challenges arise when backend changes impact frontend architecture, requiring constant re-architecting and causing friction, which frameworks like Next.js addressed by enabling a frontend developer to define specific backend functions.
08:55 🔄 Next.js empowered frontend engineers to delve into backend concerns as needed, relying on services like Vercel and AWS Amplify, blurring the boundaries and allowing for faster iterations without an extensive backend team.
10:48 🌟 HTMX targets backend-focused developers by providing a solution that enables robust frontend experiences without the need to adopt tools like React, allowing for a focus on backend excellence without compromising frontend usability.
11:31 🛠 HTMX bridges the gap between frontend and backend expertise, potentially fostering better collaboration between the two domains and reducing the need for frontend developers to adopt tools like React for certain functionalities.
12:12 📈 HTMX represents a potential evolution from earlier eras like the Rails era, enabling a smoother integration between backend and frontend, offering a promising future for simplifying complex backend/frontend interactions.
You are spot on. I dislike not react in itself , but the hoopla that goes with it.
Good comparisons and video, thank you!
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.
Jsx was enough to pass on react. Why not just learn ajax straight up and continue on? I have taken several looks at htmx, and this video helps me identify why it sparked my interest
I think HTMX is an interesting solution, it's simple and elegant. But I think it goes in the opposite direction of Elm, where there is a clearly defined application state, clearly defined state transitions and a clearly defined function that translate any state into a view. Elm's way is the golden path to QA, while HTMX is a way that leads to inconsistent states and views. If people use it while knowing and understanding this risk, that would be OK.
Great explanation.....
It's just so crazy to me that this needs to be explained at all! This is the normal way the "www" works, and has been since about 1995!
We got ourselves lost writing tons of JS spaghetti for 10-15 years.
These fullstack frameworks like phoenix or rails has now option to update (inject) data to already generated html thru websockets and it's very fast and easy :) HTMX is a nice alternative tho :)
HTMX supports WebSockets as well, see their docs
I don't understand. Isn't htmx exactly like hotwire or liveview? In this video looks like is something different
LiveView is very different from HTMX, Hotwire and other options in its details. LiveView is unique and only possible due to being on the Elixir stack. In short Elixir's compilation makes it possible for the framework to take care of replacing the dynamic parts of your HTML without the developer having to denote them in HTML. The framework knows what they are and it can change them for you. It's hard to express how simple LiveView is in box implementation and also experience.