We made two actual applications with HTMX and we and our clients are very happy with the results. Our software architecture is disciplined and simple. Data and logic live in storage/repository/service layers not within controllers, this way non-html clients like a Swift or Kotlin app consume dedicated controllers which do consume aggregated data from the services but simply don't parse it through views. (To be clear with my terms; service is not an api or micro service, it is just a technical layer inside of an application that prepares data for controllers). Anyway long story short, its very refreshing to have such a simple way for building pretty advanced HTML applications with very little JS code.
"Our software architecture is disciplined and simple"... so many technologies try to make up for a lack of the former with a lack of the latter. Inheritance, microservices, ORMs, anything which has the word framework in it's description, (I would say, "types" but let's not go crazy, structured data carries semantic value) all try to prevent poor code by necessitating convention. As an example, microservices don't make your components modular and loosely coupled they necessitate it... sometimes that works sometimes that doesn't but one thing it always does is increase overheads. If your microservice is a singletone speaking to a singleton I do not think your interface is not doing what you think it is doing. A JS application on the browser is leaky control logic, Control logic that must be replicated on the server to avoid security reasons. Keeping the two lots of partial logic in sync... urghh... you need a framework for that. htmx still requires JS on the browser... for specific behaviour of specfic widgets and bespoke widgets. (sorry JS, for visuals html5 and css done ate your lunch).
This point about data representation is super important. Different contexts call for different representations of data. Not sure I will realistically be using HTMX anytime soon, but I like the idea of delivering the format that the consumer actually cares about, since it carries intent with it. As in: This is HTMX, use it in a browser. Not: This is JSON, use it to perhaps eventually render it in a browser.
I work on a large, fairly busy server-rendered Perl site that's under active development. Many bits and pieces of interactivity were added over the years, first through jquery and lately with vanilla JS. I could definitely see adding HTMX to the mix.
I'm currently trying this out with Golang and Templ (for HTML templating). I have to say, before using it I was sceptical... But after a few basic usages... I kinda sorta fell in love with it. In Go and in HTML that is. Especially the handling of state is way easier since the truth state is always on the server. Don't try to be smart. Make it dumb and simple. PS: the htmx inventor recommends having two separate endpoints for json/HTML responses instead of handling it using accept headers. I think it was on a primeagen stream.
Null Labs also had a really solid video on this, looking at the creators older projects, explaining that it's largely about round trip latency; and tbh we've already got great tools for that.
I'm not sure we "lost our way" with the DOM manipulation libraries and JSON requests, etc. Frameworks were created out of a real need (e.g. slower internet connections, HTTP connection bottlenecks, etc.), so doing all the work on the browser made more sense. The tradeoffs, however, became more and more apparent the further we moved into JavaScript land on the front end. We all of a sudden had to think about things that the browser traditionally did much better, like routing and scroll position management. If nothing else, JS DOM libraries have galvanized what is important in native browser concerns, and helped steer us to the current state of the Web. BTW, I have been loving your channel since discovering it a couple months back. Great content!
These javascript frameworks were created because Javascript code was becoming large and complex because of very complex, very interactive frontends. In fact, things like reactjs are still better in this scenario. But people used them when they didn't require complex Javascript code because That's What Facebook Uses, and then, because That's What Everyone Uses. To be fair, popularity is a valuable metric: it's easier to get help with it, it's easier to find a job, easier to hire, etc. Also, reactjs came out long after internet connections were generally fast.
Thanks for the comment. In practice, as you mentioned the further we moved down the road, more data (payloads,js,bundles,etc) was sent down to the browser, which was the exact opposite of what was needed if the concern was slower connections, bottlenecks, etc). I have always been left scratching my head with the reinvention of routing because it was forced with the model of a SPA.
HTMX is just a fresh air. I did lot applications in react and wrote backend in golang. React always felt overcomplicated, with all the hooks, libs and so on. I do mostly dashboards, and HTMX is just the perfect fit. Every feature needs at least 40-50% less time to deliver. I definitely not go back to react.
Yes, I think it's entirely dependent on what you're building ultimately. As always some tools fit better situations than others. I think the problem is we tend to use the same tool for every situation, when it's entirely overkill or not a good fit, often because it's just "what the industry uses"
I used the .htmx extention as a way for the Http module at the core of my CMS (in 2003 or something) to recognize that this was a page that needed to be served by my cms, as opposed to a static path or file
A massive problem with what they're advertising: An HTML partial is not the same thing as HTML. I can't just go to /contact/1/edit and expect the website to render with the edit form. That GET request is just returning a partial. The glory of the old internet was if I had something like a Ruby on Rails scaffold, when I go to /contact/1/edit I get the entire hypermedia resource with all the hypermedia controls. I could bookmark that edit resource and come back to it and I'd get the same edit form. Of course I could do something more clever on the server to understand whether the request is over HTMX or a browser navigation, returning a partial in the former case and a full page in the latter. But I'm not getting rid of any of the added complexity of trying to do in-line edit, and I'm certainly not rescuing the simplicity of the REST model with HATEOS, statelessness, and the simplicity of collapsing resource and representation. Trying to get fancy stuff like in-line editing still means moving state and behavior to the client, and it still means giving up the simplicity and robustness of pursuing a REST design where we can represent something like an edit form as its own hypermedia resource rather than as a stateful on-client interaction.
htmx actually sends a header that tells your app it’s an htmx request, that way you can decide on rendering a partial or the entire page. It’s just a little check to add.
I haven't used htmx yet but i feel like the first step is to build an HATEOAS api/core and then put an htmx layer on top of it. But i'm still looking for a standard way to build the HATEOAS api (not htmx). If you guys found a good one (not a language, not a framework, a standard), let me know !
You can use pretty much any server side language for this - you just return html rather than json. That's it! Use php, ruby, go, or whatever floats your boat
Hmmm, in my opinion the big difference is where state resides. With JSON pulled from the server, the browser usually holds state; code running in the browser using the state present in the browser decides what to request next. With HTMX the state seems to move back to the server. After all it needs to know what was selected, or in a cart, or whatever to generate the HTML. HTMX does not seem well suited to have browser side state and then send all that to the server to make sure it has all the data it needs to generate HTML. Or it becomes some kind of weird hybrid where it send partial... Nah, that would be a disaster.
It is a matter of opinion or preference if the state should be stored in the server or client. You will always have trade offs. I much prefer SS state. But that’s how I am used to develop web apps for more than two decades. It suits me very well in most cases. If it works and is easy to maintain, then it’s the right tool!
@@habsi70 I've been developing SS for decades as well (and still am). And while SS increases control of the (performance of the) application, the client is just a dumb HTML display engine in that scenario, having the state on the server is not the most logical place. As much as I would like it to be, it adds complexity. The interaction with the user is in the browser, so it make sense that at least the state around the UI is there. It is not without reason the web-frontend-and-rest-backend became so popular; Rest APIs are largely stateless. And if the state is on the frontend, then the rendering also needs to be, otherwise state needs to be synced all the time (so the rendering backend knows what choice a user just made in select ABC or what have you). So rendering happens where the state is. And if one does not see the additional complexity with state on the server, then one indeed doesn't get it. 😄 The only real alternative is something like Vaadin in pure Java mode, but that is a niche approach. So the big difference of HTMX and the current web development is that state moves back to the server.
@@TomEugelink I think I understand. I am not sure if my bias prevents me from working more efficiently in the frontend or if the type of projects I do are just not that complex on the frontend. For now me and my collegues are more efficient (less time programming, better at maintaining) when using SS state. But i will keep your reasoning in mind in an upcoming project and validate it from that perspective.
Use different CSS? If the layout is completely different you have to serve different HTML. Even when rendering client side you would have two templates if the DOM differs that much.
@habsi70 so I guess in this case you are tailoring your responses to the front-end. Feels like a hard coupling. But I think this an edge case that is hardly seen, more likely you would have the client just get the json response if they don't like html one I guess
@@purezero23 Exactly! Of course this is not always a useful way to create an app. In most of my applications we have a rather static backend where htmx fits very well. Where needed we provide the necessary interfaces for JSON, XML or whatever is required. React et al seems in these cases overkill. A little AlpineJS a little custom JS and you have a usable UI which is rather low tech. Which is maintainable even by non specialists.
Then use something else? Use a tool that fits your needs, there is no need to choose only one tool and always use that. Find out what you need to do, and then use an appropriate tool 👍🏻
@@miindaugasif it was a skill issue there would be examples of good react apps. But unfortunately there isn’t. Every single one turned into an over abstracted mess that’s difficult to manage.
Haven't used it yet, so I don't know if there's some kind of caching layer or something, but it looks like a lot of unnecessary round trips to get, what is effectively, presentation states. That's the first red flag. I also understand that you excluded CSS in the payload markup to simplify the explanation of what's going on here, but there is an implication that there needs to be CSS in the base/original page download that "knows" about the structure/markup of the presentation data that's coming from the api/htmx response. That's seems like some icky coupling and while I admit quite a bit of ignorance here that makes it smell very half-baked.
We use it and regarding your concerns, HTMX respects cache related HTTP headers. We started using tailwindcss, which fixed a huge deal of different css headaches for us. We do have a few more round-trips, but these are smaller and never contain data, that is not needed. (The json data we used to have really were lot's bigger quite often, because the client made the decision, what part of it the user needs..)
You have to remember that HTMX is not a stack framework, it's a way of extending HTML's hypertext. If you want caching, enable it server side. Likewise with compression, or any other features. As @KimHogeling says, it honours the HTML request standards, and those are controlled server side, so just enable what you want.
Well yeah, but when you start adding your own code - the actual app - the js size increases really quickly. Everything is a tradeoff. SolidJS is awesome and if I was doing something incredibly complex UI wise like a full application I would use something like SolidJS. But if you only do an e-com, an internal tool with some forms etc HTMX is such a breeze to work with.
Over time you find yourself using more and more features of HTMX and that's when the few extra KB really pay off. It's actually a really small size for what it can do. And it's just tiny compared to other frameworks. Svelte is also tiny though, but that grows of course with every single new functional feature, just as a side note.
it's just not a good idea. trying to handle UI concerns on the server was not a good idea when we were doing it 20-something years ago, and it's not a good idea now. why are the obvious limitations not mentioned here? if we're being objective, we need to consider the limitations of this approach - you *will* be asked to do something you can't do with this lightweight declarative approach, or at the very least, things you can't do *well* with this approach. we need to consider complexity - you're effectively trying to replace JS with a declarative framework. this framework is likely to grow as users demand more and more of things they were able to do with JS. and how about performance? it's not just the issue that you're sending more (redundant) data, it's also the fact that this data can't be cached like many JSON requests can - or at least can't easily be cached, since cache invalidation would now coupled with HTML, design and layout. You also need to consider the sheer volume of requests, which will be much higher - for something like, say, picking a country and city, where you will need a second request for the list of cities. Every request is more expensive on the server too, since rendering HTML typically involves a template engine, while JSON just requires a simple and usually very fast JSON encoder function. These performance issues can affect user experience as well, because they're making another request after almost every interaction, which will likely feel sluggish - and you can't really optimize UX either by preloading data, because you're not working with data. "oh but React is slow too", yeah, well then use Svelte or Solid or Preact or whatever works better for you - if you want something fast and smooth, learn how to do that. All of these libraries are smaller than HTMX, by the way. Not that the "small" filesize of HTMX is even worth highlighting, since you've just moved all your UI markup out of the client onto to the server and are now sending all of the *rendered* markup with every response. this approach to UI is as unnatural as ever. the natural place to handle user interactions is in front of the user. the only appeal here is for people who hate JS or love their server-side template language - at least be honest then, and just say it, you picked this not because it's technically better in any way, but because you *like* it. And that's fine, but please go into this knowingly - all the same drawbacks we had 20-25 years ago are still there.
100% - Htmx may be viable for the simplest of sites, but once the complexity and requirements grow then this approach sux. Further, it ignores all the advances the browser has made in the last 20 years and we've gone back to IE 5.5 days.
This comment is hilarious in so many ways. You manage to be both an old man yelling at clouds and at the same time a naive junior dev who have not yet ran into the issues with modern web dev. Take a deep breath and relax. If you don't like something - don't use it! It is that easy.
As an old time dev for me it is the other way around. I am aware that each approach (client vs server side rendering) has its drawbacks. While I appreciate your comment in my experience it is just another approach. And if it isn't the right tool do not use it. We live in a wonderful time where we can choose from so many tools.
I don't see why it needs to be all or nothing for an experienced dev. Anywhere you want to leverage the browser/JS for interactivity instead you can, including having a JSON api, caching strategies, etc. Considering how much the frontend frameworks have moved towards SSR themselves, it seems there are good reasons for both approaches
Looks interesting, but no. Returning JSON is already kinda a standard. Today you have a browser as a client, tomorrow you have another one type of client that does not work with HTML. And here you go in this case. Use HTML as a data transport because it's comfortable to render in browsers without additional manipulations is an attractive but bad idea.
That's what he mentioned at the end. Although I don't think is that different, if you have a service that returns the resource you want to display, moving that service between a HTML view and and API endpoint shouldn't be hard.
@@chauchau0825 What?)) Where do you see "prematre optimization" in what I said?) Returning JSON is the simplest and direct way to interact with any web server. I would say the industry is going down because of this new "magic" ways, like: "we go back to 2013 where html response was ok.". In some sense, React was also kinda going back to php/jquery style but with the reactive stuff.
