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.
For starters, you can start by checking <a href="https://caniuse.com" rel="nofollow">https://caniuse.com .
Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.
And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.
And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.
I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.
As an example, I still like the simplicity of Rails for basic apps. I also enjoy the numerous component libraries, such as Antd, available for React. I don’t want to have to pull in React just so I can get a reasonable way to work with a Tree widget.
I’m not trying to only use the platform. The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.). But that’s contained in the component. I’m free to use my framework or web technology of choice for building my app.
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.
locknitpicker · · focus · HN ↗
For starters, you can start by checking <a href="https://caniuse.com" rel="nofollow">https://caniuse.com .
Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.
And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.
And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.
nirvdrum · · focus · HN ↗
As an example, I still like the simplicity of Rails for basic apps. I also enjoy the numerous component libraries, such as Antd, available for React. I don’t want to have to pull in React just so I can get a reasonable way to work with a Tree widget.
I’m not trying to only use the platform. The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.). But that’s contained in the component. I’m free to use my framework or web technology of choice for building my app.