FWIW the complexity issue is something many experienced JS devs likely complained about back in the early-mid part of the last decade when so many got caught up in the "object oriented JavaScript" craze (because it wasn't already? 🙃) that Kyle Simpson touched on in the first edition of You Don't Know JS, and the related "MVC EVERY CODEBASE PURELY FOR THE SAKE OF MVC 🙃" craze.
What a lot of us witnessed back then was a bunch of resulting code that was, somehow, even less readable and maintainable than it was in its previous spaghetti form (which we had probably already warned was spaghetti, but new hotness won out over common sense as the solution).
Right. Other than a clear model for componentization, it's hard to think of anything libraries offered that I wasn't already doing in one form or another. JSX/Hyper-HTML has also been quite revolutionary in it's own right, but on the other hand, that does come at a cost. I do like that the React community brought an awareness of classic CS concepts like immutability, side-effects, memoization, etc.
I could be very wrong here, but... I think the industry will dramatically shift back away from mega-frameworks and build-systems this decade, mostly due to new browser capabilities like Web Components and Modular JavaScript. I can't wait, it's going to be clean again for a while.
I actually don't have a problem with React - now Redux's obsession with pure functions to the point that you need either band-aidy (Thunk) or even more super-duper-boilerplatey (Saga) middleware just for async is a different story - in fact, it's my favorite library (actually React Native on mobile web and desktop, it's amazing what you can do with a single codebase without relying on a WebView these days).
I actually dug pretty deeply into HyperHTML (and other smaller libraries like Riot, and strictly relying on modern vanilla JS) before giving React a serious, unbiased chance, but I kept running into wheels that needed to be reinvented.
I haven't experienced many tradeoffs with JSX, especially now that there's hardly any reason for me to worry about repeating class/lifecycle methods (or using classes at all) ever again.
The thing that keeps me from web components is the same thing I ask any time I hear about use of just about any web framework/library: What's your mobile strategy? I don't like fragmenting teams to build what is often the same exact app in multiple codebases, if it's not absolutely necessary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
FWIW the complexity issue is something many experienced JS devs likely complained about back in the early-mid part of the last decade when so many got caught up in the "object oriented JavaScript" craze (because it wasn't already? 🙃) that Kyle Simpson touched on in the first edition of You Don't Know JS, and the related "MVC EVERY CODEBASE PURELY FOR THE SAKE OF MVC 🙃" craze.
What a lot of us witnessed back then was a bunch of resulting code that was, somehow, even less readable and maintainable than it was in its previous spaghetti form (which we had probably already warned was spaghetti, but new hotness won out over common sense as the solution).
Right. Other than a clear model for componentization, it's hard to think of anything libraries offered that I wasn't already doing in one form or another. JSX/Hyper-HTML has also been quite revolutionary in it's own right, but on the other hand, that does come at a cost. I do like that the React community brought an awareness of classic CS concepts like immutability, side-effects, memoization, etc.
I could be very wrong here, but... I think the industry will dramatically shift back away from mega-frameworks and build-systems this decade, mostly due to new browser capabilities like Web Components and Modular JavaScript. I can't wait, it's going to be clean again for a while.
I actually don't have a problem with React - now Redux's obsession with pure functions to the point that you need either band-aidy (Thunk) or even more super-duper-boilerplatey (Saga) middleware just for async is a different story - in fact, it's my favorite library (actually React Native on mobile web and desktop, it's amazing what you can do with a single codebase without relying on a WebView these days).
I actually dug pretty deeply into HyperHTML (and other smaller libraries like Riot, and strictly relying on modern vanilla JS) before giving React a serious, unbiased chance, but I kept running into wheels that needed to be reinvented.
I haven't experienced many tradeoffs with JSX, especially now that there's hardly any reason for me to worry about repeating class/lifecycle methods (or using classes at all) ever again.
The thing that keeps me from web components is the same thing I ask any time I hear about use of just about any web framework/library: What's your mobile strategy? I don't like fragmenting teams to build what is often the same exact app in multiple codebases, if it's not absolutely necessary.