Sometimes I look at what's going on in React land and just want to ask these developers, do you really need all this to make a UI? Really? Are you sure? Are you making things better?
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.
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.
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.
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.
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.
This article is a bit long-winded. I don't reason about React at all like the author of this blogpost. Using React with hooks is dead simple, and getting a React app running takes minutes.
It is not true of all projects _to the same degree_. Highly conventional, opinionated systems have a higher learning curve but yield a more consistent result given developers with inconsistent skill levels and investment in architectural design of an application.
That is a fancy way to say: React gets new devs productive fast, and so it has tons of them available for work, but that comes at the cost of producing more spaghetti that more experienced devs inevitably have to clean up.
> Highly conventional, opinionated systems have a higher learning curve but yield a more consistent result given developers with inconsistent skill levels
This is highly debatable. A lot of conventional and opinionated systems have lots of under-the-hood magic that make it hard to reason about, even for experienced developers.
Coming to React, after working with OOP for UI, was pretty mind blowing for me. It is so much better than anything I was working on 5 years ago. React has dramatically improved the landscape as a whole.
That said, I think React is fatally flawed in its necessity to treat state in immutable structures. I wish React could be more like an immediate mode UI library, or a “thin” rendering layer as it was originally advertised. I want to be able to structure and handle my state however I please. I think such a library is bound to come along and topple React.
There isn’t actually a whole lot of “this” in this —- from an API surface viewpoint, most UI frameworks (React included) are fairly minimal sets of abstractions. The benefit is more along the software development axis of homogenization than anything else.
At the moment yes, given that things I'm improving is an old (2012) Dojo application where the closest thing to a component is a function call that concatenates HTML, CSS and JS together. Yes that's JS-in-a-JS-string, it's er, interesting.
I'm dealing with thousands of fields with hundreds of different validations (usually min/max values or regular expressions), React is not the only one that can solve this, but at the moment I don't regret my decision. And with hooks and functional components, they're really compact - compared to e.g. Angular, which is more aimed at Java/C# developers I believe in terms of formality and verbosity.
I'd consider that a strange question since these development means the amount of code required is getting less and less each year. React code is really concise now IMO.
Go have a look at what Elixir is doing with LiveViews ....
The fatal flaw of React is that there are two states - client and server. Very often two different languages. Two different teams. Long and painful build. And in any case, you cannot trust the client. In 99.99% of the use cases - apart from extreme scale and full page renders - a LiveWiev will be more than enough, at 1/20 of the complexity and development time.
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.