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

31–40 of 224 posts

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

#31

Post by xutopia »

ifwinterco wrote: post #25
xutopia wrote: post #12

Earlier quoted context omitted.

Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.

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 HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are.

People use React today out of habit rather than because it's the best tool for the job.

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

#32

Post by asdfsa32 »

prologic wrote: post #24
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've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).

LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality.

In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

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

#33

Post by xutopia »

asdfsa32 wrote: post #15
xutopia wrote: post #12

Earlier quoted context omitted.

Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.

How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half…

Angular being basically the same HTMX is nonsense and you should know better.

Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones.

"High traffic" might be the simplified view here and it took me a few page memos to explain it to my lead but the gist is that React is slower, takes longer to load and most of what it is used for is easily done with plain HTML and sprinkles of JS as needed. Unless you're streaming sound or video like you do on Facebook pages it's really not the right tool for the job in a majority of cases.

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

#34

Post by asdfsa32 »

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…

This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.

But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.

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

#36

Post by greenchair »

asdfsa32 wrote: post #32
prologic wrote: post #24

Earlier quoted context omitted.

I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).

LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality. In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

right, so use the right tool for the job. most apps are boring CRUD apps and dont support chat.

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

#37

Post by stymaar »

asdfsa32 wrote: post #18
skydhash wrote: post #16

Earlier quoted context omitted.

It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state ui relationship is worth it.

A text editor or music player is hardly "mini". Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.

> A text editor or music player is hardly "mini".

If it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”.

For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context.

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

#38

Post by Levitz »

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.

That "massive hack" is supposed to be one of the core features of React.

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

#39

Post by xutopia »

asdfsa32 wrote: post #34
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…

This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes…

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 pages aren't streaming anything.

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

#40

Post by asdfsa32 »

monooso wrote: post #29
asdfsa32 wrote: post #14

Earlier quoted context omitted.

I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatch…

> Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management..…

> You may have stabilised on JSX, "we" have not.

Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%.

So I am not sure what "we" you are talking about.

Post reply on HN