[westoncb]

> do you really need all this to make a UI

This only makes sense for a very narrow conception of the range of UI problems. If your UI is just a basic form or trivially reflecting database structure in a CRUD app, then you would have little to no need for React.

If you were to try building e.g. the full Gmail UI and make the attempt with e.g. document.querySelector (or jquery) and again with React you would have a painfully clear understand of the necessity. (And I've selected Gmail here not as an extreme example, but rather as typical of the kind of thing I've seen React getting used to build.)

As far as needing "all this," there seems to be a misconception: React is actually quite compact. If you take into account its entire history (as you might have to if maintaining a legacy codebase), you'd find some inelegant redundancy (mostly just supporting both class and function components)—but if you're just grabbing the latest version and using it for an appropriate problem, I think someone with a sense for good system design would have few complaints.

[makotech221]

Unfortunately for your argument, Gmail was far superior before the big 'app' rewrite.

[westoncb]

If my argument were that the new version of Gmail was better than the old one, and if the old version being "far superior" had some objective grounding—then you might be on to something.

But that wasn't my argument at all. Gmail isn't even written with React. And if it were it would still be irrelevant: I'm not arguing "writing a program in React means it will be a good and well-designed program"; I'm saying if you write the same complex program twice, once with built-in browser APIs and once with React, you will on average find that the React implementation is far quicker to write, more concise, fewer bugs, and so on.

[mdoms]

> if you write the same complex program twice, once with built-in browser APIs and once with React

That's a false dichotomy.

[westoncb]

I suppose one might arise if I were claiming those were the only two options. But on a closer re-reading you'll easily find that's not the case.

[aaronbrethorst]

Nah, disagree. Case in point is Basecamp’s Hey product. Rails monolith. Server side rendered. JavaScript ‘sprinkles’ with Hotwire. https://twitter.com/dhh/status/1275901955995385856?s=21

[westoncb]

What I can find on "Hey" so far looks extremely basic as far as UI goes.

And by all means, if what you're building only requires a very basic UI—absolutely go for it.

My argument is that when you're faced with is an intrinsically difficult UI problem, React (or similar FRP-inspired frameworks which the community has stabilized around) is a huge improvement over the "simpler" past way of doing it. And the only way to really understand that is to try building non-trivial applications with both.

[aaronbrethorst]

Whatever makes you happy, my dude

[westoncb]

I mean, am I mistaken? Is the UI more complex than it looks or something? I'm just basing my comment off what I've been able to find through your reference.

If there is some new system that's a genuine improvement over React and kin I'd love to know about it.

[Scarblac]

Generally speaking, simple UI sounds like something to aim for. If your UI is "intrinsically difficult", there's a high risk the user will conclude the same thing.

[westoncb]

Not intrinsically difficult to use, I mean that the problems involved in implementing some ui concept may be intrinsically difficult or not (this can happen even when from the user's perspective the UI is simple/elegant). When they are, then you need appropriate tools.

And yes absolutely as I’ve said, if it’s possible to for some domain to have a basic ui do that.

[rat9988]

Usually the difficulty of a user to conceptualize something has nothing to do with the complexity of the code.