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

171–180 of 224 posts

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

#171

Post by foxygen »

sjoedev wrote: post #160
foxygen wrote: post #132

Earlier quoted context omitted.

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

Sure. I personally think SPAs/React have better DX than HTMX. IMO, the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster. These are UX concerns: how much the user has to download (waiting) and how long before the page becomes interactive (waiting). With HTMX, you get these b…

> the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster

Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of React. I understand using HTMX if you are building a backend in Go/Python/..., but if you are already using Node, I see no reason not to use TanStack Start instead.

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

#172

Post by LVB »

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.

Swag looks interesting and I'm definitely gonna give it a try!

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

#173

Post by bfjvibybd6cuvu6 »

asdfsa32 wrote: post #5

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamenta…

[flagged]

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

#174

Post by tored »

james2doyle wrote: post #155
sequoia wrote: post #149

Earlier quoted context omitted.

I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all. Why does the form need rerendered on a per req…

Because the form changed based on the selections you made. Like facet search. Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable opt…

Did you try out-of-bound swap (oob) in HTMX? With that you can update any element on page, e.g. three different form elements changed due to change, request returns only these three form elements with oob selectors and keep the rest of the form intact.

https://htmx.org/attributes/hx-swap-oob/

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

#177

Post by yawaramin »

james2doyle wrote: post #146
WD-42 wrote: post #136

Earlier quoted context omitted.

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?

To sync the form state based on the current selections in the form. This is often called facets. The form contained many options and as you filtered those options would change. So you need a way to update the form too. Hence, compute the full thing on the server (the form state, the options within the fields, and the results) then send it all back.

Can be done by updating the form fields dynamically as they are edited. Doesn’t need to be done all in one shot. Eg: on blur of each field, send an htmx request and update the other fields. On form submit with htmx, send only the results partial.

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

#178

Post by yawaramin »

foxygen wrote: post #171
sjoedev wrote: post #160

Earlier quoted context omitted.

Sure. I personally think SPAs/React have better DX than HTMX. IMO, the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster. These are UX concerns: how much the user has to download (waiting) and how long before the page becomes interactive (waiting). With HTMX, you get these b…

> the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of Rea…

Maintenance burden, supply chain attacks and the constant dependency upgrade treadmill. With a very minimal footprint app, you can avoid all that to a large extent.

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

#179

Post by gulugawa »

dsego wrote: post #106
asdfsa32 wrote: post #7

Earlier quoted context omitted.

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…

An islands architecture can be implemented with web components when hydration is needed.

Writing vanilla JS to manage state and backend data loading can be done with a script that is less than 2kB zipped. The script can then be reused.

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

#180

Post by yawaramin »

asdfsa32 wrote: post #42
xutopia wrote: post #39

Earlier quoted context omitted.

Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most…

Because "simple" is transient at best and a lie at worst. But for more details, see the sibling comment: https://news.ycombinator.com/item?id=49069477

Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.
Post reply on HN