re: Why the React community is missing the point about Web Components VIEW POST

TOP OF THREAD FULL DISCUSSION
re: A few quick points from my perspective. (I work on React.) We're not opposed to supporting web components better. The problem is that there's no ...
 

Dan, of course React still has value with Web Components. It has value in numerous ways, in particular orchestrating the rendering of application state into a view.

That's orthogonal to Web Components. You could do it, but it's not the best tool for the job. Just like React isn't the best tool for what Web Components are for: extending HTML.

Have you still not gotten comfortable with the nuance that there's a difference between an application framework and a library of GUI components?

Or that you can very easily produce Web Components with a declarative interface?

Or that it's a low level API, like the DOM, and that's intentional so that the web community can ideate how to author Web Components declaratively (different from using them declaratively)?

Or that there are negative ramifications to putting the entirety of the view layer behind the semantics of JavaScript instead of embracing the declarative languages of HTML and CSS?

Stop staring into your bellybutton and talk to some of the web designers your community has alienated over the past 6 years. The web is for more than software engineers. Software engineers are not more important than the rest of audience, even if it's understandable that, as a fellow software engineer, you see things the same way.

 

I'm not sure how my post justified your patronizing attitude. Indeed, React and web components are orthogonal. That's exactly what our docs say:

reactjs.org/docs/web-components.html

React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.

As mentioned in my post, we'd like to further improve this integration, but we'd need to be careful and get the semantics right.

Re: your point about software engineers, I'd like to hear from you about how React alienates designers and how we could improve this — perhaps you could raise an issue to spell out your concerns? We're excited about products like FramerX, and React docs include links to designer-friendly resources (reactjs.org/docs/getting-started.h...).

I know we're not doing enough for designers, and would love to do more there. Not sure how this is relevant to the WC conversation but maybe you can help me understand. But I don't believe I've heard from you before you told me to "stop staring into my belly button". That's not a very productive way to start a conversation. Is that how you talk to people in real life too? Maybe we can try again?

Gosh, I'm genuinely surprised you found that patronizing and confrontational! I wouldn't wish a mile in my shoes on you.

Sure, let's try again. Sorry it came off clearly far, far harsher than meant. I gotta come back later, though.

So, for now:

designer !== someone who doesn't code and therefore needs to use a GUI

Yes, there's nothing helpful or serious in "Junk" remarks.

I am so confused; I have such trouble relating with people sometimes. I've re-read what I said a dozen times, and I can't see the problem. Though if I weren't posting anonymously the self-doubt and resulting guilt would be sufficient to shut me up for at least six months. That's why I have this account: destructive anxiety. (Though, also, yes, that's how I talk to people in real life. And yet most people, including my coworkers, like me; I can only assume because a different and authentic tone is heard than has been apparently read here.)

Sure, I could pretend that I was born just this moment and so I approach all of this with neutral, fresh-faced, joyful innocence. But that's bullshit. Instead I have a dozen years of history of seeing libraries and frameworks come and go. And four years of hearing things like what Dan said repeated uncritically by the React core team and people who appear to take their word on it like they have some biases being confirmed by it all.

Nothing I've ever said about it has made even the slightest dent in that, no matter how I said it. That's why it's ironic to have my input invited on how to fix that dialogue. I only "patronized" by assuming Dan has a subjective point of view. Which is true for literally everyone. Let's look at a contrast. Dan leveled an accusation of FUD (which means deliberate evoking of fear, uncertainty, and doubt for the purposes of propaganda) and no one chided him. I leveled an accusation of naval-gazing--and how dare I! Nothing I say has any value whatsoever!

Huh? Naval-gazing is like bike shedding; it's just a common trap for people in our industry. Is all of this because I started the comment with, "Dan, of course"? That means I agree so completely with the following statement that I don't think it's even a question! Not that I think he's stupid.

I really, really don't want to be a jerk, but at the same time... If that's all it takes, I cannot understand your perspective, since hardly a week passes when someone doesn't tell me I'm categorically unfit to be in the industry and should leave it to the real engineers. When's the last time someone told you that they hope you lose your livelihood because you don't want web client implementations to exclude a wider audience by requiring a lot of specialized programming knowledge and time spared to keeping up with the pace of the JS ecosystem? I'm not saying that excuses treating anyone else like crap, but...I can't see that I am...?

Now to what I think merits objection.

"Web components are imperative." Not to users. Not to product managers, not to designers, not to blog authors, and not to application developers consuming them. React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?

Well, because React is very focused on developer experience. Is the developer experience great? Unsurprisingly, that's subjective, but I think it's accurate to say, "React's developer experience has a great deal to recommend it to a significant audience." But it's an issue if the only votes that are counted to justify that assessment come from a privileged subset of people who work on web client development.

In response to my brief comment about that, Dan pointed at auxiliary tools that double down on framework lock-in. To me, that misses the point. We already have a standardized declarative language to create elements and set properties in the DOM. It's called HTML. Putting up a website with a specification doesn't make something a standard the way I mean a standard, by the way. The majority of web client standards represent an an agreement made between multiple competing interests and vetted by performance and accessibility specialists. "I did a thing with my own interests in mind without giving any competitors an opportunity to make significant changes or veto," isn't even remotely close.

Why do non-engineers need a separate tool that's in its infancy? In part, because you excluded them from the ground up. The only way to fix it is to create something else with them in mind. It'd still be worthwhile to build FramerX, because we really haven't seen great holistic web design and web client development tools thus far. So there are numerous things I think are great about FramerX, but bolt-on inclusion is not one of them.

There is more, but after getting this far... I fear to put any energy into writing it if I'm so blinded by my own small world that I might be doing nothing except giving readers a bad impression of people who care about the same things I do.

Hey, I'm sorry if my reply frustrated you. I'll try to clarify a few things. I don't mean to create any FUD. I think my position is very concrete. (And it's definitely not something about "real engineers" — I'd like React to be welcome to everybody.)

React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?

Of course under the hood it's all imperative. The question is only about how you write the majority of your application code and how components are expressed. I already linked to this talk in my first comment but I'd be happy to link again: reactjs.org/blog/2018/03/01/sneak-...

In this talk I show a few things that I believe are very valuable from both developer and end user perspective. Features like these are not possible if your "glue code" between components is imperative. If you watch the talk I think you'll realize what I'm talking about. I'm sorry that I don't have a shorter and more condensed version of my argument than a conference talk. But I hope that if you find the time to watch it, you'll see that I'm talking about specific things and not vague FUD about imperative/declarative.

If React is not solving your problems that's cool too. No need to assume ill intent.

Who is assuming ill intent and about what?

React meets some of my needs, but not others. So I use it for some use cases, and not for others.

Again, don't get half of this response. The frustrating part is getting replies that seem to be aimed at something entirely different from what I posted.

Like, is this some form of communal trolling, or am I just that bad at expressing myself?

Your first post would have definitely been an odd opener in person. It's like talking shit before shaking hands. Not going to go over well.

A non negligible percentage of standards become standards after a company builds something and demonstrates it's worth, at which point standards bodies go through the process you described. See SPDY / QUIC. Its much easier to define and iterate on something after someone else has demonstrated success.

code of conduct - report abuse