[Pxtl]

> Forum websites mostly deliver non-interactive content

I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.

Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.

Is that the kind of thing you'd be giving up as you move to a platform like HTMX?

[geysersam]

Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/

[brabel]

It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.

[Rohansi]

It also doesn't actually work correctly - if you scroll too quickly it doesn't load more content. Possibly just a CSS issue on the example because the last row is not visible when scrolled to the bottom of the page due to the footer and its large margin.

[asdf88990]

It looks simple because first it is largely broken and second it moves half of the logic to the backend.

[arjie]

Infinite scroll is not a good tool for his use-case. Users will filter and then try to Cmd-F. They will get annoyed if you can’t search. It’s just bad UX. You can use infinite scroll for things like Twitter feed. Product search is just a different kind of UI.

[Pxtl]

I mean I'm not a front-end guy I was genuinely curious how well HTMX handles this kind of case.

[jimberlage]

I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.

Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.

[toddmorey]

Nope, HTMX could power endless scroll features if you want them

[egeozcan]

Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it.

If you want basic interactivity, HTMX is fine.

If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ )

And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever.

There is no golden rule to all of this but finding out what makes sense is a fun exercise.

[snorremd]

I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern.

But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.

I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.

But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.

[egeozcan]

I personally think that if you are adding a sortable component to a content-driven website, maybe it is moving away from being such a website. Normally a textarea should be enough for most people to order a "list" but if the list items have ids (they are entities), then that'd not suffice, and you may be going in the direction of a web application.

Otherwise, I'd recommend HMTX even if you have a super flexible JS backend.

That said, this is all baseless thinking without seeing any requirements and as I said before, trying to choose the right abstraction is the hard but fun part.

[Pxtl]

> There is no golden rule to all of this but finding out what makes sense is a fun exercise.

"Fun" as in you're years into a project before you fully accept that you made the bad call.

[egeozcan]

Dealing with bad choices is the most engineering task in software "engineering" :)

[Skinney]

How?

Everything served under one domain doesn’t have to use one technology.

Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.

As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.

[snorremd]

Indeed. In a publishing (Wordpress) like solution maybe you would use HTMX for the user facing parts and React or something similar for the more interactive admin parts. Then you don't need to bother with server side rendering for the admin bits, which at least I think simplifies React a great deal. It's not that the JS fullstack frameworks doesn't handle server side rendering and routing for you, but they feel very much like black box magic to me. Especially the new fangled React Server Components with the whole serialization and streaming model.

Good old server side rendering is simple in Rich Hickey's "Simple Made Easy" way. You can build more complex logic on top of a standard server rendered model, but the base model is mostly dead simple to reason about. I like that. I've built web "apps" in AngularJS, React, Reagent (ClojureScript) and Next. So I'm not coming at this from a grumpy "backender" position. I'm coming at this from having done lots of frontend stuff and finding the frameworks becoming increasingly complex beneath the surface. It feels like they are targeting the "easy" in Rich Hickeys parlance in the sense that you don't have to write a lot of code to make something fancy. But reasoning about the behavior and what actually happens in the framework when something doesn't work is increasingly difficult.

Edit: And maybe this is a "skill issue". If you just learn the framework and library well enough you'll get by much better. But I tend to not want to bind myself to any single framework too much. So simple frameworks that don't churn too much is better for me.

[atoav]

Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).

I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..

[Pxtl]

I'm specifically cranky about MS Azure Devops and how much lazy-loading and unloading of text it does. It's basically impossible to ctrl-F.

[fodkodrasz]

Also Github. Doing a review or searching logs is pain.

[SJC_Hacker]

Which is why you use git command line for such tasks

[fodkodrasz]

Where you can put comments on problematic lines/blocks of code easily with the git command... (Please continue, I'm really curious of there are better ways than what I'm currently doing)

[SJC_Hacker]

Use VS Code and download the git plugin. Tasks like that become super easy

[olvy0]

Yes! I suffer through this daily. It's atrocious.