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