Lots of good ideas here but writing your own date picker — both suggested and pictured — is just a silly idea. As a front end dev you are in the business of making products, not managing leap years.
That's a good one. The next time I run into my competitors at a trade show, I'll be sure to recommend they do this.
Just, I certainly agree in this point, just leave the management of leap years to the date data type of the platform. Don't ever, not for a second (leap or not), think that += 24*60*60*1000 could be acceptable. But chances are you'd be far more aware of that wrongness while throwing together some novel date picker than anywhere else you might be tempted, where usually the peculiarities of calendar are far out of scope.
Native date pickers are limited in how you can style and customize them. As a dev, I'd always prefer a native one, but if design wants a unified look across platforms or any unusual behaviors, bespoke might be your only option.
Writing your own datepicker is 99% of the times a rookie mistake.
If I‘m hiring a front-end developer I‘m sure as hell not paying them to write custom datepickers all day.
Development is full of compromises.
And what do you think their job title and experience are?
> If I‘m hiring a front-end developer I‘m sure as hell not paying them to write custom datepickers all day.
This is the opposite of what you said above.
Should every frontend developer be reinventing date pickers from scratch just to demonstrate how good they are? I don't think so.
That's why I said 99%. Maybe there's an 1% or even less where it makes sense to reinvent it because you're Airbnb or Amazon or Google or you are in the date pickers business.
But yes, you are still a frontend developer if you don't do your own datepicker and focus on shipping your company product. And date pickers are built by frontend developers. What's your point?