4 ms·
Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as
by vbo 5y ago
Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages (not the Instagram variety). Basically all "modern" web UI.
- tarboreus 5y agoMaybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be. I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.
- martpie 5y agoWhile I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad". It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...). I think the proportion of front-end developers knowing about accessibility is just low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue. Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website. So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.
- torstenvl 5y agoDid you really just tell a blind person they're wrong about the effect JavaScript has on web accessibility for the blind? Holy crap man.
- hotz 5y agoI think sites that fail the accessibility test should be shamed into compliance. Possibly like how they handle sites that aren't https. I can just imagine how frustrating it must be to have an impairment that hinders usage of a website. Especially if it might be something essential.
- tarboreus 5y agoIt's mostly fine for me, because I'm technical and can do some weird thing or use OCR tools I made myself or whatever. It's incredibly difficult for the average blind person, who is statistically likely also to be older as well.
- tarboreus 5y agoThe reality is that the education you're talking about is never going to happen. By the time you had 80% of devs knowing how to do a11y on JS framework #271, a whole new paradigm would have come in. It's because accessibility is not a priority that accessible defaults, which almost definitionally need to be system- or browser-based, are so important. If you make a form with HTML and style it with CSS, then you're 85% of the way there with accessibility, and chances are it will be usable if you screw the rest up. With JS, even if you're working from a checklist, you're much more likely to get somethign wrong. And then there are regressions. I kind of believe that you know what you're doing, because the kinds of people that hang out on HN often do. But will your second-generation successor, four years from now, know how to update your work without breaking accessibility? Empirically, based on the low level of accessibility on the web (improving, but still pretty tough going), I'd say "no."
- eitland 5y agoGood points. I'm still not convinced it is worth everything we lost: - Instant loading - Sane page sizes - Cross browser compatibility by default, including text based browsers - Every page is reasonably safe by default - CPU is idle after initial page load - Battery life is great by default and probably a few more. I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad pushers and bored developers ;-) Edits: yes, a number to clarify my points and to make it clear that I am open to change my views, at least slightly.
- vbo 5y agoAgree on all counts except instant loading, you can still do server-side rendering (from the same codebase as the client) and have the client library bootstrap/hydrate its state from it.
- deleted 5y ago[deleted]
- easrng 5y agoModals can be done with CSS pretty easily (with either :checked and a label to activate the modal or :target and a link to activate it or with details/summary etc.), so can form validation (the required and pattern attributes), and lazy loading (add the loading="lazy" attribute for images and iframes). Infinite scroll can't really be implemented easily but in theory it's possible with server support (I'll make a demo and get back to you).
- easrng 5y agoHere's the promised noscript infinite scroll! https://noscript-infinite-catfacts.glitch.me/ https://noscript-infinite-catfacts.glitch.me/
- goatlover 5y agoI mostly dislike infinite scroll and am irritated when I see visual things load after the page loads. I also don’t see the point in SPAs for regular websites. The modern web looks better, but sometimes the experience is worse, at least for those of us who were around before. Of course by this I don’t mean actual applications or games on the web. Just standard websites.