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.
The APIs are expensive for storing state (read access on attributes) and expensive to write (so many ways to trigger reflows and paints) without a good way to batch them.
WCs have tons of boilerplate to them, such as extra song and dance to make attributes observable. In fact, a custom element can have an attribute and a property with the same name, and they are managed separately unless you explicitly set them up to sync. It's a terrible design.
Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
There's a reason popular frameworks are popular. They're good enough, you can hire people who already know them, and you benefit from the maintainers fixing bugs for you.
It sounds like you are trying to force framework insanity onto the vanilla APIs. That is insanity, but I know why you are doing that... its what you know.
The good thing about the vanilla APIs is that you don't have to do knowingly broken things. The APIs themselves are stupid fast.
When I need to store state I put all the state goodness into a single object. Just one object, and its generally small even on extremely large applications. I update that object as often as the user interactions dictate. I let the needs of the application determine where that object is written: localStorage, a file, a database, or something else. I only ever need the state object when the page loads or reloads, because I am not doing things some weird framework way.
Built-in things are represented as data structures, so they are inherently as extensible as your programming capabilities allow.
> There's a reason popular frameworks are popular.
Because that is what employers dictate for hiring. If you want to work you have to do the stupid things for newbs. Framework popularity also does not indicate other positive qualities. These popular frameworks are the primary reason so many people on here bitch about the bloated web.
> These popular frameworks are the primary reason so many people on here bitch about the bloated web.
I'm not saying a framework should be used for every single website. This one doesn't need one. It would be equally absurd to say not to use them.
> It sounds like you are trying to force framework insanity onto the vanilla APIs. That is insanity, but I know why you are doing that... its what you know.
I used to work at an agency that came up during the front-end time of slicing and dicing PSD files to get pixel perfect rendering on IE5-8, with all the quirks and everything. Nothing was allowed to be a framework, not CSS (bootstrap) or JS (aside from jQuery).
As applications got bigger and bigger our code and ability to deliver on time suffered. Nothing was impossible, per se, but the ad-hoc frameworks that got invented in house to cut down on boilerplate didn't keep up with the needs of the projects.
We slowly started allowing things like backbone, then later angularjs and right before I left React started to come on the scene. These came with their own problems, but they generally solved more than they caused.
"Framework insanity" is a meaningless phrase. There's plenty of frameworks that I don't care for, and things I don't like about the ones I do use. I'd rather use almost any of them than go back to doing what I'm doing now with pure vanilla JS. I'm not writing simple blogs or news sites or recipe sites that don't need much interaction. If I were, I'd be using vanilla JS.
> Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
This is the bane of every UI out there. "I hate the inbuilt controls so I'm going to write something better that doesn't look terrible!". Then they build some half-arsed thing that doesn't do accessibility right and only works properly on an up-to-date Chrome-based browser in a US locale with javascript enabled.
The built-in controls should always be used, not because they look pretty, but because they work the same across all websites. Users don't have to guess how this site's bespoke time-picker works (and how it doesn't). It won't fail in unexpected ways. It'll deal with your locale's date format so you don't accidentally specify the 5th of June when you meant the 6th of May.
Not everything has to be pretty all the time. Functional works, too.
It seems wild to me that a (subjectively?) pretty-looking site will make more money, even if it's excluding a large proportion of its potential users by ignoring localisation, or usability.
I'd love to see the studies you base that on.
As with all things like this, a lot of the data is hidden behind teams working inside organisations that won't publish their data.
I tend to find good examples of data-driven blog posts on Gov.UK; GDS has done a lot to drive better decision-making with strong data. An example of that is the Input component they use [1] and the data behind the choice and issues with type=number [2].
On the making more money perspective, I can share an anecdote for you, when I was working with a large property portal in the UK, we had a few unstyled dropdowns hanging around the app for sort criteria etc. Simply replacing them with a styled dropdown (and dropdown list) resulted in a 60% uplift of using that sort. We made no functional changes, just styled it. And it wasn't good styling, we broke dropdowns (as many do) in the first iteration (we were testing the hypothesis that people didn't use it because it didn't look like it was our component / wasn't styled like the rest of the site) -- So yes, anecdotally, pretty can be more impactful and result in more clicks.
> The built-in controls should always be used, not because they look pretty, but because they work the same across all websites.
Funny that you mention date/ time but ignored my example of the number type input, which does not work the same across all browsers.
In any case, it proves the point I was originally making; if the built in controls were extensible, we wouldn't be in the position of reinventing the entire stack because the design team wants to be unique.
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.
zdragnar · · focus · HN ↗
WCs have tons of boilerplate to them, such as extra song and dance to make attributes observable. In fact, a custom element can have an attribute and a property with the same name, and they are managed separately unless you explicitly set them up to sync. It's a terrible design.
Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
There's a reason popular frameworks are popular. They're good enough, you can hire people who already know them, and you benefit from the maintainers fixing bugs for you.
austin-cheney · · focus · HN ↗
The good thing about the vanilla APIs is that you don't have to do knowingly broken things. The APIs themselves are stupid fast.
When I need to store state I put all the state goodness into a single object. Just one object, and its generally small even on extremely large applications. I update that object as often as the user interactions dictate. I let the needs of the application determine where that object is written: localStorage, a file, a database, or something else. I only ever need the state object when the page loads or reloads, because I am not doing things some weird framework way.
Built-in things are represented as data structures, so they are inherently as extensible as your programming capabilities allow.
> There's a reason popular frameworks are popular.
Because that is what employers dictate for hiring. If you want to work you have to do the stupid things for newbs. Framework popularity also does not indicate other positive qualities. These popular frameworks are the primary reason so many people on here bitch about the bloated web.
zdragnar · · focus · HN ↗
I'm not saying a framework should be used for every single website. This one doesn't need one. It would be equally absurd to say not to use them.
> It sounds like you are trying to force framework insanity onto the vanilla APIs. That is insanity, but I know why you are doing that... its what you know.
I used to work at an agency that came up during the front-end time of slicing and dicing PSD files to get pixel perfect rendering on IE5-8, with all the quirks and everything. Nothing was allowed to be a framework, not CSS (bootstrap) or JS (aside from jQuery).
As applications got bigger and bigger our code and ability to deliver on time suffered. Nothing was impossible, per se, but the ad-hoc frameworks that got invented in house to cut down on boilerplate didn't keep up with the needs of the projects.
We slowly started allowing things like backbone, then later angularjs and right before I left React started to come on the scene. These came with their own problems, but they generally solved more than they caused.
"Framework insanity" is a meaningless phrase. There's plenty of frameworks that I don't care for, and things I don't like about the ones I do use. I'd rather use almost any of them than go back to doing what I'm doing now with pure vanilla JS. I'm not writing simple blogs or news sites or recipe sites that don't need much interaction. If I were, I'd be using vanilla JS.
marcus_holmes · · focus · HN ↗
This is the bane of every UI out there. "I hate the inbuilt controls so I'm going to write something better that doesn't look terrible!". Then they build some half-arsed thing that doesn't do accessibility right and only works properly on an up-to-date Chrome-based browser in a US locale with javascript enabled.
The built-in controls should always be used, not because they look pretty, but because they work the same across all websites. Users don't have to guess how this site's bespoke time-picker works (and how it doesn't). It won't fail in unexpected ways. It'll deal with your locale's date format so you don't accidentally specify the 5th of June when you meant the 6th of May.
Not everything has to be pretty all the time. Functional works, too.
johnnyanmac · · focus · HN ↗
Pretty is user engagement. User engagement is money. So for our current environment, yes. It has to be pretty.
alextingle · · focus · HN ↗
It seems wild to me that a (subjectively?) pretty-looking site will make more money, even if it's excluding a large proportion of its potential users by ignoring localisation, or usability.
I'd love to see the studies you base that on.
wolvesechoes · · focus · HN ↗
Idiot211 · · focus · HN ↗
I tend to find good examples of data-driven blog posts on Gov.UK; GDS has done a lot to drive better decision-making with strong data. An example of that is the Input component they use [1] and the data behind the choice and issues with type=number [2].
On the making more money perspective, I can share an anecdote for you, when I was working with a large property portal in the UK, we had a few unstyled dropdowns hanging around the app for sort criteria etc. Simply replacing them with a styled dropdown (and dropdown list) resulted in a 60% uplift of using that sort. We made no functional changes, just styled it. And it wasn't good styling, we broke dropdowns (as many do) in the first iteration (we were testing the hypothesis that people didn't use it because it didn't look like it was our component / wasn't styled like the rest of the site) -- So yes, anecdotally, pretty can be more impactful and result in more clicks.
zdragnar · · focus · HN ↗
Funny that you mention date/ time but ignored my example of the number type input, which does not work the same across all browsers.
In any case, it proves the point I was originally making; if the built in controls were extensible, we wouldn't be in the position of reinventing the entire stack because the design team wants to be unique.