Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is Composable?

timkellogg.me

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Htmx Is Composable?

#21

Post by wg0 »

thomassharoon wrote: post #17
wg0 wrote: post #14

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 ha…

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

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

Re: Htmx Is Composable?

#23

Post by lazypenguin »

tkellogg wrote: post #11
jddj wrote: post #4

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 pl…

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

Re: Htmx Is Composable?

#24

Post by zaphod420 »

wg0 wrote: post #14

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 ha…

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.

Re: Htmx Is Composable?

#25

Post by Ralfp »

wg0 wrote: post #14

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 ha…

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.

Re: Htmx Is Composable?

#26

Post by tecleandor »

wg0 wrote: post #21
thomassharoon wrote: post #17

Earlier quoted context omitted.

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

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

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.

Re: Htmx Is Composable?

#27

Post by thomassharoon »

zaphod420 wrote: post #24
wg0 wrote: post #14

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 ha…

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.

Re: Htmx Is Composable?

#28

Post by daxfohl »

SideburnsOfDoom wrote: post #6
brodo wrote: post #5

Earlier quoted context omitted.

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.

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.

Re: Htmx Is Composable?

#29

Post by thomassharoon »

wg0 wrote: post #21
thomassharoon wrote: post #17

Earlier quoted context omitted.

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

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

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

Re: Htmx Is Composable?

#30

Post by lucasyvas »

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.

Post reply on HN