[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?