There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.
I used to _hate_ front-end programming, everything was a huge framework of magic dust and unicorns. Stuff Just Worked - if you knew the name of the magic incantations (variables and functions) you had to cast to make it work. Never mind that the whole front-end landscape seemed to do a complete pivot and invent new stuff every other week.
With React + Typescript it's just components that produce fragments of HTML and are entirely or at least mostly self-contained with a clear interface.
The coupling is super tight and always has been.
Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone.
I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water.
Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.
Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.
But it's less specific then that. When 6 years ago hiring a frontender they needed to just know html and css, now they need to be full blown devs.
Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write this in Word? We have markdown and I bet there is a tool where I can style this and generate a PDF”.
The reason I use React is mostly its composable, simple templating abstraction and the fact that it works both on the server and the client.
UX is generally improved. If a site/app is done well, it will work w/o JS enabled, loads fast and transitions even faster.
JS typically makes things better, not worse. What makes sites slow is putting in external and/or heavyweight stuff: ads, analytics, tracking, fonts, images and so on.
In fact the scoped CSS makes Vue files superior to plain html+css for non CSS experts -- organizing large stylesheets is hard to get right!
This always smells like "nobody could possibly do what we do" developer hubris.
The designers I've worked with on my last three large React projects could edit .jsx/.scss files. I don't really buy the idea that someone can learn web client design but it's jsx or whatever that's too much.
As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. The fact that it completely disregards MVC, which maybe never really worked anyway, is the least of its problems.
On the other hand, the time saved from using React Native versus having 2 separate codebases for iOS and Android is the difference between having a product and not having a product for many teams and solo developers. The issue there is not React Native being bloated, but cross-platform development being such a pain.
on the native app side, ive seen this too with mvc, mvvm, mpv apps: people just arent very good at deciding what goes where in many specific cases
im not sure, but my guess is, the more layers you have to maintain, the higher the cognitive load that one has to implement so many parts, they start to tire and without knowing it, smear things across layers, making a huge mess over time
You probably shouldn't take up a career in technology if you're not willing to continually learn new things to keep up with advancements.
It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand.
The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated messes that exist solely to paper over the fact that the main software delivery platform is still just a hacked-up document viewer. They make professional programmers' lives easier, but the act of programming becomes generally less accessible with each iteration.
React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a
Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it.
I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.
And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming.
I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.
React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element).
Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.
Frontenders at the the time didn't see themselves as engineers.
I recently wanted to throw up some minimal stuff on S3 without building, just a HTML file, and was surprised at how small the difference was, for simple enough pages - almost 0.