jQuery Tools vs jQuery UI
VS 
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, but before we dismiss what they have to say let's read on...
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 favourite websites.
This library 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 the arrogance of 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 onto jQuery UI.
From an outside perspective, this library shines and has great potential. However as I dig deeper into the API and intensions it just looks 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.
Tooltip
Demo (hover over box):
Tooltip Implimentation
HTML:
<!-- 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> </div>
JavaScript:
$('#tooltip').tooltip();
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:
- Find element(s) on the page
- Do something to them
Is the tooltip on the page? nope, not yet. Ok, failed #1. Where do we go from here? 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 seperate jQuery Tools API by passing a variable?
JavaScript:
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.
JavaScript:
var $myDiv = $("#myDiv").accordion({ 'header': 'h3' });
Then if later we want to change an option we can use that same div jQuery object.
JavaScript:
$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 seperate API has some potential, but not the way it is implimented 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
Comments are closed.
Comments
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.
Cheers,
Ric
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.
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.
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.
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!
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 ^__^
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.
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. :P
@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":
http://www.ozelwebtasarim.com/index.php/web-haberleri/14971-jquery-tools-vs-jquery-ui
The final code weight is less than 1kb not compressed and not gzipped. I will post it on my blog soon ;)
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.
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.
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.
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.
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 :P
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.
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!
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.
"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.
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.
// behave like this
tabs("select", 1);
// instead of this
tabs.select(1);
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.
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.
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.
After reading this post and the comments, I still have no compelling reason.
"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.
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.
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?
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.
http://mootools.net/blog/2008/12/04/sizzle/
@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.
OK. Now it's done. I've fixed all the issues mentioned on this article. Here are the new features of jQuery Tools 1.0.1.
Enjoy!
Although it is a good alternative