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

131–140 of 224 posts

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

#131

Post by rubyfruit »

christophilus wrote: post #113
rubylimetea wrote: post #112

As others mentioned, not great for rich interactivity. Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal. React is designed around that kind of thing. They do some funny magic under the hood to support seamless DO…

I haven’t used it with htmx, but DOM morphing seems like it’s probably a good solution to this. https://v1.htmx.org/extensions/morphdom-swap/

https://github.com/patrick-steele-idem/morphdom/issues/261

This issue is reporting the same kind of thing - text selection is lost on re-render

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

#132

Post by foxygen »

sjoedev wrote: post #72
foxygen wrote: post #60

Earlier quoted context omitted.

What is the point of using HTMX if your backend is JavaScript(Hono)?

Adopting something like HTMX is primarily a UX choice, and the language you use to serve it is almost irrelevant to UX. JavaScript is a nice backend language. It’s fast, has a massive ecosystem, and many people know it well.

I don't see how HTMX has anything to do with UX. Could you clarify what you mean?

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

#133

Post by Rohansi »

brabel wrote: post #98
geysersam wrote: post #76

Earlier quoted context omitted.

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

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.

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.

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

#134

Post by fodkodrasz »

Pxtl wrote: post #101
atoav wrote: post #94

Earlier quoted context omitted.

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.

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

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

#135

Post by brabel »

tclancy wrote: post #104
brabel wrote: post #96

Earlier quoted context omitted.

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?

It was a genuine question. I’ve implemented infinite scrolling in HTMX and it’s quite easy, another commenter posted an example from the HTMX docs and it’s a couple of lines of html.

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

#136

Post by WD-42 »

james2doyle wrote: post #126
dsego wrote: post #118

Earlier quoted context omitted.

I think I understand now, even the partial required submitting everything to the server, which can be skipped if you can have interactivity without unnecessary requests.

Exactly. The partial response was 100kb-200kb of HTML + the backend query time. Of course, depending on your filters. But a large chunk of that was just sending down the form on the left side, which I already had on page load, so that penalty was real. It was only the right side results of the experience that needed to be refetched when the form changed. But in HTMX, you are expected to just send the whole dang thing…

Why are you expected to send down the whole thing? Maybe I’m missing something, but when you send the request from the form the response is just a partial of the results on the right hand side, using hx-target to specify some div instead of replacing the form. Form just stays there?

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

#137

Post by rubyfruit »

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.

I've been saying for years: All buildings should be parking garages.

Because you can always just put a mini residential building inside a parking garage if you need tenants.

Need an office? Just put a mini office in the parking garage. It's perfect.

Parking garage construction is so clean and simple. Other buildings are too complex! From now on, I'll only build parking garages.

(Then I guess you have the opposite example of the residence without the parking garage! It's a great place to live, but there's nowhere to store my things and park my car!)

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

#138

Post by austinthetaco »

shooly wrote: post #54
epolanski wrote: post #48

Earlier quoted context omitted.

> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX. That's how interactivity has alway…

> React/Vue/etc solve a specific problem: single-page application That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates. Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the curren…

> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.

This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.

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

#139

Post by rubyfruit »

skeptic_ai wrote: post #103

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

MISAGO MONGO DJANGO BUN

WHY WILL NOT MY FORUM RUN

MISAGO MONGO DJANGO BUN

PERFECT CONFIGURATION

MISAGO MONGO DJANGO BUN

IF YOU ARE THE CHOSEN ONE

MISAGO MONGO DJANGO BUN

REWRITE MY APP AND MAKE IT RUN!

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

#140

Post by bbkane »

prologic wrote: post #59
johsole wrote: post #55

Earlier quoted context omitted.

I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc. Have you found nice workarounds for that?

You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it). If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.

Any chance you could write a hello world repo of this stack and post a link here?
Post reply on HN