6 ms·

The thing that this article is missing is that we use JavaScript in these places because compatibility is better. We can even use new JavaScript by transpiling,

The thing that this article is missing is that we use JavaScript in these places because compatibility is better. We can even use new JavaScript by transpiling, but polyfilling missing CSS and HTML is a lot harder to do and impossible in some cases (not to mention your polyfill will use JavaScript). `appearance` has a lot of caveats on MDN about testing it thoroughly if you're going to use it—even `appearance: none`. This may matter less if you only have to support new browsers, but keep in mind that old versions of Safari stay in circulation longer than you might think. `datalist` does nothing on Firefox Android. It just shows to me as an input box with no functionality at all (not even the suggestions over the keyboard that others report in Chrome Android). The color picker is neat, but extremely nonstandard, which is a dealbreaker for most businesses not just because the designers will complain but because customer support will find it harder to help people. Chromium provides the functionality to pick on a page and pick literally any color, but Firefox Android only gives me the rainbow, a gray, and black and white. The article itself acknowledges the inconsistencies with `details` and `dialog`. I hope we eventually get to a place where browsers that don't support these features (and support them consistently with each other) are no longer used, but in the meantime these elements will only find their way into my side projects, where I have full control of which browsers I support.

_the_inflator 3y ago
I side with you. Sadly, the article itself is of no use and only a rant, since the “you” in “you don’t need” is not defined. Have fun checking for mobile, tablet, desktop, Android, Apple, Chrome, Firefox. It is not that developers rejoice over creating controls all the time. There is still html and css involved.
fingerlocks 3y ago
> The color picker is neat, but extremely nonstandard When I press the button on my iPhone it brings up the actual system native color picker. It’s the same control that appears in dozens of apps because it’s provided by the OS. I much prefer that over some bespoke thing.
- demosthanos 3y ago
  You do, but companies don't. A major advantage of a browser app over a native app is having one system that behaves relatively consistently across all platforms. This isn't just cosmetic: providing customer support for a web app that has exactly one expected set of behaviors is far easier than asking your support agents to keep track of the constellation of different features users might have access to depending on their platform. The color picker control is the antithesis of this consistency: not only does it look different across platforms (making it harder for CS to walk customers through something over the phone), it provides different features depending on the platform. Some users will be able to pick an arbitrary hex code, some will be able to pick colors off the page, and still others will be given a tiny set of fixed choices. HN's audience might prefer that because they know the platforms they use extremely well, but the average caller to a customer support desk doesn't know their own device that well. If we instead write a bespoke control, you (being technical) will be able to figure it out, and the people who call in to customer support for help will all be seeing essentially the same thing. EDIT: And note that when I say "companies don't", I'm not even just talking about the SaaS vendor. Oftentimes the customer is also a business that has an internal support desk that prefers consistency.
  - drdaeman 3y ago
    > that prefers consistency So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved.
    - rhapsodic 3y ago
      > So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved. How would that work if the app had to work on both desktop and mobile? And, how easy would it be to make sure all users were using the same model and make of mobile device?
    - wlesieutre 3y ago
      Because as a customer there’s nothing that makes me happier than when I contact customer service and they say “our website is made for Windows so you’ll need to use the exact same OS as us”
superkuh 3y ago
Nope. Javascript means that if it fails then it completely fails and the content is not there at all. While the HTML examples may not look correct in older browsers, the actual content will be there. With JS it's just nothing. Nothing at all. It completely breaks accessibility. With HTML my screenreader can at least still read it. JS generated content prevents this. No amount of polyfill or other JS can save JS when JS cannot JS. It's terrible for accessibility unless it "works" to start and in that case your point is moot.
- demosthanos 3y ago
  None of what you said is an inherent problem with JS. The company I work for has JS app that is resilient against the missing-content problem you refer to. It is also more accessible than any other web app I've ever seen in my life. There's nothing about JS that breaks screen readers: you just... generate the right HTML with the right attributes. The problems you see with JS apps that don't work are apps written by people who don't care about their app working and don't care about accessibility. That's orthogonal to whether a JS app maintained by a competent team can have better cross-browser compatibility than one (by the same team) that leans entirely on new HTML and CSS features.
  - CharlesW 3y ago
    The parent commenter is saying that JavaScript in the browser MUST NOT be a dependency for core functionality because it may be disabled ("when JS cannot JS"). If your site is popular over Tor — that is, if it's used for warez or by whistleblowers and journalists who need to browse privately — this may be good advice. If it's not, people who disable a core aspect of the browsing stack are savvy enough to enable JavaScript on a site-by-site basis when necessary.
  - rado 3y ago
    Sample URL?
  - superkuh 3y ago
    >more accessible than any other web app Well there's our difficulty communicating. I'm talking about all web sites, not just applications that happen to be run in a browser. A regular HTML page with text in it is far more accessible than any application depending on execution could ever be. Web applications can, in very rare cases be made accessible (assuming you have perfect execution and JS feature support in the browser). But actual web pages always are. 99% of the time if you can do it with just HTML and text/images you should.
lelandfe 3y ago
The <dialog> element actually has deep support at this point, and the polyfill for the few percent of your users on 2021-era Firefox or Safari is totally fine. I highly recommend the element if you're making modals; the accessibility gains are fabulous.
MattGaiser 3y ago
> but because customer support will find it harder to help people. This is a big one. At a past job we actively discussed this and instead decided to use JS over things like datalist due to it potentially increasing the CS burden. Datalist specifically was tried, but the inconsistent results meant it had to go. We eventually ceased support for all browsers but Chrome as well due to the inconsistencies.
kjkjadksj 3y ago
Compatability is only better if you make the assumption that all your users need to be using javascript. I much prefer using the web without javascript, it impacts my laptops battery life by hours. Some sites, are not compatible with this and render a blank page or complain to me that they require javascript to render some text in windows. Meanwhile Amazon has a javascript free clone of their ecommerce site, showing that such herculean feats are possible without reaching for javascript.
- hinkley 3y ago
  Battery life is the silent victim. Maybe browsers should name and shame websites that are heavy.
  - quickthrower2 3y ago
    I would love to know how many milliwatts a page is using? Any way to find out?
- Dylan16807 3y ago
  Sites should work without javascript, but I think it's fine to demand a somewhat up to date browser in that case. For features that have been very widespread for enough time, it's okay to have a javascript polyfill as the only fallback, in general.
- standardUser 3y ago
  > Compatability is only better if you make the assumption that all your users need to be using javascript Are any companies foolish enough to assume otherwise? I understand there is a minuscule number of users who don't want to run JS in their browsers, but aside form Amazon and their near-unlimited resources, who is catering to that small number of users?
- joegibbs 3y ago
  I think that is a pretty good assumption to make. The vast majority of websites are being made for the average person to use, and the average person is using one of the big browsers with more or less standard settings. You could write a website that doesn’t use JavaScript, is meant to be accessed primarily through curl, etc but if it’s a business project then you’re going to end up with a product that your users (average people) will view as more janky than otherwise, and you’ll spend more time and money on it too, for the benefit of 0.01% of the population who would be slightly inconvenienced if you didn’t.
hinkley 3y ago
I briefly contributed to WURFL before I got out of mobile. Being able to figure out limitations based on UA I think has a place in the world because you can generate script tags for polyfills in the head based on which you need. But now that I’m saying this, I think an attribute for script tags that only load if the browser doesn’t support feature X (or any feature in a set, so you can roll up polyfills that tend to be needed together. That could be backward compatible because existing browsers would just load everything, and new ones could negotiate.
yetanother12345 3y ago
> I hope we eventually get to a place where browsers that don't support these features Uhm... I wonder whatever happened to "decay gracefully"?
- demosthanos 3y ago
  Define "gracefully"? The standard behavior of "render unknown elements as if they were a div" isn't viable for more complex elements that aren't just content holders. Alternatives that involve developers specifically coding a backup component are more expensive than just writing a bespoke component in the first place. What sort of graceful decay are you imagining for these cases where a whole widget is missing or is implemented differently across browsers?

_the_inflator 3y ago

I side with you. Sadly, the article itself is of no use and only a rant, since the “you” in “you don’t need” is not defined. Have fun checking for mobile, tablet, desktop, Android, Apple, Chrome, Firefox. It is not that developers rejoice over creating controls all the time. There is still html and css involved.

fingerlocks 3y ago

> The color picker is neat, but extremely nonstandard When I press the button on my iPhone it brings up the actual system native color picker. It’s the same control that appears in dozens of apps because it’s provided by the OS. I much prefer that over some bespoke thing.

demosthanos 3y ago
You do, but companies don't. A major advantage of a browser app over a native app is having one system that behaves relatively consistently across all platforms. This isn't just cosmetic: providing customer support for a web app that has exactly one expected set of behaviors is far easier than asking your support agents to keep track of the constellation of different features users might have access to depending on their platform. The color picker control is the antithesis of this consistency: not only does it look different across platforms (making it harder for CS to walk customers through something over the phone), it provides different features depending on the platform. Some users will be able to pick an arbitrary hex code, some will be able to pick colors off the page, and still others will be given a tiny set of fixed choices. HN's audience might prefer that because they know the platforms they use extremely well, but the average caller to a customer support desk doesn't know their own device that well. If we instead write a bespoke control, you (being technical) will be able to figure it out, and the people who call in to customer support for help will all be seeing essentially the same thing. EDIT: And note that when I say "companies don't", I'm not even just talking about the SaaS vendor. Oftentimes the customer is also a business that has an internal support desk that prefers consistency.
- drdaeman 3y ago
  > that prefers consistency So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved.
  - rhapsodic 3y ago
    > So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved. How would that work if the app had to work on both desktop and mobile? And, how easy would it be to make sure all users were using the same model and make of mobile device?
  - wlesieutre 3y ago
    Because as a customer there’s nothing that makes me happier than when I contact customer service and they say “our website is made for Windows so you’ll need to use the exact same OS as us”

superkuh 3y ago

Nope. Javascript means that if it fails then it completely fails and the content is not there at all. While the HTML examples may not look correct in older browsers, the actual content will be there. With JS it's just nothing. Nothing at all. It completely breaks accessibility. With HTML my screenreader can at least still read it. JS generated content prevents this. No amount of polyfill or other JS can save JS when JS cannot JS. It's terrible for accessibility unless it "works" to start and in that case your point is moot.

demosthanos 3y ago
None of what you said is an inherent problem with JS. The company I work for has JS app that is resilient against the missing-content problem you refer to. It is also more accessible than any other web app I've ever seen in my life. There's nothing about JS that breaks screen readers: you just... generate the right HTML with the right attributes. The problems you see with JS apps that don't work are apps written by people who don't care about their app working and don't care about accessibility. That's orthogonal to whether a JS app maintained by a competent team can have better cross-browser compatibility than one (by the same team) that leans entirely on new HTML and CSS features.
- CharlesW 3y ago
  The parent commenter is saying that JavaScript in the browser MUST NOT be a dependency for core functionality because it may be disabled ("when JS cannot JS"). If your site is popular over Tor — that is, if it's used for warez or by whistleblowers and journalists who need to browse privately — this may be good advice. If it's not, people who disable a core aspect of the browsing stack are savvy enough to enable JavaScript on a site-by-site basis when necessary.
- rado 3y ago
  Sample URL?
- superkuh 3y ago
  >more accessible than any other web app Well there's our difficulty communicating. I'm talking about all web sites, not just applications that happen to be run in a browser. A regular HTML page with text in it is far more accessible than any application depending on execution could ever be. Web applications can, in very rare cases be made accessible (assuming you have perfect execution and JS feature support in the browser). But actual web pages always are. 99% of the time if you can do it with just HTML and text/images you should.

lelandfe 3y ago

The <dialog> element actually has deep support at this point, and the polyfill for the few percent of your users on 2021-era Firefox or Safari is totally fine. I highly recommend the element if you're making modals; the accessibility gains are fabulous.

MattGaiser 3y ago

> but because customer support will find it harder to help people. This is a big one. At a past job we actively discussed this and instead decided to use JS over things like datalist due to it potentially increasing the CS burden. Datalist specifically was tried, but the inconsistent results meant it had to go. We eventually ceased support for all browsers but Chrome as well due to the inconsistencies.

kjkjadksj 3y ago

Compatability is only better if you make the assumption that all your users need to be using javascript. I much prefer using the web without javascript, it impacts my laptops battery life by hours. Some sites, are not compatible with this and render a blank page or complain to me that they require javascript to render some text in windows. Meanwhile Amazon has a javascript free clone of their ecommerce site, showing that such herculean feats are possible without reaching for javascript.

hinkley 3y ago
Battery life is the silent victim. Maybe browsers should name and shame websites that are heavy.
- quickthrower2 3y ago
  I would love to know how many milliwatts a page is using? Any way to find out?
Dylan16807 3y ago
Sites should work without javascript, but I think it's fine to demand a somewhat up to date browser in that case. For features that have been very widespread for enough time, it's okay to have a javascript polyfill as the only fallback, in general.
standardUser 3y ago
> Compatability is only better if you make the assumption that all your users need to be using javascript Are any companies foolish enough to assume otherwise? I understand there is a minuscule number of users who don't want to run JS in their browsers, but aside form Amazon and their near-unlimited resources, who is catering to that small number of users?
joegibbs 3y ago
I think that is a pretty good assumption to make. The vast majority of websites are being made for the average person to use, and the average person is using one of the big browsers with more or less standard settings. You could write a website that doesn’t use JavaScript, is meant to be accessed primarily through curl, etc but if it’s a business project then you’re going to end up with a product that your users (average people) will view as more janky than otherwise, and you’ll spend more time and money on it too, for the benefit of 0.01% of the population who would be slightly inconvenienced if you didn’t.

hinkley 3y ago

I briefly contributed to WURFL before I got out of mobile. Being able to figure out limitations based on UA I think has a place in the world because you can generate script tags for polyfills in the head based on which you need. But now that I’m saying this, I think an attribute for script tags that only load if the browser doesn’t support feature X (or any feature in a set, so you can roll up polyfills that tend to be needed together. That could be backward compatible because existing browsers would just load everything, and new ones could negotiate.

yetanother12345 3y ago

> I hope we eventually get to a place where browsers that don't support these features Uhm... I wonder whatever happened to "decay gracefully"?

demosthanos 3y ago
Define "gracefully"? The standard behavior of "render unknown elements as if they were a div" isn't viable for more complex elements that aren't just content holders. Alternatives that involve developers specifically coding a backup component are more expensive than just writing a bespoke component in the first place. What sort of graceful decay are you imagining for these cases where a whole widget is missing or is implemented differently across browsers?