jQuery Tools vs jQuery UI


A new library has come out called,“jQuery Tools” that is packed with some visually appealing plugins built on top of jQuery.

Here is their opening line to grab your interest:

Let’s face it: do you really need drag-and-drop, resizables, selectables or sortable tables in your web applications? Websites are not desktop applications. They are different.

This is obviously a jab at jQuery UI

What you really need are tabs, tooltips, accordions, overlays, smooth navigation, great visual effects and all those “web 2.0” goodies that you have seen on your favorite websites.

jQuery UI contains six of the most useful JavaScript tools available for today’s website. The beauty of this library is that all of these tools can be used together, extended, configured and styled. In the end, you can have hundreds of different widgets and new personal ways of using the library.

While there is some truth to the fact that you don’t need each component that jQuery UI provides in most websites. You still have to keep in mind that jQuery UI’s focus is to bring a set of components to the table that you can pick and chose from.

I agree with what the jQuery Tools author in saying that everybody needs overlays and visual effects that this library provides. I just don’t understand attacking jQuery UI right off the bat, instead of augmenting the library and working together with them.

Note: the author says he isn’t attacking the jQuery UI library (in comments). But I think he should still be looking for ways to add the good parts of his plugins into jQuery UI.

From an outside perspective, this library shines and has great potential. However as I dig deeper into the API it looked bad.

Note: Tero from jQuery Tools has updated the API to fix this issue I’m pointing out here. You can see the result of the update in the jQuery Tools release notes. This type of thing should be sorted out behind the scenes from now on, but it was a good learning experience for me personally about where the public / private line should be.


<!-- trigger element -->
<a href="#"id="trigger">Move the mouse over this box to see the tooltip in action.</a>
<!-- tooltip element -->
<div class="tooltip">
  <h3>The Tooltip</h3>
  <p><strong>A great tool for designing better layouts and more intuitive user-interfaces.</strong></p>
  <p>Tooltips can contain any HTML such as links, images, forms and tables. This tooltip is vertically centered on the top edge of the trigger element</p>


It doesn’t make sense within the context of jQuery.

So apparently, you have to grab the tooltip div, then turn it into a tooltip? Um… what? How do I get multiple tooltips on the page?

Quick, here is the philosophy behind jQuery:

  1. Find element(s) on the page
  2. Do something to them

Typically you would grab elements on the page and then attach the tooltips to them. This is just common jQuery sense.

Note: After reading this article, the author of jQuery Tools updated his tooltip API.

As I dive into more examples of the tooltip, it continues to make no sense. The form example have no way to target inputs that you desire with custom classes or ids. You have to modify the markup before page load to change tooltips. After you load up the tooltips, you are stuck and cannot ditch tooltips, or make new ones from within the JavaScript.

Please, just use the jQuery Tooltip plugin or ClueTip.

Non-jQuery API

So now look at the API where it talks about returning the API instead of a jQuery object by passing api: true … What? We are now forced to exit out of jQuery into a separate jQuery Tools API by passing a variable?

var api = $("#myDiv").scrollable({size: 3, api: true});
api.onClick = function(){ ...

Contrast this to using jQuery UI, you can stay within’ jQuery and modify all settings.

var $myDiv = $("#myDiv").accordion({ 'header': 'h3' });

Then if later we want to change an option we can use that same div jQuery object.

$myDiv.accordion('option', 'changestart', function(){ ... });

With jQuery UI, all the plugins work with jQuery and it’s philosophy. Working with John Resig’s supervision and incite. Working together. Returning a separate API has some potential, but not the way it is implemented here.

jQuery Tools flying solo

All this means (from what I’ve seen) is that the author did not take the time to learn the why behind jQuery and decided to go his own route, then flame jQuery UI and give you some shiny effects. The effects have potential, but the author needs to open up the code and start collaborating instead of going it solo.

Note: discussion has been opened up between jQuery UI and jQuery Tools teams.

Keep it real, y’all


  1. Frank says

    Besides what you wrote, all what jQuery-tools offers is either easily made with a few commands in jQuery itself, or are an already existing plugin. I don’t see the ‘new’ or ‘wow’ effect here. And as jQuery-ui can be customized for downloadable size (just select only tabs on the download-page) and there you go.

  2. Ric says

    I gotta say I love jQuery Tools. If I just want tabs and overlays on a given site it’s an overly heavy and tedious task with UI, whereas with Tools it’s a matter of minutes to get them working. And it’s light: say I only want tabs. 3.21 kb in Tools. jQuery UI? ~122.7 kb (minified). How crazy is that?

    There might be a point to your api criticisms but it also makes sense to have an easy access to api. The way I see it, the author’s taken the best of both worlds. He’s created great jQuery plugins while respecting common programming practices. I totally respect that.

    By the way, the source code is as open as it gets. On the Download page there are links to the source code for each tool. Every tool is licensed with GPL2 and MIT – just like jQuery.



  3. EM says

    In fact nowdays we need all those (drag-drop,sortables, resizables etc) but jQueryUI still does not have some basic, much needed, WEB UI elements like Buttons, menu and Grid. I am sure that the developers have their reasons for the plugin priority they have chosen but still can think of situations when u need spinner, autocomplete or progressbar before the buttons and menus.
    That said i am aware that these elements are much more complex and i know they are coming to jQueryUI, but i just wished there was more effort put in them.

  4. says


    I’m the author of jQuery Tools. I spotted this from twitter which is pretty hot about this topic. Never really thought that it would be such huge. I’m feeling almost frightened at the moment.

    Couple of things I want to say.

    – first and foremost: this is not a fight against jQuery UI. I have loved jQuery since it’s version 1.1 and still do. My intention was simple: to provide a library that is clearly missing. Almost all libraries out there: (extjs, jquery UI, YUI, qooxdoo, GWT) are focusing on making web more like a desktop application. I took a different approach: let web be what it is and just enhance it with modern JavaScript technologies.

    – the sources are indeed there on the download page. no need to hide them. really want people to look at them

    – you may be right about the tooltip issue. My thoughts was “grab elements and make them tooltips” – almost the same as “find elements and do stuff with them”. This definitely does not mean that I “have no clue about no clue about how to design a plugin API with jQuery”. One way or another I’m beginning to take your opinnion on this and may change the plugin. This of course breaks old installations but I guess it pays the price.

    – api- flag is indeed proprietary but you need to realize that this is not the default behaviour. by default the plugin works as a normal jQuery plugin. if you want to get access to the api (like many people want) this is just a very powerfull shortcut.

  5. says

    Just to qualify one point mentioned above and on the web site: “The JavaScript file is only 2.5 Kb when minified. Compare this to the jQuery UI library where you’ll have to have 130 Kb of minified code to get tabs and accordions working.”

    jQuery UI Tabs is only 6KB minified and gzipped, jQuery Tools Tabs is 1.5KB minified and gzipped – and that’s saying nothing of the features supported by both plugins.

  6. says

    @Tero Piirainen: Thanks for stopping by. If you aren’t attacking jQuery UI then I would suggest changing some of your language. Your homepage attacks conventional libraries like jQuery UI instead of just stating what you do. By using language like, “Tabs done right”… that is to say the rest aren’t done right, and when they think of tabs, they think of jQuery UI tabs.

    That is fine you are taking a different approach to UI libraries, I understand your point. But please join in on the community by taling to the jQuery UI team if you have plugins that they are, “missing”. They have a mailing list, irc and are very open to talk to. I still think it is arrogance (or ignorance) that you haven’t done this. And partly this article is to point that out so people don’t hide in the shadows doing their own thing instead of contributing to the growing set of jQuery UI components.

    Let me know when you’ve updated the tooltip API. Please simply consider the fact that you are getting elements on the page and attaching behaviors to them. A tooltip is a behavior, not it’s own entity.

    As far as returning an API. I am used to being able to access the API on a per-element basis through the main plugin method. That is how all plugins work in jQuery that I’ve used. By changing this you are confusing your user base and me. Typically you have a string or an object that is passed in. If it is a string it runs a function and an object initializes the plugin.

    @John Resig: Thanks for dropping by and setting the facts right on file size!

  7. Two cents says

    I haven’t played with jQuery Tools yet, but let’s be honest: jQuery UI sucks big time… It’s big, performs poor and the design breaks in some browsers (even the demo’s on the page! how are you ever going to sell it when the demo’s suck?)… (no I’m not going to submit tickets)

    Anyway. The idea behind jQuery UI is great, but it needs a lot of work imho. Maybe Tools and UI can collaborate and do great things __

  8. says

    @Marc Grabanski. “Tabs done right” is a snappy slogan and I like it. It surely is not very arrogant when you think of it. It obviously says that others aren’t done right which I simply agree with. There are tens of different tab implementations on the web and there are even many of them under jQuery umbrella. If you start thinking specifically of UI tabs – there must be something wrong with them on your opinnion too. I feel that other implementations are overbloated, complex or just buggy. Tools / Tabs fixes the situation. Everyone out there: Enjoy!

    It must be noticed that jQuery Tools is a very different product from jQuery UI. According to the front pages only Tabs can be found on both libraries and that’s it. Now think of this very closely. If I wanted to make a project such as jQuery Tools under the UI project – this would simply be impossible. A random dude would come to UI project and say: “I want to rewrite the core framework and all of the core widgets”. What would be the response? And who stops me from doing the code I want? I just cannot understand that. Science, computers, linux operating system, politics and everything is based on alternatives. This is called progress.

  9. says

    A small tweak to the intro copy on the jQuery Tools page is probably in order, otherwise let’s not make too much hubbub about it attacking jQuery UI. I’ll give Tools a shot the next time I need something it does and see how I like it, mainly because of previous positive experience using FlowPlayer. That doesn’t mean I’m going to stop using UI. Those complaining about UI being bloated are most likely, as others have noted, just dropping the entire combined library into their pages, which is pretty silly.

  10. Karan says

    While your JQuery Tools’ constructive criticisms may be valid, I think you’ve taken this arrogance thing way too far by making a very bad assumption, “This is obviously a jab at jQuery UI”. Says who? Most JS libraries UI components seem to try and make the browser into a desktop app,and I was finally happy to see one that wasn’t, written for my favourite javascript library (JQuery).

    I really don’t want to get into a flamewar, but if anyone needs a clue, it’s the person who suggested integrating JQuery Tools into JQuery UI. They serve two completely different purposes and our ‘community’ needs the alternatives.

    Anyways, stop all this nonsense and you two should hug and kiss up. 😛

  11. says

    I dove right into jQuery Tools after hearing the announcement, only to be instantly turned off, as Marc pointed out, by the very first API – tooltip. So, you have to create a separate div for each tooltip, the method is called on the tooltip itself, and it has to be directly adjacent to the parent object in the DOM?! Because of this, I immediately ceased any further development.

    @Tero, your stuff looks great, and to be fair it is an initial release. The “styling the mask” demo is particuarly wowing. Looking forward to seeing future API improvements.

    SEAN O

    p.s. @Marc, this article – barely 6 hours old – is already ripped off and is the first Google hit for “jquery tools vs jquery ui”:

  12. says

    Well.. Every time i needed a simple tab system i use my own script. Is smaller than any of those things (few lines of code) and contains exactly the features i wanted to contain.

    The final code weight is less than 1kb not compressed and not gzipped. I will post it on my blog soon 😉

  13. KarateRobot says

    He’s allowed—in fact, encouraged—to compete with jQuery UI. That means he’s allowed to point out the weaknesses in UI, and to claim that his library is better. We can all agree or disagree, hopefully with reasonable analysis, like most of your post.

  14. Matchu says

    I really hope the two teams work together on this, because both libraries have things I like, both libraries need work, and I really don’t feel like including both when I require elements from both.

    Given that, I’m tempted to use JQuery UI plus any additional plugins I may need to accomplish what JQuery Tools has to offer, since at a glance it seems like almost everything there is offered already via preexisting plugins or SWFObject (flash embed). Not my judgment of the libraries, but just what seems best for my particular site’s needs.

  15. says

    I’ve just recently discovered jQuery-ui and found visual sorting very useful for clients. Being able to rearrange items visually makes it much easier for them to understand than alternative methods. I’ve also used the datepicker, another tool that enhances usability for end users. I have yet to use jQuery Tools, but completely disagree with the author’s argument against jQuery-ui.

  16. says

    @Marc: Just wanted to point out that many open source users have little idea (or lack the confidence) about how to get involved in a project, especially in one as visible as JQuery. You can’t attack him for not openly communicating with the JQuery UI team because he may not have this experience (or desire … maybe he just wrote this for himself, said, “I think others might like this, I’ll turn it open.”). I know it took me a long time just to put in a bug report for one project I used. :)

    I think the JQT author was just looking for marketing pizazz when describing his extension. Most people will cherry pick stats and such to make their offering look good. It’s not arrogance, it’s just trying to build enthusiasm.

    Anyway, as most people have stated, I hope there’s some ability to reduce the heat here and focus on what’s important…what is missing from JQuery or JQuery UI that inspired JQuery Tools? All of us are looking to consolidate the plugins we use and stretch the features we can support.

  17. Alex says

    I’m rather certain people working on jQuery UI have taken note and will do some things differently in the future as a result of all this.

  18. says

    Hey everybody! I appreciate your comments.

    Apparently some people are upset with me for calling his actions arrogant for doing his own thing and not collaborating with others. Now look, not only is he doing his own thing, but he also keeps saying his plugins are doing things the, “right” way. When I just showed you logically why I think this is not the case. So, I stand behind saying this looks to me like arrogant behavior.

    This is not the first case I’ve seen this. I’ve seen many plugin authors looking for the glory by releasing their own plugins with a shoddy API and not working to make the good plugins any better, or leveraging existing knowledge base, or reach out to the community for feedback. Unfortunately I have to make this case with jQuery Tools.

  19. says

    I’m happy to see that there are people out there that aren’t settling for what jQuery UI has to offer, create their own solution, then give it to everyone.”

    I read what the author wrote (before seeing this blog) and all I saw was someone who was really excited about his product, and put in a little more marketing spin than the typical dry techie writeup.

    While I use UI all the time (and love it) it’s not the end-all-be-all. I’ve been using it for over a year and find a lot missing and a lot of problems. And the docs are scary bad.

    So I LOVE the fact that people take the initiative and do their own things. And I use these things woven into my UI code. Isn’t that the whole point of open source and community?

    I’ll be using some of his code woven into my future projects.

  20. Alex says

    Aggressive marketing is still just marketing. There might be some point to what you’re saying, but then not really, as there in fact doesn’t seem to be much direct competition in the light-weight, easy-to-use, useful in your everyday web development -categories. Which means his solution is indeed right for a lot of people, especially given the buzz and enthusiasm. So let’s see something else like jQuery Tools that’s possibly better and only then dismiss it.

  21. Marty says

    I’m glad that jQuery Tools was shown to the public. We’ve got a debate here. Ultimately, we should be giving feedback to improvements to the initial release of jQuery Tools.

    Obviously, there is more work to be done to jQuery Tools (including the tooltip issue mentioned here) and make it 100% jQuery-ified (is that a real word?) to gain greater acceptance by the public.

    As for flames between people – chill out. There is life outside the interwebs 😛

  22. says

    jQuery Tools does fulfill a different need than jQuery UI — though, I believe with some work these things could add to jQuery UI instead of being separate. The only thing I am fighting about here is that these API issues could be resolved by joining in the community and getting feedback instead of flying solo. That is the whole point of open source. jQuery Tools unfortunately just became the target for my point to be made.

  23. Pete says

    To be honest, I’ve found the jQuery UI team to be very defensive about their code and un-encouraging to participation. They seem to place a very big emphasis on their process for doing things and adding them to the library (first document in the wiki, etc etc). Which is valid I guess when you want a consistent and large library. But there are bits of obviously bad (well – unpolished) programming in their plugins and they don’t seem open to people helping with it. Even simple stuff like unused variables sitting there in the code and backwards approaches to algorithms.

    So I’m not surprised that someone else has taken a different approach and I have no problem with them promoting their solution by calling it the “best” or by saying it’s better than others (with no mention of jQuery UI – it definitely seems you are defensive about that for some reason). Anyone can “sell” whatever code they like and if people like it then they’ll “buy” it. While I understand and appreciate the amount of work that’s gone into jQuery UI it’s definitely far from perfect and I think it is the most political (in terms of the team thinking of their own importance rather than the good of the library) open source project I’ve ever had any involvement in.

  24. says

    I have personally found the jQuery UI team to be very helpful and open to suggestion. I was working through some bugs myself in the UI core and they pointed me in the right direction and helped explain the browser quirks. I use the effects core and other UI plugins regularly crossbrowser without any trouble. UI did have some bugs in early major releases, which is why they are so meticulous about ensuring that the best fixes are committed for each release.

    Honestly, if anyone thinks they can write better UI code, please post the bugs and fixes at dev.jqueryui.com. 1000s of jQuery users would appreciate it!

  25. Alex says

    The only thing I am fighting about here is that these API issues could be resolved by joining in the community and getting feedback instead of flying solo. That is the whole point of open source.

    But then we’d have only one solution, which can’t be the point of open source. The developer’s already said he’s taking your advice into account and might do changes in his code in the future. (I’d also be curious to know how perfect people feel jQuery UI was at 1.0.0.)

    He also said he feels there’s a lot of possibly fundamental problems with jQuery UI. Do you feel there’s any way for one person to change that? If so, why is it a better option than offering your own solution? Is there some strict code to how open source must be developed? While a million people might hold a huge power in their hands, there’s also some truth – well, a lot of truth! – to the saying “too many chefs…”.

    Seriously, look at big companies where each and every decision goes through dozens of people. I’m sure nobody wants to see jQuery UI turn into Windows Vista of open source, so this can all only be good. At the moment I feel there’s a chance Tools could become more popular than UI given its simplicity and the (mostly healthy) arrogance and aggressive marketing they have.

  26. Slash Smiley says

    “Now look, not only is he doing his own thing, but he also keeps saying his plugins are doing things the, “right” way.”

    Actually, that part of the discussion is particularly salient to me…I think that jQuery is suffering from a bit of plugin dilution (jQuery being such an easy, extensible framework, there are a million examples of badly coded plugins for every great implementation.) If someone thinks they did something right, that’s ok. It’s good to be better, and our apps are better for it.

    If it’s not better, so what. I wouldn’t fault the guy for saying he has a better solution for something…that’s the art of the free market. This whole thing sort of smacks of sour grapes.

  27. says

    Totally agree with:
    Let’s face it: do you really need drag-and-drop, resizables, selectables or sortable tables in your web applications? Websites are not desktop applications. They are different.

    I choose jquery beacuse of the plugins i dont care about what is under that, i dont have time for it.

  28. says

    I totally agree with Alex and I’m happy that he has better skills to say the things I would like to say too. I disagree with Marc that jQuery Tools has some kind of “API issue”. On the contrary. You want my API to

    // behave like this
    tabs(“select”, 1);

    // instead of this

    The first one is the UI way and second one is the Tools way. Second one is also what most of the programmers are accustomed to. Since Tools is not part of UI I can do that. In my opinion there is no API issue in the Tools.

    After getting slapped to my face I feel tempted to write my own comparison. I would talk about the project goals, coding practices, consistency, documentation and a bit of “theme rolling”. With a hint of arrogancy of course. Well – I won’t do that. I’m not a blog writer – I’m a tool writer.

    I will fix the Tooltip issue you pointed out. Thank you for that and I’ll let you know when it’s ready.

  29. says

    I can’t possibly rebuttal each argument. All I can say at this point is that if anyone has feedback or comments on how to change jQuery UI, then please post on the UI mailing list. I assure you they are doing everything they can to listen to you to make it the best library possible.

    Tero, I respect the work you are doing, regardless if we disagree on how your API fits into the jQuery landscape. I agree with you writing out project goals, coding practices, consistency and documentation just as you said, so that people like me don’t jump to conclusions and end up “slapping” and getting “slapped”. Lol, arguements are fun aren’t they?

    I do think this post brought up some very interesting discussion. We just need to take what we can agree with and bring it into producing and collaborating.

  30. redsquare says

    I dont want to join the tit for tat fight. Just want to put my views across.

    I have discussed jquery-ui at length with various people, including a few of the regulars over on the freenode irc forums and the general consensus is that it tries too hard to pack functionality, options and features at the expense of speed & robustness & quality assurance.

    I believe there is a place for a framework of widgets that come in a much lighter base format that allow for fully featured extendability with ‘optional’ extras. As a quick example, the ui-draggable widget comes preloaded with a plethora of options (30 ish). Could this not have been split out into a base-draggable with the ability to snap-in the extra features. I hope its not too late to refactor out things like this. It seems the widgets are coded for the exception rather than the norm. I’m not sure why this design decision was taken.

    There are some great brains behind the ui design & dev, leaps above what i could ever achieve and the work they do is greatly appreciated but I always have a performance devil sitting on my shoulder everytime I visit the ui download page.

  31. florin says

    Wow. Do some get rubbed the wrong way. Let me say that the Tools look great and the tabs look way better than the jquery ui. I’ve tried several times to use the jQuery ui and I always end up going for something else.

  32. Daron Robinson says

    I enjoy using jquery UI, but it does seem to be a bit heavyweight, having a lighter weight “rival” around may help jquery UI in the long run, not hurt them. Nothing inspires extra effort and excellence more than a bit of competition, even if a few smackdowns are thrown around the end result is better for all.

  33. says

    I saw the announcement (via twitter) about Tools, went to the web page, and could find no compelling reason to use Tools over UI.

    After reading this post and the comments, I still have no compelling reason.

  34. says

    Same as last comment. What i dont like about JQT is that it fails for me at first sentence:“do you really need drag-and-drop, resizables, selectables or sortable tables in your web applications?“My answer is yes, yes i do need drag-and-drop, resizables, selectables or sortable tables in my web app’s. Kudos for enthusiasm but i like JQ UI and it’s offer from which i can strip down exactly what i need, ot just use thw whole bunch.

  35. emkay says

    while I like the idea behind jQuery UI the direction it has taken is a no-go for me. It’s a designer’s nightmare. Obviously (unless I’m missing something) you either go with themeroller which makes it fail css(2.1) validation or you take a week off to disassemble and re-style all the injected ids and classes on foot. If I need tabs, I just want tab markup and tab styles. period.
    The criticism concerning the API behaviour might be appopriate. I’m all for standards but I have to admit I’m not an expert here.
    But if “right” means “easier” (which btw is my idea of jquery. less code – remember?) than JQT is indeed “tabs done right”. JQT might not be as feature-rich as JQUI but hell it’s young, slim, easy to use/style and done by a (afaics) responsive and constructive author.

  36. Alex says

    Great. So let’s discuss jQuery UI now shall we? The more I look at it the more baffled I am why anyone would use it. Let’s face it, it’s true that in your everyday web development you won’t want resizables or drag’n‘drop (unless you’re doing bad web UI design either purposefully or out of ignorance).

    Now, if you’re creating applications that truly need them, like an online office suite or something, then you’re probably going to want (as well as be capable) to also create your own drag’n‘drop etc. instead of the bloat that UI has become.

    Looking at UI you rather quickly realize there’s a lot of other problems as well, probably due to bad project management or simply “too many chefs”. Cross-browser support in some of the simpler applications seems sketchy in some demos, for instance. (What’s with the themeroll fixed div naming…? There’s an API problem for you.)

    It’s clear who Tools is aimed at, as pretty much anyone can use it, but who is UI aimed at?

  37. says

    @Marc : I am referring to the statement “The effects have potential, but the author needs to open up the code and start collaborating instead of going it solo.”

    While I don’t appreciate jQuery tools for indirectly mocking jQuery UI, I don’t see why sometimes going it solo is a bad thing at all. jQuery UI have matured on their own and sometimes it’s hard to change the direction of the library as so many people have been using it. In the spirit of competition, I would very much like to see projects being worked on the sideline afresh with different a philosophy, and that’s how breakthroughs/diversities are created.

    It seems to me that this “collaborate or you are alone” mentality is rampant in the jQuery camp.

  38. says

    @Alex: if you identify browser issues, submit a ticket on trac. Most issues that I’ve seen have been resolved in the latest point releases. Size complaints can be understandable, but not everyone is able to code the exact amount needed for their application – so because of this, libraries need to have a lot of settings and hooks. “Other issues” is ambiguous.

    @Royal: developer independence is sometimes good for innovation, but also can lead to forking and dividing communities which otherwise could have been much stronger.

    @Kean: I agree that sometimes you need to, “fly solo” to break out of the box and try a completely new thing. But at the end of the day, every developer should consider reigning in those independent ideas and contributing them back to the greater health of the community in which you are a part of.
    I commend Tero (jQuery Tools author) for what he is doing as well, I was just not pleased with his initial API (what I saw of it) — to which he has agreed to revise the tooltip API.

  39. james says

    The first time I see jQuery tool is that I am happy to see a person point of view in a different perspective, I agree that many JS UI library are trying to make web look like desktop, which I think it is really hard to develop. A good example is Gmail vs Yahoo Mail.

  40. darcon3371 says

    jQuery tools is good, but no datepicker … and I often use for my applications, so I stay with jQuery-ui.

    Although it is a good alternative

  41. says

    Thanks for all your help Tero on the API fix. There is good dialog going now between the jQuery UI and jQuery Tools teams and everyone is reaching a better understanding of the work that lies ahead.