No disrespect, it just feels like he's not spending the time necessary to understand how things work and instead of doing so, he just goes on and vents on his blog.
We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently.
Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.
React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components.
One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity.
Or a ton of global jQuery plugins for select boxes and modals and everything else.
Everything is so much more portable across projects.
That's not even mentioning the whole plug-and-play reactivity that is baked in.
[1] Here's a good list of the problems of CSS-in-JS helps solve: https://i.imgur.com/LbE1kqc.png
But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components". In one project, you use Redux, in another, you drill props down to all children. In the next, there's React Context or whatever the next thing is. Do components load their own data (like some widgets) or is there a root component that loads all data and handles the state for the entire app?
I'd argue writing presentational components isn't that different from writing just HTML and CSS. The tough parts of React is where all the unique state logic is placed.
But this is like any abstraction in programming. When you have a function you want to be reusable you usually have to do some work to make it more portable across your codebase and create a proper flexible "interface" for it via arguments.
The UI components are particularily easy to reuse. If you look at something like Rebass it uses predefined constants to add consistency of values across the entire site + a theming system which simply tweaks those constants (ie, colors, the scales of font sizes across h1-h6, etc).
Utility-first CSS frameworks are awesome if you get past your first impression. I've been using TailwindCSS [0] both at work and for all my personal projects ever since I read Adam Wathan's justification on it [1]. In TailwindCSS those constants are configured in one place and generated at build time (through Rollup/Webpack/PostCSS etc.). Consistency and theming for free basically.
Even Bootstrap has now a decent collection of them in v4.
[0] https://tailwindcss.com/ [1] https://adamwathan.me/css-utility-classes-and-separation-of-...
Right now, for me, the main reason for choosing React on a project is staffing; the availability of enthusiastic devs is a major plus point. The flip side of this is it feels a bit like hiring JS devs 10 years or so ago at the height of jQuery's popularity -- you get people who can churn out decent code in that paradigm but will often miss easier ways to do things that rely on an understanding of the underlying technologies.
I worry that the underlying tooling and technologies for React too are far removed from most React devs daily experience, that because of this they won't make that transition to greater understanding. There's often ~one person on a React team who understands the build pipeline and that's a problem Have you ever come to a project and found an x-hundred line web pack config file? Yikes! Those things can be hard to un-pack and figure out what every piece is doing and why.
Sure you can, but only in that specific language, which sadly your browser won't understands.
I'm working with Struts 2 at my job sadly, when I started I quickly began to make components because it's much better than the usual copy-paste they were doing.
The components are great and works well, are not so hard to make (much harder than React but still accessible) but once it's rendered, that's it. You want to add an element using JS?
Well okay, you'll just add some kind of template that you will render in the JS, even more works, but that's fine. Thing is, you don't have access to parameters... well just add it in the JS initialization easy right? No they use OGNL, thus if anything is done programmatically (which it will, for concatenation or i18n, or whatever), most likely won't works.
Most time when the component change visually, the same change need to be done on JS too. Twice the time...
In the case of Struts, the components are also quite hard to imbricate into one another, which push toward even more code smell.
It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.
Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )
> I also got — and continue to get — a whole lot of (often private) correspondence from a slew of people who feel equally overwhelmed.
Adopting a new framework can be tricky. IMO it's okay to write about "the process of learning" to show that it isn't always a breeze. Posts like this can give perspective to both learners and experienced practitioners.
Speaking for myself, I've enjoyed learning React, though looking back on my first project I can see I've made some pretty bad mistakes with my use of state. I don't know if there is a guide I could have read to avoid these mistakes, or if I just needed to struggle through it.
"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",
The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.