[jypepin]

every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) is way over his head.

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.

[ehnto]

For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most projects I have seen. It mostly ends up in a greenfields component stew.

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.

[dmix]

What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes.

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

[2] http://getbem.com/

[WA]

> React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration

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.

[dmix]

It's true Redux/VueX creates a habit of coupling your components to the specific usecase. But I've been using them for over a year now and whenever I've had to reuse a component, often in very different environments, it takes about an hour of tweaking to make the component reusable. Sometimes you have to rewrite parts of the DOM to make it more flexible.

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).

https://rebassjs.org

[pierreyoda]

On your last point, I feel like components this basic should really rather be addressed at the real theming level, i.e. in CSS.

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-...

[tomgp]

This chimes with my experience after 2 years of React dev I like it, it's fine, but on most projects I haven't really needed it and have found the tooling overhead can become quite onerous.

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.

[dwild]

> We can write re-usable components in pretty much any language with as bit of file organisation.

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.

[rrrich]

I'm curious as to how you can make reusable UI components with just a bit of file organisation?

[cljs-js-eval]

Yeah - I've seen and worked with (very talented!) people like Brad, and I feel for them. They're good at working with this presentational stuff, but it's never been necessary to learn that when they're creating an <input> they're secretly creating an HTMLInputElement. And then one day, they're expected to learn this framework that fits so nicely with the frontend because they try to emulate that hierarchy of objects on the frontend and deal with them in code.

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.

[keithnz]

I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css.

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 )

[rhaksw]

he writes,

> 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.

[typetrail]

Are you referring to posts like this?: http://bradfrost.com/blog/post/my-struggle-to-learn-react/

"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.