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

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.


> writing your own date picker

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.


Several years ago I tried to find a good date and time picker, but most were rather bad, and I had to heavily modify a date picker to add time to it. I assume that things are better now.


It's not much better now afaik. I still just default to using separate fields for day/month/year etc. If anything good and fully accessible/mobile friendly/etc. exists I'd be happy to know. The browser native solutions have never been very good as well.


The web has it built in now! Try input type=“date”


But implementing a date picker UI isn't hard at all. If you have some particular extra requirement or a novel idea, go for it. That's also what front-end devs are for, reinvent UI for, I don't know, reasons.

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.


> As a front end dev you are in the business of making products, not managing leap years.

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.


Then you use an existing datepicker library, and customize it.

Writing your own datepicker is 99% of the times a rookie mistake.


Would you not consider the people working on those libraries to be front-end developers?


They are developing those for their companies or in their free time.

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.


> They are developing those for their companies

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.


Yes, those are frontend developers, we all agree with that.

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?




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

Search: