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

191–200 of 224 posts

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

#191

Post by Skinney »

shooly wrote: post #47
xutopia wrote: post #31

Earlier quoted context omitted.

I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads. People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal H…

> loading times What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB. > You cannot argue that React is extremely heavy and also adds a lot of time between first render Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the…

React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself.

So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly.

If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.

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

#192

Post by evilduck »

gulugawa wrote: post #179
dsego wrote: post #106

Earlier quoted context omitted.

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.

At that point, gzipped Preact is only 1k larger (and 10k smaller than htmx) and provides a pretty comprehensive and common set of solutions to the majority of front end problems compared to hand rolling everything.

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

#193

Post by bbkane »

prologic wrote: post #166
bbkane wrote: post #140

Earlier quoted context omitted.

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

Yes! Check out https://swag.mills.io and the examples in the repo.

Thank you, will check this out

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

#194

Post by fodkodrasz »

SJC_Hacker wrote: post #187
fodkodrasz wrote: post #134

Earlier quoted context omitted.

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

Which is why you use git command line for such tasks

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)

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

#195

Post by brabel »

zx8080 wrote: post #161
brabel wrote: post #135

Earlier quoted context omitted.

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.

No worse thing for ux as the infinite scroll. As it breaks the native cmd-f/ctrl-f page search and makes loading progressively slow.

It doesn't do such thing at all, unless you think it's acceptable to load EVERYTHING in HTML, hide it, and do front-end search. Which would be completely nuts to do for things where infinite scroll is used.

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

#196

Post by ifwinterco »

xutopia wrote: post #31
ifwinterco wrote: post #25

Earlier quoted context omitted.

Why would react fail for higher traffic pages? If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version. Most of the tim…

I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads. People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal H…

Yes it’s true that for a landing page (relatively simple site, most users are unique) React is not the natural choice.

It can probably be made to work well if written by people who know what they’re doing using SSR, but it’s not what React was originally designed for

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

#198

Post by snorremd »

Skinney wrote: post #189
Pxtl wrote: post #128

Earlier quoted context omitted.

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

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.

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.

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

#199

Post by sgt »

asdf88990 wrote: post #151
sgt wrote: post #75

Earlier quoted context omitted.

Having adopted Angular 1 back when it was new, I can promise you it's completely different than Htmx.

What is the main difference?

The main difference is that htmx is server driven, and it's HATEOAS (hypermedia driven). Angular was always client side only with data binding and state management. So as far as frameworks go, they are pretty much as different as they come.

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

#200

Post by sgt »

dsego wrote: post #110
skeptic_ai wrote: post #17

Earlier quoted context omitted.

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.

This is probably true, but I'm pretty happy just using the template engine on the server side and keeping thing DRY as much as possible. Htmx is still going to be faster by orders of magnitude to write and maintain, so choose where to spend your innovation tokens.
Post reply on HN