Hacker News Reader

Comment by asdfsa32 | Hacker News Reader

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 decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does.

If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.

View on HN

As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense.

The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.

It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.

Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes.

In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.

> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.

Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...

Every one of those are things that the browser manages for you if you are using semantic markup and embracing web standards.

This is a pipe dream. Browsers have come a long way but they're largely still broken in many many ways.

Would love to hear about which of those listed examples does not currently have native browser support.

> what the user is currently typing

Easy as pie. We don't even have to get into the specific of making things work correctly.

I don't understand what is broken with the browser's management of typed content. Do you have an example of UX that requires a custom state management layer on top?

Sorry, no. You can not make such assertions yet have little experience with dealing with complex UIs in web.

Input management is one of the most difficult aspects of web development once you want anything beyond a simple input. That you have to ask for an example means this conversation isn't going anywhere. Good luck!

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.

The only nonsense here is ignoring that 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.

The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.

One key part of good frontend engineering is picking tools to effectively solve current challenges your product is facing. Thinking about theoretical problems that may not apply to you is a waste of time.

I don't currently use use HTMX. However, that doesn't invalidate the use of htmx by others when it is a better fit for their experience and use cases.

htmx is no more invalid than Visual Basic, and the parallels goes deeper than that.

If you really think HTMX and Angular 1.0 are equivalent then…actually I don’t even know where to begin.

Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you never mastered CDN's or the exact opposite? It certainly doesn't lead any credibility the assertion that A will become Z because they look similar or embrace similar ethos.

You need to read things in the context, Chicken.

But I will answer your main questions since your comment seems to be in good faith.

Just like angular 1 choked on complex, high-frequency UIs, HTMX is going to follow the same faith. Github uses a similar approach to HTMX and you will find that even for such a simple system, their notification indicator elements on the same page are often out of sync.

The reasons for this is that State Management is hard, which is why the reconciliation loop of React-like frameworks and shadow-dom does away with pushing complex state management to user application and handles it systematically.

Of course, this doesn't mean htmx is useless, for a specific case of web apps, it is good enough, but the problem is that often times, you start with "specific cases" and your application grows overtime.

So when you consider that and the cost of doing htmx vs React or any react-like framework, picking htmx is only reasonable if it is the only option you're comfortable with and rarely on merit.

Reply on news.ycombinator.com