Htmx Is Composable?(timkellogg.me)
timkellogg.me
Htmx Is Composable?
https://timkellogg.me/blog/2024/01/17/htmx
68 comments
One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely".
This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or framework which doesn't leave us much better off.
To be fair, I have not seen this stated as a goal or concern of HTMX anywhere. But, it's a concern of mine - I'm not going to build all my components from scratch all the time and this kills HTMX for me.
I guess what this would look like is an encapsulated backend module with internal templating and properties that allow controlling certain behaviours or routes. Definitely doable, not thought out at all.
This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or framework which doesn't leave us much better off.
To be fair, I have not seen this stated as a goal or concern of HTMX anywhere. But, it's a concern of mine - I'm not going to build all my components from scratch all the time and this kills HTMX for me.
I guess what this would look like is an encapsulated backend module with internal templating and properties that allow controlling certain behaviours or routes. Definitely doable, not thought out at all.
my position is that components for htmx are simply components for HTML: they should integrate with the DOM in the standard manner: attributes, input values and standard JavaScript events.
It doesn’t make sense to talk about “htmx components”, there are only html components that should play well with anything that respects the core web platform: unpoly, Hotwire, twinspark, data star, alpine Ajax or, heaven forbid, a vanilla HTML form.
I recognize this may hinder htmx adoption.
It doesn’t make sense to talk about “htmx components”, there are only html components that should play well with anything that respects the core web platform: unpoly, Hotwire, twinspark, data star, alpine Ajax or, heaven forbid, a vanilla HTML form.
I recognize this may hinder htmx adoption.
HTMX users just use existing JS components.
It's not an XOR proposition.
It's not an XOR proposition.
But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it.
Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents.
It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway.
I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.
Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents.
It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway.
I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.
No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool.
Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm.
It provides a more simple, basic service.
You may be tempted provide a django template + view + htmx reusable component.
Or a rail enpoint + htmx reusable component.
But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.
Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm.
It provides a more simple, basic service.
You may be tempted provide a django template + view + htmx reusable component.
Or a rail enpoint + htmx reusable component.
But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.
That's OK - but then I'd say I'm not interested in it based on its project scope.
I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.
I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.
And yet, and yet:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
https://htmx.org/essays/a-real-world-react-to-htmx-port/
I've read this and think it makes a ton of sense. I still think it's lacking an ecosystem strategy that would propel it further.
I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework.
It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition.
If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.
I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework.
It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition.
If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.
That's how engineering is supposed to work: you get to decide what to use based on your problems and the nature of the solutions.
Beyond the memes, this one Montana guy is very reasonable.
Beyond the memes, this one Montana guy is very reasonable.
Yeah, thats been my experience with it also. It works great for small things and getting going, but eventually the project starts to grow and you want to embed something that would be straightforward if you used a JS framework and then the spaghetti code starts as you bolt on a JS component inside of HTMX. After the 10th time you do this the project gets pretty messy and you want to just start from scratch with a conventional framework.
It's already like this for complex widgets, think of wysiwyg editors with file upload, usually it is necessary to provide a compatible backend for the file upload and management
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so.
And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.
Any open source project done in HTMX that has gone beyond TODO/LLM front ends etc could be interesting to look at
And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.
Any open source project done in HTMX that has gone beyond TODO/LLM front ends etc could be interesting to look at
> I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so.
When you use `hx-boost` (one of the most common uses), it does an ajax request, updates all the child elements, and updates the URL in the browser automatically.
When you use `hx-boost` (one of the most common uses), it does an ajax request, updates all the child elements, and updates the URL in the browser automatically.
This needs to be higher. Works normally without JS enabled and doesn't require any header fiddling. By far the easiest way to integrate htmx while keeping a consistent user experience.
How the heck does HTMX work without JS? And in this specific example, they're making an Ajax call! Also, the 'j' in Ajax stands for 'javasxript'
It doesn’t? Your site still does is the entire point.
Not every app is so complex that keeping address in sync with the UI requires complex logic. A lot of apps just want to update whats between the navbar and the footer without changing any of those. And URL needs to change from "/" to "/categories/". Sometimes you want to reload part of page as user clicks on tabs or side menu. Or load a content into a modal.
Keeping the url in sync can be done by tracking whether the request has the `HX-Request` header in it and then returning either a partial template or the full the template, example of the helper - https://github.com/Austionian/bl0g/blob/46182cf762e9acefc35e...
The great part of this, too, is caching these responses is still simple with the a `Vary: HX-Request`
The great part of this, too, is caching these responses is still simple with the a `Vary: HX-Request`
And, of course, with a 'Cache-Control: ...' header.
not everything needs the window url to be updated.
* Add a comment on the timeline and you don't need the url to be updated. * Open a new record and the url needs to be pushed to history
* Add a comment on the timeline and you don't need the url to be updated. * Open a new record and the url needs to be pushed to history
>not everything needs the window url to be updated.
The user needs it to be. It is the single most important handle of information for a layman. Of copying and pasting URL to someone else so that's kinda should be non negotiable for any pro user developer/engineer.
I find React to be too convoluted through its evolution multiple times over (plus the virtual DOM and horrendous ergonomics of hooks) but at the time, I'm pretty content with SvelteKit's way of doing things. Even in SPA mode, it keeps the whole thing in sync and the state management is awesome, comes built in, damn simple, just works.
But honestly, torn towards htmx but undecided.
The user needs it to be. It is the single most important handle of information for a layman. Of copying and pasting URL to someone else so that's kinda should be non negotiable for any pro user developer/engineer.
I find React to be too convoluted through its evolution multiple times over (plus the virtual DOM and horrendous ergonomics of hooks) but at the time, I'm pretty content with SvelteKit's way of doing things. Even in SPA mode, it keeps the whole thing in sync and the state management is awesome, comes built in, damn simple, just works.
But honestly, torn towards htmx but undecided.
The thing is... not everything needs the window url to be updated. Either because the URL is the same, or because you're pulling content that shouldn't/can't/won't be accessible with a direct URL.
For example:
For example:
- Blog: You add a comment to a blog post. The comment appears without reloading, and you don't need a new URL (because it's the same blog post)
- Menu navigation: You load menu items and/or children via htmx. That probably doesn't need a new URL.
- Ecommerce: You add/remove/modify products to/from your cart. The URL for the cart is still the same.For all your examples I can think of a reason to update the url in some or most scenarios. It depends.
New blog comment can be part of the url target with the comment id. Makes it easy to share and puts the scroll bar at the right position.
Menu navigation can be quite complex with nested modals, you might want to be able to deeplink for documentation/training purposes and highlight a selection.
With a cart you might want to add a ‘cart state/session’ id so you can share it with your spouse to quickly get to an agreement about stuff to order.
New blog comment can be part of the url target with the comment id. Makes it easy to share and puts the scroll bar at the right position.
Menu navigation can be quite complex with nested modals, you might want to be able to deeplink for documentation/training purposes and highlight a selection.
With a cart you might want to add a ‘cart state/session’ id so you can share it with your spouse to quickly get to an agreement about stuff to order.
> With a cart you might want to add a ‘cart state/session’ id so you can share it
That might not work for carts that work by temporarily 'booking' an item, like a seat for a cinema ticket. By definition, the cart is unique to a user.
That might not work for carts that work by temporarily 'booking' an item, like a seat for a cinema ticket. By definition, the cart is unique to a user.
My local cinema actually allows this but the cart-session is tied to the user session so when you share it the page goes to readonly mode where only the time and chosen seats are visible.
> But honestly, torn towards htmx but undecided.
We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.
Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.
It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.
[1] https://alpinejs.dev/
We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.
Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.
It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.
[1] https://alpinejs.dev/
I have not prototyped anything but I think that alpine-js + htmx can go long way for such apps. Especially, this is pretty interesting idea [0]
React... might be good but I am too weak to handle all that comes with it.
[0]. https://devdojo.com/pines
React... might be good but I am too weak to handle all that comes with it.
[0]. https://devdojo.com/pines
I've only just started getting into HTMX, but I think the point of it is more about hypermedia as the engine of application state. The response is a self contained declarative UI. The browser just has to stick the response in the right place. There is no need to interpret the response and create the UI based on it.
Yep.
https://hypermedia.systems/hypermedia-components/
And to avoid entire page rewrites, there is alway the option to inject a server response (html) into the top (or end) of comments for example.
https://hypermedia.systems/hypermedia-components/
And to avoid entire page rewrites, there is alway the option to inject a server response (html) into the top (or end) of comments for example.
> then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.
You don't need all of the tools you think you need. HTMX is reimagining SPAs by extending hypermedia. It doesn't yet extend as far as existing SPA frameworks, but it covers a much broader range than you think.
You don't need all of the tools you think you need. HTMX is reimagining SPAs by extending hypermedia. It doesn't yet extend as far as existing SPA frameworks, but it covers a much broader range than you think.
Doesn't this go against the philosophy though? I'd expect navigation to happen mostly with plain old html navigation
If you want the URL to be updated, just go and do a full request.
That doesn’t make sense because there’s millions of reasons to update the url even when navigating sub sections of the page or to reflect some sort of state that needs to be persistent when refreshed/shared.
> Years ago, in .NET and Java, it was popular to use an Inversion of Control container with XML configuration that declared and configured different classes and objects. I think it largely went out of style because it’s complicated, or at least more complicated than it needed to be.
In .NET anyway, this was replaced by use an Inversion of Control container with configuration as code. Because it's more flexible if you need that. And if you don't, it's just a boring (in the good sense) list of e.g.:
services.AddTransient<IFoo, FooService>();
services.AddScoped<IBar, BarService>();
services.AddSingleton<SomeType>();
// etc for many lines
This is definitely no worse than XML.
It's now as simple or as complicated as you want it to be. Using the same tools as the rest of the app code rather than a different syntax.
In .NET anyway, this was replaced by use an Inversion of Control container with configuration as code. Because it's more flexible if you need that. And if you don't, it's just a boring (in the good sense) list of e.g.:
services.AddTransient<IFoo, FooService>();
services.AddScoped<IBar, BarService>();
services.AddSingleton<SomeType>();
// etc for many lines
This is definitely no worse than XML.
It's now as simple or as complicated as you want it to be. Using the same tools as the rest of the app code rather than a different syntax.
I also don't think it's out of style if you have a .Net monolith. It's already there; there's no need to include or install anything. So people use it. It's a little too much magic for my taste, but people like magic.
In my experience in .NET recently, Inversion of Control containers are as popular as ever; typically just using the one that's "already there".
But it's the "config as a XML file" that is right out of style, in favour of config as code, for the reasons given.
But it's the "config as a XML file" that is right out of style, in favour of config as code, for the reasons given.
Having moved from .net to java recently, I have to say I miss the .net IoC ecosystem; things are simple and to the point, and you use the tools however best fits your use cases. In Java-land everything is Guice, which is more of a "framework"; it requires a lot more boilerplate and you have to design around it, and gets in your way any time you want to do anything outside of its golden path.
I'm not sure I fully understand the composable part. To me this seems like server-side rendered HTML on the one end (which indeed makes it easier to debug), and a react version on the other end. React would instead of passing the object directly to the renderer (as one can do when doing it all in one process), have some fetching mechanism.
In terms of composability, react seems more composable to me. I can delegate the distributed and state aspect to something like redux / redux query, and fully concentrate on the composable component system. The added benefit is of course to separate backend and frontend concerns, which might or might not be to your like or useful within a certain project's scope.
In terms of composability, react seems more composable to me. I can delegate the distributed and state aspect to something like redux / redux query, and fully concentrate on the composable component system. The added benefit is of course to separate backend and frontend concerns, which might or might not be to your like or useful within a certain project's scope.
I think the key feature of htmx that often people overlook is that you can update several elements with one html response
The attribute is the following: https://htmx.org/attributes/hx-swap-oob/
The attribute is the following: https://htmx.org/attributes/hx-swap-oob/
that's even easier to do in react though. If I say, update the cart, and update my cart state in redux, then every component rendering the cart (say, header, checkout component, shipping progress bar) will update seamlessly.
To me htmx seems weird in its mixing of logic / API separation layer with the UI separation layer. I can see it making sense on single/small team projects and appreciate the lack of bundling and async communication and all the issues JS entails, but composability is not the argument that makes sense to me.
To me htmx seems weird in its mixing of logic / API separation layer with the UI separation layer. I can see it making sense on single/small team projects and appreciate the lack of bundling and async communication and all the issues JS entails, but composability is not the argument that makes sense to me.
It definitely feels weird in htmx.
It is easier in React if you are using a centralised state manager, yes. I prefer it, it is more explicit. If you use Context to set state it can come from anywhere. In this sense, it is even easier in Elm, since if you use Elm you are using one (redux was inspired by it iirc) ;o)
I think htmx makes sense really at the html level, like rest (I believe that is the goal of the project), because it would be framework agnostic. Then some boilerplate on top would fix these issues. You could define some central state in a single place and generate all the references (hx swap oob attributes). The basis is solid imho.
The most attractive thing for me would be that it would stay stable (like rest), but I agree right now a subset of react (choose state manager, styling method, ssr, etc) is easier/quicker. It needs to be constantly updated, though, and dependencies can creep in quickly if a team is not disciplined enough.
I agree with the weirdness of mixing logic an ui. I remember when css, html, and js were supposed to be kept separate. Then components in jsx mixed them, and it was useful. If htmx proves useful, the mixing of concerns does not differ much (not the same but it rhymes)
It is easier in React if you are using a centralised state manager, yes. I prefer it, it is more explicit. If you use Context to set state it can come from anywhere. In this sense, it is even easier in Elm, since if you use Elm you are using one (redux was inspired by it iirc) ;o)
I think htmx makes sense really at the html level, like rest (I believe that is the goal of the project), because it would be framework agnostic. Then some boilerplate on top would fix these issues. You could define some central state in a single place and generate all the references (hx swap oob attributes). The basis is solid imho.
The most attractive thing for me would be that it would stay stable (like rest), but I agree right now a subset of react (choose state manager, styling method, ssr, etc) is easier/quicker. It needs to be constantly updated, though, and dependencies can creep in quickly if a team is not disciplined enough.
I agree with the weirdness of mixing logic an ui. I remember when css, html, and js were supposed to be kept separate. Then components in jsx mixed them, and it was useful. If htmx proves useful, the mixing of concerns does not differ much (not the same but it rhymes)
I am not a web dev, but I do it occasionally for fun, or want to put a script on the web, and when I saw htmx I was excited because I immediately grokked it and knew how to use it for my purposes. React looks cool, but intimidating for someone who is not a web dev. Maybe htmx is not for making big complex apps.
That's where looking at HTML as serialized state really helps. When a request changes the cart the server responds with chunks of HTML "state" for anything that changed.
In the shopping cart case, a user clicks Add to Cart and the server responds with an update for the button (maybe it has a success message) + new HTML for the cart item counter in your header. Sure that counter is technically UI, but the server is sending it because the state has changed and the client needs to patch in the update.
In the shopping cart case, a user clicks Add to Cart and the server responds with an update for the button (maybe it has a success message) + new HTML for the cart item counter in your header. Sure that counter is technically UI, but the server is sending it because the state has changed and the client needs to patch in the update.
Oh, I was wondering how to do this with HTMX! I wish the documentation was more verbose, and had some examples. It's a little hard to understand how to use with how minimal the docs are.
edit: just found the example. https://htmx.org/examples/update-other-content/
edit: just found the example. https://htmx.org/examples/update-other-content/
I think many "clean" abstractions are about making a certain layer (horizontals) in a tech stack is clean, whereas functional parts in actual applications are most cleanly separated as functional verticals. But if you follow a clean vertical separation you will run into issues when horizontals (like common styling in a web-app or coherent network failures handling in many applications ) isn't handled cleanly.
For really clean applications you want your design to be a DAG, focusing on horizontals or verticals often leaves people with messes when you violate DAG constraints in the other direction.
What the author has issues with is that React frontend-monoliths would need extra machinery to work with separate compilation steps to allow separate building of verticals, with something like HTMX it's fairly loose (And separately worked on verticals can easily co-exist).
I think that this is part of the big divide between people who came from classic web-dev backgrounds and more latecomers from other domains (often manifested by the love or hate of DHH and his anti-TS/React stance).
Web-dev people would naturally land on writing verticals (one page = one task) and whilst their common abstractions could be horrible (SQL everywhere) they accomplished tasks well but cleaning up architectural messes could be bad.
Classic developers outside of web often saw applications, servers,etc (horizontals) as their main unit and made those clean, keeping the horizontal clean (like network failure handling) would influence design decisions (often at the expense of vertical concerns).
React allows for composability internally but often re-introduces issues on a larger scale, like your Redux store needs to know about parts from perhaps both user-admin and more application specific tasks. Now this is fine if it's a separately distributed application (like a mobile app) but people used to just handle one vertical at a time might feel that it's a lot of extra work other more contained cases.
For really clean applications you want your design to be a DAG, focusing on horizontals or verticals often leaves people with messes when you violate DAG constraints in the other direction.
What the author has issues with is that React frontend-monoliths would need extra machinery to work with separate compilation steps to allow separate building of verticals, with something like HTMX it's fairly loose (And separately worked on verticals can easily co-exist).
I think that this is part of the big divide between people who came from classic web-dev backgrounds and more latecomers from other domains (often manifested by the love or hate of DHH and his anti-TS/React stance).
Web-dev people would naturally land on writing verticals (one page = one task) and whilst their common abstractions could be horrible (SQL everywhere) they accomplished tasks well but cleaning up architectural messes could be bad.
Classic developers outside of web often saw applications, servers,etc (horizontals) as their main unit and made those clean, keeping the horizontal clean (like network failure handling) would influence design decisions (often at the expense of vertical concerns).
React allows for composability internally but often re-introduces issues on a larger scale, like your Redux store needs to know about parts from perhaps both user-admin and more application specific tasks. Now this is fine if it's a separately distributed application (like a mobile app) but people used to just handle one vertical at a time might feel that it's a lot of extra work other more contained cases.
Oof, 4.5 MB for a decorative image.
I would have liked the article without the image more.
And even for that size it loads insanely slow, at least for me.
This reminded me that one thing I miss from WPF is the "free" render-time polymorphism.
If you had an interface, say ICard, and a few xaml data templates for how to render the concrete types, all you had to do was bind to a collection of ICards and it would automatically do what I guess we'd now call pattern matching on the concrete type of each element to render it without needing to mix the presentation with the plain old c# objects.
If you had an interface, say ICard, and a few xaml data templates for how to render the concrete types, all you had to do was bind to a collection of ICards and it would automatically do what I guess we'd now call pattern matching on the concrete type of each element to render it without needing to mix the presentation with the plain old c# objects.
Why did WPF go out of style? (or did it? idk) It seems like a good pattern, but it's always good to look at historical cases for the gotchas
Microsoft stopped investing in it for a time and generally less focus on desktop technologies over the years. It’s still fairly popular in .NET shops as far as I can tell with spiritual successors like Avalonia
XAML is not a learn in a weekend type of deal and most dev don’t want to put the time to reading a proper book to learn it.
When I was last dabbling with WinUI/Win App SDK it honestly never even crossed my mind to read a book, but in retrospect that sounds like a good idea. Figuring out how to do X basic thing in XAML through googling was frustrating largely due to how many different flavors of XAML exist now.
Microsoft's desktop strategy has been a disaster.
If I had to guess? A bad decision and then sunk cost. If for their cross platform story they'd gone the avalonia route and developed cross platform wpf they would have been miles ahead of wherever they are now with their three or four competing underfunded ideas. Then wasm as a target might eventually have even fallen into their laps.
They have good execution in general but their strategy in this space is closer to a "12 startups in 12 months" style approach.
If I had to guess? A bad decision and then sunk cost. If for their cross platform story they'd gone the avalonia route and developed cross platform wpf they would have been miles ahead of wherever they are now with their three or four competing underfunded ideas. Then wasm as a target might eventually have even fallen into their laps.
They have good execution in general but their strategy in this space is closer to a "12 startups in 12 months" style approach.
Something about this feels really at odds with all the "locality of behavior" virtue the creator/maintainer often promotes.
Yep, and as soon as you need non-local updates, the whole concept of HTML-over-the-wire starts breaking down. I really like this HN comment on this topic: https://news.ycombinator.com/item?id=38081174
As mentioned in that comment, there is hx-swap-oob, but there is also the official htmx multi-swap extension that makes this pretty trivial.
https://htmx.org/extensions/multi-swap/
In that example, you'd just send partials for the card and cart elements and they'll both be swapped out.
https://htmx.org/extensions/multi-swap/
In that example, you'd just send partials for the card and cart elements and they'll both be swapped out.
If we continue the cart example, what should HTTP endpoint return in that case?
In this example, the html for the card which looks different and the cart with the updated count could be returned. HTMX will swap both with the appropriate element based on the ids of the elements in the Dom and the elements being returned by the server and this won’t cause a whole page refresh or anything.
For the folks who have been writing these inline HTML views and been wishing to have a more composable way of generating HTMX like in this blogpost try https://github.com/maxpert/htmxido
I couldn't get it to work with single-spa, which is what our company's UI framework uses to compose components built by different teams.
It seems like the two approaches are at odds with each other anyway, so perhaps this won't ever be possible.
It seems like the two approaches are at odds with each other anyway, so perhaps this won't ever be possible.
> HTMX as Configuration
Bam, there you are, can't make programs with just configuration, that's a wet dream.
The article also mentions IoC configuration, which is a horrible way to program, another thing that is only good on paper.
Bam, there you are, can't make programs with just configuration, that's a wet dream.
The article also mentions IoC configuration, which is a horrible way to program, another thing that is only good on paper.
Feedback to author:
The diagram and explanation took a beat longer than normal to scan, since this buries a bit that it's not about the beautiful source control system called fossil shipped as a composition of modules:
https://fossil-scm.org/home/doc/trunk/www/index.wiki
Great diagrams, so of course that's the first thing a reader will skim. Reader thinks people build things based on git all the time, the diagram looks like it's based on fossil, cool, scan more...
Making it take a bit longer when scanning upwards from the diagram, the Mastodon client is introduced without naming it until an aside at the end of the paragraph:
> Before the New Year I decided to hack on an idea. I wanted a social media client for Mastodon that displays my feed in a way that suits me ... I call it Fossil.
If you missed that at the end and scan back down to the arch section, it mentions fossil without really saying it's the social media app:
> With fossil plugins, it’s become straightforward to work on any part of the stack:
- UI elements — write verbatim HTML or Jinja templates, packaged into a plugin
- API endpoints — register them via a decorator API
- DB tables — Create them during plugin initialization
- AI algorithms — register them via the API
- fossil
> That’s neat. The whole stack.
I'd edit three things:
+ "...social media client for Mastodon I call ‘Fossil’ that displays my feed..."
+ "With plugins for my Fossil app..."
+ "- fossil mobile app"
The diagram and explanation took a beat longer than normal to scan, since this buries a bit that it's not about the beautiful source control system called fossil shipped as a composition of modules:
https://fossil-scm.org/home/doc/trunk/www/index.wiki
Great diagrams, so of course that's the first thing a reader will skim. Reader thinks people build things based on git all the time, the diagram looks like it's based on fossil, cool, scan more...
Making it take a bit longer when scanning upwards from the diagram, the Mastodon client is introduced without naming it until an aside at the end of the paragraph:
> Before the New Year I decided to hack on an idea. I wanted a social media client for Mastodon that displays my feed in a way that suits me ... I call it Fossil.
If you missed that at the end and scan back down to the arch section, it mentions fossil without really saying it's the social media app:
> With fossil plugins, it’s become straightforward to work on any part of the stack:
- UI elements — write verbatim HTML or Jinja templates, packaged into a plugin
- API endpoints — register them via a decorator API
- DB tables — Create them during plugin initialization
- AI algorithms — register them via the API
- fossil
> That’s neat. The whole stack.
I'd edit three things:
+ "...social media client for Mastodon I call ‘Fossil’ that displays my feed..."
+ "With plugins for my Fossil app..."
+ "- fossil mobile app"
The author of the article needs to read this
https://youryoure.com/?its
Sometimes people are just in a rush or just a bit careless, much like you were here: https://news.ycombinator.com/item?id=38879565 . It really isn't the end of the world.
Glass houses, and all that.
Glass houses, and all that.
I agree with the spirit of your comment, but I do think the bar for proof-reading published material (like a blog post) should be much higher than the bar for informal communication (like a forum comment).
nah, it's just proof that I didn't LLM my blogs into existence ;)
Does your backend has components? Does your scripting toolkit has components?
HTMX doesn't care either way, and will use whatever you give it.
You can pick reusable django forms, alpine js, some manually created boundaries, a jquery module... You can even drop react on a single page because there is a widget you like and it's not loaded often.
People may be tempted to talk about HTMX using irrelevant points of references.
It's not providing an SPA with a component architecture, that's the point.
The readers that are very used to modern JS stacks and never had to deal with the web before 2010 may want to read:
https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1
This will give a better idea of how to think in HTMX, which is just a new trick for an old dog.
It's better to use this tool for what it is, with its limits and strengths rather than trying to make it into something it's not.
The reason HTMX can't do many things react is good at is because it's by nature the opposite of react.