maybe you can send me to the right tutorial. I'm a backend, distributed systems engineer. I have worked on eye-watering scale. React is anything but simple to me.

I tried create-react-app, the thing built and downloaded for several minutes, and then there was a nest of file relationships that I didn't grok. It seemed like any change required three files to be updated. Lots of ancillary things like bundlers, packers, tree shakers, lions, tigers, and bears, oh my. After an hour, I didn't get what I was doing. Somehow, altering this function over here made this other thing over there go "moo."

I used to do web development back in like 2001. I understand the web, http, css, html, and basic js. I'm not up on all the latest, but I have a very firm base.

I got htmx working and pretty much fully digested in the same amount of time I wasted on React and have produced a working prototype. I find htmx to be like how the web used to be. It makes sense.

FWIW, create-react-app is overloaded with every package you could ever potentially want to use for some weird reason. It's way overkill and I wouldn't recommend using it.

It's much better just to use Vite with React as a plugin. Then you only need to install three React packages to get your app going.

The best tutorial I've used was "Road to React" by Robin Weiruch. His example app you learn is how to build a Hacker News front page. Very clear and it goes step by step.

Most of the tutorials online are all over the place, or mix Class tutorials with Hooks tutorials, or starts adding in things like Redux (which aren't needed).

The person you're responding to is correct, at it's core React is very simple, especially if you just stick to hooks. Most of my code is just bog standard HTML (as JSX), CSS and JS with a few React hooks thrown in.

FWIW, I've been doing frontend dev since '94 and personally find React jives the most for me and how normal HTML/JS/CSS work. I can see why people would like HTMX, but I've never liked overloading HTML attributes as some strange event model. But it's good there are choices.

React has very good documentation and an excellent tutorial. Here is a link to it: https://react.dev/learn . I recommend doing the exercises. They really help you learn React.

Create React App should not be used because it is no longer maintained. Here is its GitHub repro: https://github.com/facebook/create-react-app/commits/main/ . It has had very few updates since July 2022. This is bad because it needs constant updates because it depends on a large number of packages and those packages are constantly releasing security updates.

That doesn't sound like a good selling point for react.

create-react-app is not react

While true, if cargo was exploitable we'd say it was rust.

To be fair, this would be more analogous to some random person creating a crate called 'create-rust-app' and then abandoning it. Hardly a signal that Rust is dead.

Never said it was saying react/rust were dead, I said it "doesnt look good". Those words were not in my mouth.

I understand your confusion and dismay over React because I'm myself a backend developer and the kind of complexity doesn't exist in backend tech stack.

But this all or none of it has anything to do with React rather with a broken language design which never imagined anyone would write JavaScript worth more than a few paragraphs in a single file.

That's where tons of bundlers come into play from parcel and webpack to vite.

But then there are some language extensions that must be transpiled before they can be bundled. Your JSX comes to mind.

Typescript can be considered in the same league.

Minus all that - Modern React has a very minimal surface area, very few concepts and that's about it.

> Modern React is too simple. A component is just a pure function

React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user...").

You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway.

(I'm saying that as someone who generally likes React and would choose it for a new project)

useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.

> The only other thing you need to know is few hooks.

And where you can't use them. Hopefully there are zillions of YT videos from experts teaching you all react gotchas.

> The only other thing you need to know is few hooks.

...and then draw the rest of the owl.

try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D

Except when your state appears in many parts of the page, HTMX makes it hard to keep everything updated.

Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.

agreed: htmx is good for "swap out this one element and its children". It is not good for "and these other related elements need to update"

> It is not good for "and these other related elements need to update"

That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.

Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier

To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.

Not any more complicated than passing parameters to a function.

If that is actually the case, there is an issue with your component design.

You pull the state up. Props down.