That's the luddite take.
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.
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.