Comment by jchw
8 hours ago
I have worked on my own component libraries for HTML, but I don't like solving the same problems over and over and over again. I'd prefer a well-supported battle-tested library over my ad-hoc attempts.
The argument presented in the article here is that libraries like jQuery and React were useful, but now the browser has better APIs, so we should use them.
The browser indeed has a components API, but it is by the admission of many, fairly low-level as far as component APIs go. It doesn't really solve how to manage data flow or rendering in your components or application, and has many sore spots.
No problem. There is a pretty nice library called LitElement that provides solutions to some of these problems.
But then we're not really living off the land are we? We still need Lit in this case.
So what's wrong with WebComponents? Frankly, I think this is a bad question. A better question is why people think WebComponents competes with React to begin with. WebComponents intentionally fails to solve some of the most annoying problems with writing components because it is intended to be low-level and used by libraries like Polymer. Because of this, it leaves many problems open-ended. Like for example. WebComponents act like HTML elements. Cool? So you can pass data down using HTML attributes. Neat. Problem: HTML attributes are strings. Okay... So you either need to serialize everything to strings, or you have to pass objects through a separate side channel (usually properties that you assign separately.) In fact, generally speaking, writing WebComponents that compose other WebComponents is ass. I'm pretty sure it has been noted before that WebComponents works best for leaf components... So it would certainly not make a good replacement for a library like React, which is meant to be a substrate you can build large scale applications out of.
Yeah, I don't really like WebComponents either. I have not take the time to examine the WebComponents API. I just don't like the concept as a means of architecture.
For me its all about design freedom and maximum flexibility. To achieve that I go further down the stack, as low as the given platform allows. I have been doing this work for a very long time, so I am not worried about risks with operating in the browser as primitive as possible. The most important APIs and conventions have not changed much, at least for me, since the release of DOM4 spec and the JSON methods entered JavaScript as language methods, then later WebSockets.
When you go lower elsewhere, the risks are higher given there is so much we otherwise take for granted. There are risks to reinventing the wheel on some of the most complex things we use but don't really think about. The benefits, though, are massive if you can create capabilities the technologies allow but nobody else has. Achieving this is more common than it sounds like it should be, only because most people don't try.
My original motivation for reinventing wheels, early in my career, was to have streamlined processes at work so that I could spend lest time doing work assignments and more time browsing the web. Now, I am about to do my first start up so now my motivation is to kneecap the incumbents with a cheaper and more durable technology that allows for writing future tools upon it to scale in ways the competition cannot.
Thank you for typing this all out because I could not articulate this nearly as well as you did but this was exactly what I wanted to respond to that comment.