I don’t know exactly where you’re going, (and to be fair the parent comment is rude) but it’s wise to be humble even if you are a professional. Some of the most experienced people in the field frequent these threads, HN is not a monolith of neo-luddites.

My 2 cents: native solutions like HTML and CSS are preferable: they are designed to degrade well, they work with screen readers, with increased font size, high contrast, and other less-known or unknown and even future use-cases and needs. No dev team has the time to test their custom JS solution on all possible browser targets, and in reality they frequently fail even basic accessibility needs for no good reason.

At least to me, honoring the principles of the web is our responsibility, especially in our current time when they are arguably under attack from well-funded players. I would hate to see the web degrade into a delivery mechanism for opaque executables that work only on corporate blessed mega-browsers.

> they work with screen readers, with increased font size, high contrast, and other less-known or unknown and even future use-cases and needs

Where does this idea come from? I’m seeing it all over these comments, and I strongly suspect this sentiment is coming from people that haven’t actually looked at WCAG or been tasked with creating a compliant accessible website. You can botch the contrast, hard code font sizes in pixels, and leave out pertinent navigation details for screen readers with plain HTML and CSS. Here’s WCAG if you don’t believe me (emphasis mine):

> Myth No. 9: Pages With JavaScript Cannot Meet WCAG 2.0: FALSE WCAG 2.0 was designed to allow many new modern technologies to be used and still provide accessibility. Pages with JavaScript can be made to conform to WCAG 2.0. It is also possible to write pages with JavaScript using the JavaScript in a way that would make the pages not conform. It is also possible to create a page using only HTML which do not conform.[0]

There is nothing about using JS that makes a site less accessible, and there is nothing built in to HTML to make a site automatically accessible. The only way you’ll have an accessible site is by testing it manually and bringing in users to find edge cases.

[0]: https://www.w3.org/WAI/GL/wiki/WCAG_Myths

> Nobody cares if you used CSS or JS for a toggle switch.

Other than the people who have to wait several minutes for your 20MB JavaScript framework to load on their slow metered connection just so you can make an expandable section using a bunch of <div>s rather than the native <details> element. But those people don’t matter because they should just move to a country with unlimited fast internet, am I right?

Vanilla JavaScript is supported natively by all web browsers now.

Nobody is suggesting using a 20mb framework to make a toggle switch work on a standalone page that isn’t a web app.

If you’re building a web app either way, then choosing between a screen full of CSS or a handful of lines of js is negligible.

For expanding sections, you should use native HTML elements when they do the job with less effort/code. You should use JS when they don’t.

> Vanilla JavaScript is supported natively by all web browsers now.

What a strange statement. 'Vanilla' JS has been supported 'natively' in browsers since the late 90s.

Or these people are execs on business trips on terrible hotel or remote connections.

Nobody cares because people have been trained on crap software for decades and don't know what it is capable of when optimised well. USP opportunity, anyone?