Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hahaha wow I have to say that was the least convincing demo I’ve seen.

- Fills history with massive amounts of entries, and back button doesn’t do anything

- Slider UI look like crap (ok fine, can be fixed) but use not just css but SCSS (requires a precompiler) but wait, not enough, it also needs hardcoded number of images. It’s not reusable in the most basic sense.

- Input validation has phone number on xxxx-xxx-… format and doesn’t fill dashes automatically. It’s also type=number which opens a numpad on iOS which does not have dashes available at all. I can’t proceed unless copy pasting a dash from somewhere else?

- Gave up after that but I’m sure there’s plenty more

Yeah, I’m leaning towards that JS isn’t the nemesis of accessibility. It’s simply not knowing what works and testing properly. It’s funny that frontend folks are seen as lesser beings and then counter-claims like this is passed as enlightened. Yeah on first glance maybe, but it’s proof that these regurgitated claims are made with very little insight. Like all tech, you have to know how to hold it right which takes a little time and humility to get right.

And yes, we still use too much JS. But it’s not the fault of JS or dev practices that we have newsletter popovers, cookie banners and 100 ad delivery and click tracking requests per page load. Indeed JS became extremely bloated for a while but nowadays everything is equally bloated, just look at all the backend snake oil with 1000 cloud microservices and leftpad-like APIs.



I disagree. I've built entire sites that rival the most popular SPA's today with HTML / CSS and a tiny bit of JS, and I've had less issues with those than other sites at my agency built with a JS framework. User reports often come in telling me "Wow, this site is so good! I'm really glad you took on this project".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: