This got to me:
> For a certain type of developer, building things yourself is just more fun
The platform APIs were terrible. React wasn't "more fun"... it just made it possible to do things with the platform that were extremely difficult and cumbersome to get working reliably with platform APIs alone.
To me, web components were an incredible idea poorly implemented. Most of the minimal adoption happened on top of frameworks like Lit that wrapped WCs to try to make the dev experience tolerable.
In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.
Now credit where credit is due: it has very much improved. And modern standards means it really is time to re-evaluate where and when you need these patches. But don't write off all that annoying and painful effort people put in to trying to making the platform deliver it's promised potential just to "building it yourself is more fun".
After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+. Of those aesthetics based conclusions most people cannot find their own way to handle it without waiting for somebody else to write a tool that provides the answer they were looking for. Even then the answer tends to be predicated on social acceptance more than technical evaluation. That is a training or human performance problem more than a technical problem. It says a lot about an industry where the people who are able to ask these kinds of questions realize its a training problem and are willing to raise salaries and assume tech debt as opposed to fixing a human capital problem for far less money.
At any rate there is something to be said for the developer who builds things on their own just for themselves. In many cases the result is faster, lighter, and more capable software than what they are paid to do for their employer. Their personal software isn't locked into conventions or abstractions beyond their control.
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.
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.
toddmorey · · focus · HN ↗
The platform APIs were terrible. React wasn't "more fun"... it just made it possible to do things with the platform that were extremely difficult and cumbersome to get working reliably with platform APIs alone.
To me, web components were an incredible idea poorly implemented. Most of the minimal adoption happened on top of frameworks like Lit that wrapped WCs to try to make the dev experience tolerable.
In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.
Now credit where credit is due: it has very much improved. And modern standards means it really is time to re-evaluate where and when you need these patches. But don't write off all that annoying and painful effort people put in to trying to making the platform deliver it's promised potential just to "building it yourself is more fun".
austin-cheney · · focus · HN ↗
In what way?
After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+. Of those aesthetics based conclusions most people cannot find their own way to handle it without waiting for somebody else to write a tool that provides the answer they were looking for. Even then the answer tends to be predicated on social acceptance more than technical evaluation. That is a training or human performance problem more than a technical problem. It says a lot about an industry where the people who are able to ask these kinds of questions realize its a training problem and are willing to raise salaries and assume tech debt as opposed to fixing a human capital problem for far less money.
At any rate there is something to be said for the developer who builds things on their own just for themselves. In many cases the result is faster, lighter, and more capable software than what they are paid to do for their employer. Their personal software isn't locked into conventions or abstractions beyond their control.
jchw · · focus · HN ↗
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.
someguyiguess · · focus · HN ↗