Back before modern frameworks (and jQuery), this was one of the most important tools in the html navigation arsenal. Tbh, it's been so long that I'd forgotten to! 😅
Agree. i like simple tool too. But i am concern whether simple tool can still fare well (in terms of maintenance and readability), if the target it deals with, start growing in complexity.
For me, a medium to large sized project has multiple frontends with complex UIs and great UX, mobile apps that render animations at 60fps is mandatory. Htmx is usesless for me in those cases. React is a tool that gives you more control of the users client device.
Not sure anyone uses put correctly in their rest apis according to this. Every framework out there seems to just use post or put for what should be a patch
Something that's no clear to me. If html can do native partial page updates, how does the server keep track of whether it should send back a full page or a fragment? That's a necessary part of the picture, and it wasn't addressed here. I love everything in this talk aside from that question. :-)
when htmx makes a call, it adds a custom header that you can use on the sever to only send the fragment. if the header is missing, send the full page. alternatively is to use a different url for fragments, for example, prefixed by "fragment/"
@@fish1r1 Yes, I know about the header for HTMX. But if this got into HTML directly, what would be the equivalent? And how would the page handle it if it's not handled by the server? That's what I don't know.
In HTML, I guess those potential additional attributes on form/a/btn should allow the client to handle fragment (partial) and target (replacement) automatically.
@@LarryGarfieldCrell I don't understand the question. I'm guessing you didn't try htmx yet. just give it a shot, play with it a couple of hours, do a form, a list with dynamic items etc and get a grasp. theory will only get you so far...
@@fish1r1 I'm not asking about HTMX. I know it has headers to control fragments assuming you have server side support, or just pulls selected parts out of a full page response. The question is what a native html approach could do, since it cannot assume server side support, and sending back the role page to just pull out part is very wasteful.
I disagree with DELETE not having a request body. I actually had a valid use case recently where I wanted to allow users to send a flag that decides whether others get notified about the deletion. If you prevent me from sending that, I have to keep using the hacky workarounds. Don't come up with arbitrary restrictions without a justification.
It’s reasons like this I think it’s unreasonable to think a monolithic standard is going to cover everyone’s use case. You need to be able to define your own semantics
@@nikolastanisic1954 Doesn't feel very REST-like. The URL should identify the resource. Putting boolean flags for secondary side effects into the URL is pretty weird. Also, why break the symmetry between POST, PATCH, PUT and DELETE? Here's another idea I just had: what if I want to schedule a deletion for a later date? How would I convey that date? Do I have to "POST" a "/resource/:id/scheduledDeletion" instead of "DELETE"-ing the "/resource" in the regular way and passing the date as a body param?
Can we talk about the fact that htmx element apparently expects an html response from the server while we are all used to respond with json? I don't see how all rendering logic can go back to server. What if, say, we need to display returned result differently according to some ui-checkbox being checked or not?
"while we are all *used* to respond with json?" Are you sure? It's all about Hypertext! JSON is just an intermediate language in this case. In the end of day everything going to be HTML.
@@ailuros_I do understand all the benefits here of just getting direct html in the response instead of the intermediary json but one thing I'm puzzled with is - What if you need to parse that returned html client side? For example, the user would like to reorder some of the items. Isn't it easier to parse and process json with JavaScript than trying to parse html?
@@rranon8489 browsers parse HTML. This is a mistake that I've seen many people who first look at HTMX make. They are so used to parsing JSON and then using that data structure to render their HTML that they forget that a browser is literally something that parses HTML. In the case of reordering, there a benefits to having the reordering happen server side - e.g. you can save the reordering immediately. It really does require a bit of a small project with HTMX before suddenly you get that lightbulb moment where you realise that it can be of benefit to unlearn things
One other thing that would make forms and such better. Give JS access to the returned headers in the HTTP call. Then you can have other events happen. That is pretty essential.
What we need is native partial support in the standard. The moment browsers can automatically reconcile partials, it’s reset the market like react did to jquery. We already have the technical ability as view transitions api does something like that already. It replaces parts of the existing page with the result of the request.
@@look997The HTMX way is called an “Out-of-Band Swap”. It’s an “advanced” feature that doesn’t need to be implemented by browsers for this talk to be valid.
@@funky_hedgehogI'm keen to see how it would work on a large SPA dashboard. Mainly how state would be managed. It's where web components fall down compared to React/Vue/Svelte, so I'm assuming HTMX would have similar challenges at scale
@@LukeWatts85 htmx is not meant to be used in the SPA pattern. Htmx says SPA is an antipattern and we shouldn't do that at all. Everything should be handled on server side and the html should represent state. Html should be the engine of state.
That Logout button part... _Isn't_ it just a GET request to logout endpoint? I haven't yet had to implement it in any way other than a GET request to get a logout working... I must be missing something here. If I am... please do help! 14:40
This is our convention because it’s the best option available. However, I can see an argument to be made that a DELETE request to a /session endpoint is more semantically correct. In theory, GET requests shouldn’t mutate backend state.
So if or when HTMX is absorbed into HTML, will that mean every HTMX function will work even on browsers with Javascript disabled? That would be amazing
The good thing is that HTMX is just another JS library like knockout or lodash. Use it where you can get its benefit but continue to use Angular, React, Vue, Solid, etc. where you need to use something more sophisticated! Most of the enterprise apps I have built in the last 10 years have a pretty rich set of app configuration screens. Most of those are perfect for the simplicity of HTMX. Reducing the implementation cost and reducing maintainability cost of those screens will help sell them to the PM. Your users will thank you. Your users will also thank you for the decision to use a richer framework for the heart of the app. It is not one size fits all. Use the tool that best fits the functional and non-functional requirements being implemented. HTMX is just one more tool in the dev's tool belt to please the customer and the PM.
I heard that HTMX (similar to Jquery) does not enforce certain structure in project. Is that true? If true, this can be a problem, when working in a multi-developers team and everyone starts coding in their own way, resulting in inconsistency style, esp in big projects
@@funkdefied1 Hitting the enter key? Or a successful entry of input. I mean these are opt-in so if it doesn't make sense for your form then don't use them. I just think it's weird to support
I like htmx, but I take issue with the discussion at 7:21. POST is not just to create new resources, it's to apply a resource-specific operation, eg. create, delete, replace, link, launch missiles, etc. Furthermore, this whole discussion makes assumptions about URL formats is inaccurate, eg. that well formatted URLs like /user/123 have meaning we can easily interpret. The meaning of URLs is entirely server-defined, and technically clients should not be constructing their own URLs.
These are all server oriented ideas. POST is specifically for creation. Separating these operations declaratively is very powerful, and also gives the control of business logic to the server (where it should be) As far as URLs, if the URLs in actions are in the html, then they are defined BY the server, not the client. Again, control in the correct area. This is very useful, because if the server changes a route, then it can also change the URL reference used in the client.
@@nathanbrown19 POST is NOT specifically for creation. The HTTP 1.1 specification says "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI". This method can be thus used for *any* type of operation, eg. it's a general remote procedure call. This is why it's not idempotent and why browsers only needed to implement GET and POST, because those two are technically the only two operations you need to retrieve or update any data or perform any kind of side-effect. Yes it's nice to have more methods, but those two suffice. As for URLs, my point was that the meaning of URLs are server-defined and that this human-readable pseudo-REST format, like POST /user/123 to create, PUT /user/123 to update, etc. is a structure we may impose, but a client should not and cannot assume it has meaning, eg. given a url like /user/123 they cannot assume that /user/999 and /user/100 are well-formed URLs, or that they all accept the same set of methods. The server may provide /asd8f7h23847hf8 as the URL to create a user, /da897h34t3ieufh as a url to update a user, and /6sd98j349hfnj as a URL to delete a user.
You can still redirect your users in response to POST. htmx is a tool to replace partials , *when necessary*. We can also trigger events that update other parts of the page on dom updates.
POST today has become equated with “any action” BECAUSE that’s all that we have access to in the browser. In purely semantic terms (going by what the spec says), POST is for non-idempotent create events, PUT is for idempotent create events, PATCH is for idempotent updates, and DELETE is for idempotent deletes.
@@funkdefied1 This is a tad revisionist: 1) POST has been for any action since HTTP 1.0 from 1996, and only HTTP 0.9 in 1992 specified POST for create events, 2) PATCH didn't even exist in HTTP 0.9 or 1.0, it was added in 2010, 3) PUT is not just for create events either, but for updating OR creating entities at a URI (HTTP 0.9 actual said the URI should already exist), 3) PUT and PATCH are different semantically beyond mere idempotency, as PUT specifies the precise URI that should be modified or created (the client knows it), where POST may or may not create or modify any URI at all (so the client cannot know the URI or action being performed).
I very much disagree that it should only be forms, anchors, and buttons. I use other elements all the time and it's very useful and very simple to implement the functionality you want
With great power, comes great responsibility. Semantics is an important part of keeping thing clean and maintainable. I agree with you on a basic level, but the additional complexity that can arise, can cause big problems down the line. Maybe not for you as the creator, but for maintainers who follow.
@@abdurahmanmohamed4732 for one, needing to consistently reproduced interaction conventions that are naturally conveyed with anchors and forms (even buttons have these, hence why the video author suggested adding a request method to buttons). Aria prompts for screen readers, focusing, CSS selectors, evens etc Adding these to random divs which you decide should be clickable/requestable is not impossible, but doing so creates additional overheads and complexity. Certainly not much of a problem in small projects, but become increasingly problematic at scale.
I say we just make a new standard that way html can continue to have backwards compatibility and we can move forward with a modern standard. While we are at we can dump JS and create something new.
@@Stefan-bs6ty have you heard about mobile apps? how can you use htmx in Android or IOs? how is an application with a web only frontend a complex large scale app? It seems to me that you havent worked in large enough projects if you need evidence. You arent reaching enough users if you target the browser only.
@@Stefan-bs6ty if you target only the browser, your project isnt as complex or big to reach enough users. A large scale complex project would need multiple frontends, including Android and iOS apps. Also, you need an incredible UX to attract more users. How would you use htmx in those projects? For those projects in my opinion, htmx is a problem instead of a solution. I dont think you have worked in projects big enough to have a clear picture of why htmx is not as useful as it looks.
We shouldn't try and think in absolutes. Webapps (fe first) have their place, but unfortunately have been used everywhere, including areas where they're not needed. So, use React etc. in the correct use cases (needing discrete UI blocks/apps) and server apps when appropriate. The best of both worlds! (And more jobs 😜)
Wrapping a button with a form is NOT a hack Feeling like it's a hack does not mean it is Hacking around what is not a hack is dumb. Now your button doesn't degrade without js 🙃
I only see the death.... Hard to implement custom code. If I have a form, with user data, the form MUST be created at backend level... Then if I have a 'view' with the same data, I need to reimplement the call in the backend. Using api like system, you only need one backend. I don't even start with the "too much garbage", using http headers to put stuff in place. I have one backend, 3 frontends for the same backend.... HTMLX is the wrong way. It's like those movies, or pictures, with two paths, one beautiful and other 'dark'... In MOST stories the beautiful one is a SCAM.
It looks like your backend is architectured like garbage. Because adding view layers server-side is no different than doing it client-side. Same logic, same data sources. You simply switch the view layer, or even only parts of it.
@@Stefan-bs6ty first. You don't know how to code. Imagine I want to list all clients with filtering options. In a well-structured API-driven backend, I can create a single endpoint that outputs the same filtered list to any client: web, mobile, Java, Delphi-whatever the frontend happens to be. Each client pulls only the data it needs and renders it in its own way. This lets me support multiple frameworks and clients (HTML, native mobile, desktop, etc.) with one central source of truth. With HTMX, I’m locked into HTMX for that interaction. To add another HTML framework or non-HTML frontend, I’d have to reimplement the backend logic specifically for that setup, creating duplicates and inconsistencies in data handling. It’s like each new frontend becomes an independent system, which isn’t efficient or scalable. So, an API-driven approach lets me handle diverse frontends cleanly, without redundant logic. This way, each client can just fetch the data and render it, keeping the backend logic in one place. HTMX, in contrast, forces everything into one framework, which limits flexibility.
@@LuizFernandoSoftov Hehe, I'll just skip my 30 years track record. :D Look, if you organize your software properly, you will most likely have your domain, infrastructure and presentation separated. That means, your HTML views mostly consist of a few lines of codes, gathering and formatting data. HTML templates have to be writteb, there lies some work. But, there's no way to optimize this - React composes them via JSX, and SSR most often via template engines. It you need an API for other consumers, you simply build it, for that particular need. Instead of having one single API that serves all and needs to be adjusted all the time and that'll grow like hell. htmx doesn't lock you into anything. If you tailor your web apps wisely, they will even work with JS turned off, with exceptions of REAL client-side use cases, like interactive maps. That means htmx ADDS convenience, but doesn't replace anything. It feels like your software is not as modular and reusable as you think.
@@Stefan-bs6ty ah, the legendary 30 years of experience-impressive! You must be a true connoisseur of scattered code, relishing in the art of spreading backend logic across individual view implementations. Not old as you, but I know the feeling well, actually; I was doing the same thing before HTMX even existed, back in the days of jQuery and PHP. Nostalgic times, really-like a monument to redundancy! No lazy-load, do lazy-load, no spagetti logic, do spagetti logic.. HTMX, as you say, is all about pure freedom, as long as I tailor my app ‘wisely’ enough to keep it modular for every possible frontend. Super convenient! Why would I want to build a single, centralized API to serve multiple frontends when I can make a fresh backend variation for each client, rewriting the same logic over and over again? Who wouldn’t want a mini backend collection! Sure, for a Ui with 6 screens, 2 forms and some buttons, maybe it works. Don't you think that your project in HTMX will grow too? For context, I have a system with 1104 API calls, a lot of modules. Efficiently handling multiple clients (ExtJS, reactJS, Angular, C++, reactNative) without redundant re-implementation. I can even do some automation using some js scripts, or integrate with another system, easy peasy. But sure, I could try integrating HTMX and redoing the backend logic for each new frontend instead. One logic for HTMX and another for the remaining UIs, maybe I will stay using HTTP/WEBSOCKET and JSON, or maybe I will use pure TCP and XML, because it's similarity to HTML. After all, why aim for a single source of truth, why settle for the dark, cold path of efficient, scalable design when I can embrace the HTMX ‘beautiful path’ of duplicate backend logic and custom solutions? Imagine doing a backend, with the logic split all over, fun right? Like back in the old days! Clearly, modular, reusable code is overrated-and if that makes my software less efficient or harder to maintain, well, I’ll just remind myself that HTMX adds convenience … for someone, somewhere, I’m sure.
A lot of the web haven't moved on from jQuery. And a lot had, but for the wrong reasons - how many blogs made with Next.js are out there? I can see htmx powering a lot of websites.
The first guy is very charismatic i think he should start streaming.
isn't he the VSCode guy?
@@RobertFletcherOBE No I think he uses Emacs.
😂😂😂😂
blazinggggly fastttttttttttt
@@RobertFletcherOBEYeah he shits on vim motions all the time. Why learn shortcuts when you can use your mouse
Another win with HTMX is that it’s got absolutely nothing to do with adding “AI” to all the things
Good talk. Also I didn't know you can target an in "target" attribute of - that seems quite useful!!
Back before modern frameworks (and jQuery), this was one of the most important tools in the html navigation arsenal.
Tbh, it's been so long that I'd forgotten to! 😅
I like the idea of HTMX, to just make things easy to work, without the overkill of e.g. React.
Keep it simple and easy.
Agree. i like simple tool too. But i am concern whether simple tool can still fare well (in terms of maintenance and readability), if the target it deals with, start growing in complexity.
Going from backend to frontend has been pretty overwhelming but HTMX makes things so easy.
For me, a medium to large sized project has multiple frontends with complex UIs and great UX, mobile apps that render animations at 60fps is mandatory. Htmx is usesless for me in those cases. React is a tool that gives you more control of the users client device.
Excellent talk! Let's get a formal proposal made
Thank you.
Not sure anyone uses put correctly in their rest apis according to this. Every framework out there seems to just use post or put for what should be a patch
yeah, i'm trying to use it correctly on my app, but PATCH should be imdepotent right?
@@cuauth PUT should be idempotent. PATCH can be, but doesn't have to be.
Alex is a network of talent
Something that's no clear to me. If html can do native partial page updates, how does the server keep track of whether it should send back a full page or a fragment? That's a necessary part of the picture, and it wasn't addressed here.
I love everything in this talk aside from that question. :-)
when htmx makes a call, it adds a custom header that you can use on the sever to only send the fragment. if the header is missing, send the full page.
alternatively is to use a different url for fragments, for example, prefixed by "fragment/"
@@fish1r1 Yes, I know about the header for HTMX. But if this got into HTML directly, what would be the equivalent? And how would the page handle it if it's not handled by the server? That's what I don't know.
In HTML, I guess those potential additional attributes on form/a/btn should allow the client to handle fragment (partial) and target (replacement) automatically.
@@LarryGarfieldCrell I don't understand the question. I'm guessing you didn't try htmx yet. just give it a shot, play with it a couple of hours, do a form, a list with dynamic items etc and get a grasp. theory will only get you so far...
@@fish1r1 I'm not asking about HTMX. I know it has headers to control fragments assuming you have server side support, or just pulls selected parts out of a full page response. The question is what a native html approach could do, since it cannot assume server side support, and sending back the role page to just pull out part is very wasteful.
When HTMX conf?
Should framesets be considered a step (or misstep) in the history of "partial page refreshes"?
I disagree with DELETE not having a request body. I actually had a valid use case recently where I wanted to allow users to send a flag that decides whether others get notified about the deletion. If you prevent me from sending that, I have to keep using the hacky workarounds. Don't come up with arbitrary restrictions without a justification.
Good one. Hope htmx devs will read this
It’s reasons like this I think it’s unreasonable to think a monolithic standard is going to cover everyone’s use case. You need to be able to define your own semantics
Send flag as a path variable?
@@nikolastanisic1954 Doesn't feel very REST-like. The URL should identify the resource. Putting boolean flags for secondary side effects into the URL is pretty weird. Also, why break the symmetry between POST, PATCH, PUT and DELETE?
Here's another idea I just had: what if I want to schedule a deletion for a later date? How would I convey that date? Do I have to "POST" a "/resource/:id/scheduledDeletion" instead of "DELETE"-ing the "/resource" in the regular way and passing the date as a body param?
@@clumsyjester459 Yes. You aren't "doing a DELETE", you are "creating a deletion schedule". POST sounds like exactly the action you want to do there.
Can we talk about the fact that htmx element apparently expects an html response from the server while we are all used to respond with json?
I don't see how all rendering logic can go back to server. What if, say, we need to display returned result differently according to some ui-checkbox being checked or not?
Lots of ways, you can still use Javascript, CSS, you can embed and modify in request URLs etc.
"while we are all *used* to respond with json?"
Are you sure? It's all about Hypertext!
JSON is just an intermediate language in this case. In the end of day everything going to be HTML.
@@ailuros_I do understand all the benefits here of just getting direct html in the response instead of the intermediary json but one thing I'm puzzled with is -
What if you need to parse that returned html client side? For example, the user would like to reorder some of the items. Isn't it easier to parse and process json with JavaScript than trying to parse html?
@@rranon8489 browsers parse HTML. This is a mistake that I've seen many people who first look at HTMX make. They are so used to parsing JSON and then using that data structure to render their HTML that they forget that a browser is literally something that parses HTML. In the case of reordering, there a benefits to having the reordering happen server side - e.g. you can save the reordering immediately. It really does require a bit of a small project with HTMX before suddenly you get that lightbulb moment where you realise that it can be of benefit to unlearn things
@@rranon8489 you don't parse the html. It goes into the dom and you manipulate it there.
So when is HTML6 coming out? 😂
One other thing that would make forms and such better. Give JS access to the returned headers in the HTTP call. Then you can have other events happen. That is pretty essential.
14:20 buttons don't need them. Just wrap it in a form and add a submit handler... But for that we need put, delete, etc..
He talked about exactly that like 10 seconds later 😅
I do agree with more-or-less all of his arguments too, especially the "people would use buttons if only buttons could do this".
But, like he explained, different buttons in the form may require different methods. So one method on the form is often not enough.
RIP❤
What we need is native partial support in the standard. The moment browsers can automatically reconcile partials, it’s reset the market like react did to jquery.
We already have the technical ability as view transitions api does something like that already. It replaces parts of the existing page with the result of the request.
What if I want to replace more than one target with one click?
Well u can do that with Htmx too
@@anouarben779 How? And how to do this in a standard proposal with video? Because it's not the same.
@@look997The HTMX way is called an “Out-of-Band Swap”. It’s an “advanced” feature that doesn’t need to be implemented by browsers for this talk to be valid.
You can use out of band swaps, essentially in the response you say primary target
Great talk! I'm waiting for someone to build a good component library that plays nice with HTMX then I migrate
Yes! A web componets library on pure html
Shoelace and web awesome
@@funky_hedgehogI'm keen to see how it would work on a large SPA dashboard. Mainly how state would be managed.
It's where web components fall down compared to React/Vue/Svelte, so I'm assuming HTMX would have similar challenges at scale
@@LukeWatts85 htmx is not meant to be used in the SPA pattern. Htmx says SPA is an antipattern and we shouldn't do that at all. Everything should be handled on server side and the html should represent state. Html should be the engine of state.
@@fbarneawhat if my users need a mobile app?
There was
blazinggggly fastttttttttttt guy
That Logout button part... _Isn't_ it just a GET request to logout endpoint? I haven't yet had to implement it in any way other than a GET request to get a logout working... I must be missing something here. If I am... please do help!
14:40
I would do a GET request as well. Just hit the /logout endpoint, and in the server, unset the user session.
This is our convention because it’s the best option available. However, I can see an argument to be made that a DELETE request to a /session endpoint is more semantically correct. In theory, GET requests shouldn’t mutate backend state.
GET shouldn’t change state.
So if or when HTMX is absorbed into HTML, will that mean every HTMX function will work even on browsers with Javascript disabled? That would be amazing
aye, would be!
A realistic alternative to a js package manager. Detach from that sea of security issue littered js.
The good thing is that HTMX is just another JS library like knockout or lodash. Use it where you can get its benefit but continue to use Angular, React, Vue, Solid, etc. where you need to use something more sophisticated!
Most of the enterprise apps I have built in the last 10 years have a pretty rich set of app configuration screens. Most of those are perfect for the simplicity of HTMX. Reducing the implementation cost and reducing maintainability cost of those screens will help sell them to the PM. Your users will thank you.
Your users will also thank you for the decision to use a richer framework for the heart of the app.
It is not one size fits all. Use the tool that best fits the functional and non-functional requirements being implemented.
HTMX is just one more tool in the dev's tool belt to please the customer and the PM.
whats PM?
@@yash1152 PM = Project Manager
@@yash1152 product manager.
I heard that HTMX (similar to Jquery) does not enforce certain structure in project. Is that true?
If true, this can be a problem, when working in a multi-developers team and everyone starts coding in their own way, resulting in inconsistency style, esp in big projects
@@yash1152 Project Manager
Want Infinite scroll?
HTMX
Want theme switching?
HTMX
Want user profiles and app settings?
HTMX
Theme switching should be client side wtf
POST should be named CREATE in the first place imho 😅😅😅😅
you're assuming that everyone is using is using POST as intended lmao
if only HTTP verbs had a clear, intuitive meaning, instead of creating depressions amongst those who dare read the http verbs rfc!
@@pierrotlasticot5848 RFC are scary /s
HTMX looks OK for monolithic-like apps. Not sure about microservice architecture where UI/frontend and backend are separate things...
Why would that be any different?
Hey i was in that park yesterday!
If button can make requests, why can't any form element do it? Like or ?
Because they have more complex interactions than just 'click'. ie, what event would cause the request to fire?
HTMX solves that problem. For example you can make an trigger a request on a blur event.
@@GerbenWijnja yes, it can, but it wouldn't be clear to a user that blurring the input would submit a form. Unclear/bad ux (in most cases)
Menu items should be able to make http requests as well…
Menus just wrap buttons, no?
looks like a green screen stage?
Why stop at being able to make requests? Why not ? There's an btw
What event would trigger the request? most inputs don’t trigger an “onclick” or “onsubmit” action in any meaningful way.
@@funkdefied1 Hitting the enter key? Or a successful entry of input. I mean these are opt-in so if it doesn't make sense for your form then don't use them. I just think it's weird to support
I like htmx, but I take issue with the discussion at 7:21. POST is not just to create new resources, it's to apply a resource-specific operation, eg. create, delete, replace, link, launch missiles, etc. Furthermore, this whole discussion makes assumptions about URL formats is inaccurate, eg. that well formatted URLs like /user/123 have meaning we can easily interpret. The meaning of URLs is entirely server-defined, and technically clients should not be constructing their own URLs.
These are all server oriented ideas.
POST is specifically for creation. Separating these operations declaratively is very powerful, and also gives the control of business logic to the server (where it should be)
As far as URLs, if the URLs in actions are in the html, then they are defined BY the server, not the client. Again, control in the correct area.
This is very useful, because if the server changes a route, then it can also change the URL reference used in the client.
@@nathanbrown19 POST is NOT specifically for creation. The HTTP 1.1 specification says "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI". This method can be thus used for *any* type of operation, eg. it's a general remote procedure call. This is why it's not idempotent and why browsers only needed to implement GET and POST, because those two are technically the only two operations you need to retrieve or update any data or perform any kind of side-effect. Yes it's nice to have more methods, but those two suffice.
As for URLs, my point was that the meaning of URLs are server-defined and that this human-readable pseudo-REST format, like POST /user/123 to create, PUT /user/123 to update, etc. is a structure we may impose, but a client should not and cannot assume it has meaning, eg. given a url like /user/123 they cannot assume that /user/999 and /user/100 are well-formed URLs, or that they all accept the same set of methods. The server may provide /asd8f7h23847hf8 as the URL to create a user, /da897h34t3ieufh as a url to update a user, and /6sd98j349hfnj as a URL to delete a user.
You can still redirect your users in response to POST. htmx is a tool to replace partials , *when necessary*.
We can also trigger events that update other parts of the page on dom updates.
POST today has become equated with “any action” BECAUSE that’s all that we have access to in the browser. In purely semantic terms (going by what the spec says), POST is for non-idempotent create events, PUT is for idempotent create events, PATCH is for idempotent updates, and DELETE is for idempotent deletes.
@@funkdefied1 This is a tad revisionist: 1) POST has been for any action since HTTP 1.0 from 1996, and only HTTP 0.9 in 1992 specified POST for create events, 2) PATCH didn't even exist in HTTP 0.9 or 1.0, it was added in 2010, 3) PUT is not just for create events either, but for updating OR creating entities at a URI (HTTP 0.9 actual said the URI should already exist), 3) PUT and PATCH are different semantically beyond mere idempotency, as PUT specifies the precise URI that should be modified or created (the client knows it), where POST may or may not create or modify any URI at all (so the client cannot know the URI or action being performed).
Button: logout > JS or wrap in an A tag. I hate it and it should just be a button with doFunc or submit
"Log Out".
this guy looks like a hotter george clooney
So htmx is giving html a kick in the but?
I very much disagree that it should only be forms, anchors, and buttons. I use other elements all the time and it's very useful and very simple to implement the functionality you want
With great power, comes great responsibility.
Semantics is an important part of keeping thing clean and maintainable.
I agree with you on a basic level, but the additional complexity that can arise, can cause big problems down the line. Maybe not for you as the creator, but for maintainers who follow.
@@nathanbrown19
Could you give some examples of such complexities
@@abdurahmanmohamed4732 for one, needing to consistently reproduced interaction conventions that are naturally conveyed with anchors and forms (even buttons have these, hence why the video author suggested adding a request method to buttons). Aria prompts for screen readers, focusing, CSS selectors, evens etc
Adding these to random divs which you decide should be clickable/requestable is not impossible, but doing so creates additional overheads and complexity. Certainly not much of a problem in small projects, but become increasingly problematic at scale.
I say we just make a new standard that way html can continue to have backwards compatibility and we can move forward with a modern standard. While we are at we can dump JS and create something new.
Not gonna happen
For really complex apps, you need to control the users device.
@@elultimopujilenseplease don't play the "enterprise complex scale" card without providing evidence.
@@Stefan-bs6ty have you heard about mobile apps? how can you use htmx in Android or IOs? how is an application with a web only frontend a complex large scale app? It seems to me that you havent worked in large enough projects if you need evidence. You arent reaching enough users if you target the browser only.
@@Stefan-bs6ty if you target only the browser, your project isnt as complex or big to reach enough users. A large scale complex project would need multiple frontends, including Android and iOS apps. Also, you need an incredible UX to attract more users. How would you use htmx in those projects? For those projects in my opinion, htmx is a problem instead of a solution. I dont think you have worked in projects big enough to have a clear picture of why htmx is not as useful as it looks.
So HTMX is dead?
always has been
Always will be
More like "HTMX ought to be unnecessary by essentially being absorbed into the HTML standard"
@@Akronymus_ But if they do that all the React devs wouldn't have jobs.
We shouldn't try and think in absolutes. Webapps (fe first) have their place, but unfortunately have been used everywhere, including areas where they're not needed.
So, use React etc. in the correct use cases (needing discrete UI blocks/apps) and server apps when appropriate.
The best of both worlds! (And more jobs 😜)
0:07 so, prime-agen is doing the anchoring. ha.
Wtf is primes real name?
His real name is Jürgen Wagner
Nooo dont make me use the platform 😭
I just want to write Solid
Primegean? The good son returns
Htmx
As dead as Primeagens pristine hairline.
Oh look, it's a React developer.
@@GerbenWijnja whoa whoa. I only write react for corporations. Not by choice.
Htmx is best for server side rendering things
HTMx is making Hypertext great again.
It was never cool
So htmx is just another attempt to kill JavaScript lol (using JavaScript😅)
Wrapping a button with a form is NOT a hack
Feeling like it's a hack does not mean it is
Hacking around what is not a hack is dumb.
Now your button doesn't degrade without js 🙃
I only see the death.... Hard to implement custom code. If I have a form, with user data, the form MUST be created at backend level... Then if I have a 'view' with the same data, I need to reimplement the call in the backend. Using api like system, you only need one backend.
I don't even start with the "too much garbage", using http headers to put stuff in place.
I have one backend, 3 frontends for the same backend.... HTMLX is the wrong way. It's like those movies, or pictures, with two paths, one beautiful and other 'dark'... In MOST stories the beautiful one is a SCAM.
It looks like your backend is architectured like garbage.
Because adding view layers server-side is no different than doing it client-side. Same logic, same data sources. You simply switch the view layer, or even only parts of it.
@@Stefan-bs6ty first. You don't know how to code.
Imagine I want to list all clients with filtering options. In a well-structured API-driven backend, I can create a single endpoint that outputs the same filtered list to any client: web, mobile, Java, Delphi-whatever the frontend happens to be. Each client pulls only the data it needs and renders it in its own way. This lets me support multiple frameworks and clients (HTML, native mobile, desktop, etc.) with one central source of truth.
With HTMX, I’m locked into HTMX for that interaction. To add another HTML framework or non-HTML frontend, I’d have to reimplement the backend logic specifically for that setup, creating duplicates and inconsistencies in data handling. It’s like each new frontend becomes an independent system, which isn’t efficient or scalable.
So, an API-driven approach lets me handle diverse frontends cleanly, without redundant logic. This way, each client can just fetch the data and render it, keeping the backend logic in one place. HTMX, in contrast, forces everything into one framework, which limits flexibility.
@@Stefan-bs6ty But, hey, who needs reusability, right?
@@LuizFernandoSoftov Hehe, I'll just skip my 30 years track record. :D
Look, if you organize your software properly, you will most likely have your domain, infrastructure and presentation separated. That means, your HTML views mostly consist of a few lines of codes, gathering and formatting data.
HTML templates have to be writteb, there lies some work. But, there's no way to optimize this - React composes them via JSX, and SSR most often via template engines.
It you need an API for other consumers, you simply build it, for that particular need. Instead of having one single API that serves all and needs to be adjusted all the time and that'll grow like hell.
htmx doesn't lock you into anything. If you tailor your web apps wisely, they will even work with JS turned off, with exceptions of REAL client-side use cases, like interactive maps. That means htmx ADDS convenience, but doesn't replace anything.
It feels like your software is not as modular and reusable as you think.
@@Stefan-bs6ty ah, the legendary 30 years of experience-impressive! You must be a true connoisseur of scattered code, relishing in the art of spreading backend logic across individual view implementations. Not old as you, but I know the feeling well, actually; I was doing the same thing before HTMX even existed, back in the days of jQuery and PHP. Nostalgic times, really-like a monument to redundancy! No lazy-load, do lazy-load, no spagetti logic, do spagetti logic..
HTMX, as you say, is all about pure freedom, as long as I tailor my app ‘wisely’ enough to keep it modular for every possible frontend. Super convenient! Why would I want to build a single, centralized API to serve multiple frontends when I can make a fresh backend variation for each client, rewriting the same logic over and over again? Who wouldn’t want a mini backend collection!
Sure, for a Ui with 6 screens, 2 forms and some buttons, maybe it works. Don't you think that your project in HTMX will grow too? For context, I have a system with 1104 API calls, a lot of modules. Efficiently handling multiple clients (ExtJS, reactJS, Angular, C++, reactNative) without redundant re-implementation. I can even do some automation using some js scripts, or integrate with another system, easy peasy.
But sure, I could try integrating HTMX and redoing the backend logic for each new frontend instead. One logic for HTMX and another for the remaining UIs, maybe I will stay using HTTP/WEBSOCKET and JSON, or maybe I will use pure TCP and XML, because it's similarity to HTML. After all, why aim for a single source of truth, why settle for the dark, cold path of efficient, scalable design when I can embrace the HTMX ‘beautiful path’ of duplicate backend logic and custom solutions? Imagine doing a backend, with the logic split all over, fun right? Like back in the old days!
Clearly, modular, reusable code is overrated-and if that makes my software less efficient or harder to maintain, well, I’ll just remind myself that HTMX adds convenience … for someone, somewhere, I’m sure.
this guys "enthusiasm" is annoying and distracting sorry lol
If this would have worked, we wouldn't have moved on from jQuery. Fite me!
A lot of the web haven't moved on from jQuery. And a lot had, but for the wrong reasons - how many blogs made with Next.js are out there?
I can see htmx powering a lot of websites.
As someone who used quite a bit of jquery lately: jquery is a PITA compared to htmx, because you have to manipulate the DOM yourself
@@Akronymus_ I preferred Alpine over jQuery
Yup, that's how we did in the jQuery days.
The simple size of the lib bundles for each is one very strong reason