I have been using html select boxes or textboxes for date input. On submit, the date is validated and if invalid an error is returned. I have avoided javascript calendars thus far, but jQuery datepicker seems to be a popular choice amongst people on SO. I was updating my app and wondered whether to use a Javascript Calendar(jQuery datepicker in particular). It would be a good "feature" for existing users and will fit the "2011" upgraded look of the app.

I am not using jQuery or anyother JS library. The scripts in use are "plain" javascript. With jQuery, I will have to include jQuery's library in the universal .js files list or link to Google's copy. Either way it will increase page load time. And I understand that with or without datepicker in place, the validation(and the error handling) stays and that the datepicker widget is for visual purposes only. But UI is an important factor.

A positive that I can see is, I might use more of jquery in the future and I will not have to think about page load time and bandwidth issues then.

So my question is, is lugging along jQuery the right decision, when I only see one use in the near future? Or should I use a "plain" JS only calendar widget or should I simply stick to the select or text boxes.

Wanted to post this on SO, but since the topic is more about programming practices and decision making, I am posting the question here.

3 Answers 3


@Alexey pretty much has it, but from where I sit...

If you want a nice date picker there is bound to be a bit of overhead regardless of which you pick, in addition you want to choose something well developed and functional.

So, accepting that you're going to take a hit, the question becomes how big a hit are you prepared to take? Using a standard library (and jQuery is excellent) means you can pull from a CDN hence benefiting from both speed and caching and leaving just, in most cases, just the custom UI bit as specific to your site.

Once you have jQuery then other opportunities open up (e.g. auto-suggest lists become fairly trivial) - and if UI is important then use of (something like) jQuery is going to bring benefits.


Id suggest to give jQuery a try. In minified version it is 83 kb, and you can deliver it with MS, Google and jQuery own CDNs.

One day you might want to add Dialog boxes, AJAX and other stuff. BTW SO uses jQuery and it is ok=)

Also some browsers can load js in parallel. You can use jQuery and add only DatePicker plugin from UI.

  • Thank you for the parallel tip. Do I have to modify the source for that or is it done automatically?
    – abel
    Feb 2, 2011 at 8:42
  • 1
    AFAIK it depends on browser and its capabilities. For example try to watch some site loading using Google Chrome Resource Tracking. Also Http/1.1 spec suggests that browsers should download no more that 2 resources in parallel from one host name. So if you will use CDN for jQuery, it wont cost you a lot=) Feb 2, 2011 at 8:47
  • 1
    Look out, though! This is how jQuery creeps into your development toolkit. First you need a calendar widget, then you realize you need to style your radio buttons some fancy way, then one day you discover the elegance and power of jQuery object selectors, and next thing you know you're dreaming in jQuery.
    – Dan Ray
    Feb 2, 2011 at 13:15
  • 2Dan Ray: Good point =)))))))))) Feb 2, 2011 at 13:31
  • No browser currently supports parallel JS. It's pseudo parallelism - html won't block on loading JS, but it'll block on executing it and no more than one JS file can load at once.
    – Slawek
    Feb 2, 2011 at 16:56
  1. Google CDN is sometimes slow (waiting 5-10 sec to load the libs). I mean come on - compress it using GZIP and the size will be around 30kb, much less than any image, you don't need CDN for that.
  2. Browsers can't load JS in parallel, moreover all javascript code is limited to one CPU core (single threaded), you can use defer of course but it is causing problems, probably your scripts wont work with it. Plus defer will only cause HTML rendering won't block on loading JS, the code is still limited to single thread.

But you'll probably need JQ anyway and it isn't too slow (compared to some crap like DOJO UI that'll freeze all versions of IE for a couple of seconds before even simplest layout can load).

You should consider using mootools, much better and faster lib, that encourage better coding habits. But it's also harder to learn, but then the code is easier to read...

Just pick carefully. IE can't handle more than a couple of libs, premade JS UI controls too well. Already made code (Yahoo UI, Dojo) is very low quality and very slow, if you're so fortunate that you can drop all IE users - you have nothing to worry. You can include half of JS crap ever invented on your website and it'll work rather well... but not in IE ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.