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.
"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%+."
It may be that a lot of it is aesthetics (though aesthetics also matter to usability) but some of it is richer functionality.
For example, a pattern I've been asked to implement multiple times is a requirement like this:
"We should have a 'Country prefix' input for a telephone number on the form. It should be a list, but allow the user to filter. They should be able to search by code (+44, 0044) or by country name (United Kingdom). We want a little flag beside the input".
Now I _can_ do that myself from browser APIs, e.g. using something like a datalist, using emojis for flags. But then I've to handle stuff like Win/Chrome not even supporting the emoji properly. Chrome will autocomplete based on label or value but FF won't. Even though there's a datalist, I can't constraint the input to _only_ select one of those values, so I need to do additional client-side validation on inputs anyway.
Then if a designer said of an 'contact book' look-up (e.g displaying an profile photo of people instead of a flag) I now have to come up with some other custom field anyway, to support that.
I think the browser level APIs and supported tags have come a long way from where they were, but they're still at the level of primitives. The libraries people are reaching for are one level above that.
But we've well established patterns on the web now that there's no reason we couldn't have richer OOTB browser chrome and remove the need for a lot of this stuff getting reimplemented in libraries all the time.
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.
another-dave · · focus · HN ↗
It may be that a lot of it is aesthetics (though aesthetics also matter to usability) but some of it is richer functionality.
For example, a pattern I've been asked to implement multiple times is a requirement like this:
"We should have a 'Country prefix' input for a telephone number on the form. It should be a list, but allow the user to filter. They should be able to search by code (+44, 0044) or by country name (United Kingdom). We want a little flag beside the input".
Now I _can_ do that myself from browser APIs, e.g. using something like a datalist, using emojis for flags. But then I've to handle stuff like Win/Chrome not even supporting the emoji properly. Chrome will autocomplete based on label or value but FF won't. Even though there's a datalist, I can't constraint the input to _only_ select one of those values, so I need to do additional client-side validation on inputs anyway.
Then if a designer said of an 'contact book' look-up (e.g displaying an profile photo of people instead of a flag) I now have to come up with some other custom field anyway, to support that.
I think the browser level APIs and supported tags have come a long way from where they were, but they're still at the level of primitives. The libraries people are reaching for are one level above that.
But we've well established patterns on the web now that there's no reason we couldn't have richer OOTB browser chrome and remove the need for a lot of this stuff getting reimplemented in libraries all the time.