Hacker News Reader

Comment by andrewstuart | Hacker News Reader

>> Do this only if you don't care about the people that use (sometimes: have to use) your software.

Rubbish. Web technologies are way too sophisticated to boil down to some silly rule of thumb that “the least powerful technologies are the” best in some way.

As a professional developer, use every technology at your disposal and use it in whatever way you like, including the most advanced techniques.

Ridiculous to be given the most one of the most powerful development tools ever made - the web browser - and artificially constrain how you use it for some dogma.

And if you’re a junior developer, ignore people who tell you how you should program - do it how you like unless the boss says different.

View on HN

The article seems to be suggesting to remember to use the power the the web browser already provides instead of needlessly using frameworks.

The walkthrough in the article seems to demonstrate pretty effectively that the powerful development tools offered by a modern browser may obviate the need for elaborate frameworks in many cases.

Where this is the case, then, relying a framework instead of the tools the browser already provides artificially constrains an application, potentially for dogmatic reasons, and regardless of a developer’s level of advancement.

Browsers have rapidly come a long way even just in recent years. Frameworks well and truly have a place, but narrowly relying on frameworks, particularly out of beliefs about browser capability established years ago (like when React was introduced), can neglect browser-native functionality that can provide same-or-better results, with potentially better outcomes in performance, accessibility, maintainability, and more.

> As a professional developer

This qualifier probably applies to >90% of this website’s audience, so I don’t think it’s useful.

Using less power if you can get away with it is absolutely sensible. If my implementation is suitably robust without the use of type families, data kinds, singletons, lenses, etc., then that’s a more economic solution.

Sure, I guess. Just act like all of those vision impaired folks don't exist, and put the entire website in JS that their screen reader can’t handle. Nice.

Remember kids, if a minority is a "rounding error" it's okay to ignore, block, and hurt them though your profession. That's what webdevs tell me.

Disabling JS doesn’t magically make your site screen reader friendly. It’s entirely possible to create a shit layout that uses no JS and is just as horrible to use as a shit layout with JS. Likewise, adding JS doesn’t magically make your site non-screen reader friendly.

What actually makes a site screen reader friendly? Developers that actually write accessibility tests, tab through their site manually, open it with a blindfold and a screen reader to make sure they can navigate it, etc. This myth that no JS automagically enables accessibility needs to die.

It's even more ridiculous to bring the browser to its knees, destroy performance, and accessibility, because the trendy framework made your dev life easier.

Your web app is most likely rubbish and 20 times as complicated as it needs to be, and probably still nothing special.

A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.

> A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.

Are users happy? Is dev speed of improvement good enough? Can you onboard new devs easily enough?

That’s it. Nobody cares if you used CSS or JS for a toggle switch.

The only people who disable JavaScript in their browsers and expect the 2023 internet to accommodate them are right here in this thread.

Just componentize it and move on to solving the next business problem, not the next code elegance problem.

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?

Sure, maybe if it accomplishes exactly the same. That’s why I disable JavaScript on most news sites. But in the real world most web apps simply can’t accomplish the same without JavaScript, which is why we use JavaScript.

Reply on news.ycombinator.com