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

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

misago-project.org

Post reply on HN
Print view View original

101–110 of 224 posts

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#101

Post by Pxtl »

atoav wrote: post #94
Pxtl wrote: post #71

Earlier quoted context omitted.

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

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

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.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#102

Post by dsego »

james2doyle wrote: post #91

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

You can always make the server-side render partials based on a request header.

https://github.com/dsego/ssr-playground/blob/main/src/server...

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#103

Post by skeptic_ai »

> A lot of pages in Misago are implemented twice: as Django templates and React.js components.

I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx.

> there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that

Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#104

Post by tclancy »

brabel wrote: post #96
james2doyle wrote: post #91

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??

Want to help rather than throw tomatoes?

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#105

Post by Exoristos »

inigyou wrote: post #97
ko27 wrote: post #67

Earlier quoted context omitted.

It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.

An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.

They don't have to be that way.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#106

Post by dsego »

asdfsa32 wrote: post #7
sgt wrote: post #6

Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.

Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.

Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#107

Post by Exoristos »

asdfsa32 wrote: post #7
sgt wrote: post #6

Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.

Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.

Astro then.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#108

Post by Capricorn2481 »

brabel wrote: post #96
james2doyle wrote: post #91

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??

Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#109

Post by egeozcan »

snorremd wrote: post #90
egeozcan wrote: post #81

Earlier quoted context omitted.

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…

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

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.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#110

Post by dsego »

skeptic_ai wrote: post #17
sgt wrote: post #6

Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.

That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.

I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
Post reply on HN