Comment by wruza | Hacker News Reader

Comment by wruza | Hacker News Reader

Parent Full thread

why annoy users with a custom component

Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.

My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.

That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.

That's totally on point, but I think the core issue is less about "why the native date picker isn't always appropriate" and more "why do we keep half-assing non-native alternatives?"

The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be developed in JavaScript that would serve everyone's needs, be totally accessible, and not a bowl if <div> soup. So why don't we do it? Why are what should be basic HTML forms on corporate websites difficult to navigate or in some cases fundamentally broken, requiring workarounds? Nobody is interested because solving real problems doesn't carry any of the prestige of building another framework. Who wants to build a date picker that is standards compliant when you could write another web framework, bro? Even if a developer is not trying to build the next React, they're probably spending more time on their toolchain than actually coding. It's gotten so bad that seemingly every company I've joined in the last 6 years needs a bunch of people dedicated to maintaining toolchain and CI crap for the rest of the team.

I love programming, but the web needs to get its head out of its own ass. We're acting like our jobs are more important than the value the software delivers, and more effort is being put into making sites impractical for machines to parse (because muh intellectual properteh!) than in making web components that aren't riddled with bugs.

There’s a little more harshness than needed in your comment, but I generally agree with it. Having brought this up before, I’ve usually seen either no or strange reactions to it. It feels like web dev consists of people who only have done their job for an unknown faceless client sitting behind layers of teams and toolchains. Driving to a specific person, listening to their brutal feedback on your system and being asked to maybe fix it right now would be a sobering experience to some of them.

You're absolutely right on the 'why' part, but sadly a lot of custom implementations are annoying in terms of UX and accessibility. My only point here is that building proper custom components is far from easy, it takes a lot of time and effort.

Reply on news.ycombinator.com