A few quick points from my perspective. (I work on React.)

1. We're not opposed to supporting web components better. The problem is that there's no single "web component community". There are multiple subcommunities. You mention "web component libraries" in the post. These libraries don't agree on a single standard so React would need to pick a side in debates like "how does server rendering work with web components". Whatever we pick will have large downstream effects, and our reluctance to support more has to do with being careful (see [1] note below) about the semantics — not somehow being at odds with web components per se.

2. As I mentioned in the previous point (and you mentioned in the post), there are multiple "web component libraries". As far as I can see many of the criticisms of React would apply to such libraries as well. I don't think the way to counteract "DOM FUD" is to introduce "library FUD". If you're using a library for defining and updating your web components declaratively, you're not following a conceptually different approach from using React.

3. Saying "you can do everything with WCs that you can do in React" is double edged. Yes, of course, you can do anything — because we haven't actually agreed upon any constraints. If the constraint is "you don't use a React-like library on top" I think you'll find there's plenty of things that are very hard to do with an imperative abstraction like vanilla WC APIs. We've done a few talks about what using React as a unifying abstraction lets us do (such as non-blocking rendering, or dynamically loading UI code without degrading user experience). You might want to check them out (youtube.com/watch?v=nLF0n9SACd4, youtube.com/watch?v=ByBPyMBTzM0). Of course, you can do these things if you use a library like React on top of WCs. But that negates the argument that you don't need React-like libraries for this.

To sum up: we'd be happy to support WCs better in React. We don't want to rush it, and want to make sure this support is well thought-out. Additionally, we believe there are many things that raw imperative WC APIs don't give you — and for them something like React would be appropriate even in a WC world. Finally, there's this myth going around that once you write React code, you can't reuse it as web components. That's not true — and as you can see from the documentation it's a few lines of code: reactjs.org/docs/web-components.ht...

Hope that makes sense, and provides some additional context!

[1]: For example, if I'm not mistaken, the semantics chosen by Preact make introducing a new standard property to DOM base element potentially a breaking change for the web. We try to avoid such problems if possible — precisely because React did learn from MooTools and we don't want to do another mistake like what happened with Array.prototype.flatten().

Ruby

a - b

As a religious Jew, once we light the candles on Friday night, we don't touch our phones or computers until havdallah Saturday night (barring emergencies, like the time I delivered our youngest Saturday morning at 4am, but I digress).

Instead of social media, we socialize. Instead of feeds, we feast. Instead of merge conflicts, we discuss the great makhlokos (legal and philosophical differences of opinion) in Jewish scholarship.

In short, it's a day for being instead of doing.

That CSS is the most complex modern programming language

So true.

It's a little bit like voodoo sometimes. I can see why a lot of people rather do back-end. I learnt much most of what I know about CSS from StackOverflow than from books, good thing now there's MDN. Not entirely sure where to start when juniors ask me "how do I learn CSS".

FOMO is the enemy of focus.😞