6 ms·

Htmx Is Composable?

85 points by tkellogg 3y ago

SideburnsOfDoom 3y ago
> 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.
- brodo 3y ago
  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.
  - SideburnsOfDoom 3y ago
    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.
    - daxfohl 3y ago
      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.
larve 3y ago
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.
- mejutoco 3y ago
  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/ https://htmx.org/attributes/hx-swap-oob/
  - larve 3y ago
    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.
    - mejutoco 3y ago
      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)
jddj 3y ago
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.
- tkellogg 3y ago
  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
  - metaltyphoon 3y ago
    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.
    - jwells89 3y ago
      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.
  - lazypenguin 3y ago
    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
  - jddj 3y ago
    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.
chupapimunyenyo 3y ago
The author of the article needs to read this https://youryoure.com/?its https://youryoure.com/?its
- detritus 3y ago
  Sometimes people are just in a rush or just a bit careless, much like you were here: https://news.ycombinator.com/item?id=38879565 https://news.ycombinator.com/item?id=38879565 . It really isn't the end of the world. Glass houses, and all that.
  - antonyt 3y ago
    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).
- tkellogg 3y ago
  nah, it's just proof that I didn't LLM my blogs into existence ;)
kugelblitz 3y ago
Oof, 4.5 MB for a decorative image.
- reportgunner 3y ago
  I would have liked the article without the image more.
- matrss 3y ago
  And even for that size it loads insanely slow, at least for me.
wg0 3y ago
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
- naasking 3y ago
  > 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.
- thomassharoon 3y ago
  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
  - wg0 3y ago
    >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.
    - tecleandor 3y ago
      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: - 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.
nsonha 3y ago
> 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.
maxpert 3y ago
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 https://github.com/maxpert/htmxido
lucasyvas 3y ago
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.
- BiteCode_dev 3y ago
  HTMX users just use existing JS components. It's not an XOR proposition.
  - lucasyvas 3y ago
    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.
    - BiteCode_dev 3y ago
      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.
daxfohl 3y ago
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.
BiteCode_dev 3y ago
HTMX is neutral to composability, since it's limited to connecting and orchestrating parts of a system that may or may not chose to provide components. 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 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.
Terretta 3y ago
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 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"
betenoire 3y ago
Something about this feels really at odds with all the "locality of behavior" virtue the creator/maintainer often promotes.
- sesm 3y ago
  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 https://news.ycombinator.com/item?id=38081174
  - paranoidxprod 3y ago
    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/ 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.
    - sesm 3y ago
      If we continue the cart example, what should HTTP endpoint return in that case?
      - paranoidxprod 3y ago
        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.

85 points by tkellogg 3y ago

> 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.

brodo 3y ago
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.
- SideburnsOfDoom 3y ago
  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.
  - daxfohl 3y ago
    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.

larve 3y ago

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.

mejutoco 3y ago
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/ https://htmx.org/attributes/hx-swap-oob/
- larve 3y ago
  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.
  - mejutoco 3y ago
    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)

jddj 3y ago

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.

tkellogg 3y ago
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
- metaltyphoon 3y ago
  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.
  - jwells89 3y ago
    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.
- lazypenguin 3y ago
  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
- jddj 3y ago
  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.

chupapimunyenyo 3y ago

The author of the article needs to read this https://youryoure.com/?its https://youryoure.com/?its

detritus 3y ago
Sometimes people are just in a rush or just a bit careless, much like you were here: https://news.ycombinator.com/item?id=38879565 https://news.ycombinator.com/item?id=38879565 . It really isn't the end of the world. Glass houses, and all that.
- antonyt 3y ago
  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).
tkellogg 3y ago
nah, it's just proof that I didn't LLM my blogs into existence ;)

kugelblitz 3y ago

Oof, 4.5 MB for a decorative image.

reportgunner 3y ago
I would have liked the article without the image more.
matrss 3y ago
And even for that size it loads insanely slow, at least for me.

wg0 3y ago

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

naasking 3y ago
> 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.
thomassharoon 3y ago
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
- wg0 3y ago
  >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.
  - tecleandor 3y ago
    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: - 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.

nsonha 3y ago

> 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.

maxpert 3y ago

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 https://github.com/maxpert/htmxido

lucasyvas 3y ago

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.

BiteCode_dev 3y ago
HTMX users just use existing JS components. It's not an XOR proposition.
- lucasyvas 3y ago
  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.
  - BiteCode_dev 3y ago
    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.

daxfohl 3y ago

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.

BiteCode_dev 3y ago

HTMX is neutral to composability, since it's limited to connecting and orchestrating parts of a system that may or may not chose to provide components. 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 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.

Terretta 3y ago

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 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"

betenoire 3y ago

Something about this feels really at odds with all the "locality of behavior" virtue the creator/maintainer often promotes.

sesm 3y ago
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 https://news.ycombinator.com/item?id=38081174
- paranoidxprod 3y ago
  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/ 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.
  - sesm 3y ago
    If we continue the cart example, what should HTTP endpoint return in that case?
    - paranoidxprod 3y ago
      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.