For full disclosure, I used jQuery with Domino long before v8.5 at a time when the dojo documentation sucked big ones and it was nearly impossible to figure anything out. Today though that is much improved and the dojotoolkit website and the work done by sitepen have done a lot to catch up.
I am more familiar with jQuery syntax and the core library capabilities and I think I will always prefer to use jQuery than dojo given a choice and even playing field. In traditional Domino it is a level playing field as neither library is loaded by default. But that all changed with XPages and I am forcing myself to have to learn dojo because it just doesn’t make sense to use jQuery “just cos dojo sucks”.
jQuery does not conflict with dojo and can be used very successfully in tandem with each other. But there are some things to consider before you do.
jQuery selectors are IMHO easier to read and more intuitive to understand. jQuery uses a combination XPath/CSS query selection process and dojo uses a CSS3 selector paradigm
So why shouldn’t I use jQuery?
If you are going to add jQuery there has to be a good reason/purpose other than “‘cos I like jQuery and dojo sucks”. If you add a jQuery library you are:
- adding additional overhead to the database
- adding potential maintenance issues down the road
- adding to the download size of every XPage which already has the dojo overhead by default.
- (Yes you can turn dojo off but why would you? If you not going to use the XPage functionality don’t use an XPage design element……)
So if you are just doing a basic selector to get a page element or a basic animation, there is really nothing dojo can’t do any worse than jQuery. If you want to see a simple comparison between dojo selectors and jQuery selectors check this out
Dojo & jQuery side by side. Part 1: DOM Basics
Dojo & jQuery side by side. Part 2: Animation
So when should I use jQuery?
When you can’t do something you need to in dojo, or just just does not make sense to re-invent the wheel. jQuery is now more popular than Flash in terms of web usage for the most popular sites. dojo isn’t even on the map when it comes to web usage tracking. In terms of community size and usage jQuery dwarfs dojo everything else and because of that there is a lot of libraries to chose from.
In an XPages environment, the real benefit is not so much using jQuery itself, but in taking advantage of the thousands of plugins available which other people have written. There are plugins for everything from:
- Menus
- Calendars
- Embedded video players
- Photo galleries
- Page Design libraries
- Effect libraries
- MVC Framework design libraries
I think I am going to start a series of weekly jQuery plugin examples (in XPages) to show what can be achieved very easily with the minimum of code. Let’s see how far it takes me before I run out of the over 4000 jQuery plugins and jQuery mobile
Xomino 
Please do. I’d like to see jQuery plugin samples. Wrap them up in XPages controls and submit to contest 🙂
Niklas – it is almost like you read my mind 🙂 There are many plugins which “look pretty” but don’t really fit what I would call a “business need”. But there is certainly one in particular which I had my mind set on as a submission. Wrapping all the rest of them into the same database wouldn’t hurt I guess 🙂
Hi,
thanks for the article. I also would really like to see what is possible with jQuery in XPages, because sometimes Dojo drives me into madness =)
http://www.mnicklisch.wordpress.com
We’ve had a really tough time with dojo.
We have an application that has been live for about a year and a bit now, running on Dom 8.5.1 fp5, we use dojo extensively (Panes, grids, sliders, DateText, Dialog, Tooltip, Trees, Menus, Toolbars, etc.), and the app is a mix of XPages and “traditional” Notes design elements. It’s an app that users log into and uses for 8 hr shifts. Dojo has been a real pain for us, primarily performance and memory leaks. We went from using dojo 1.3, up to 1.7, we have 1.6.1 in our production environment. Most users are using some flavour of IE, but we don’t really have control over what browser they use.
We had a number of issues, but dojo grids have caused us the most problems, re-sizing, rendering, quirks with scroll-bar, which seems to get exponentially worse as you increase the grid rows (we have been down various design paths, should we use paging, cap the number of rows, lazy loading, etc…I could write another 10 pages on it). We destroy all dojo objects when we don’t need them anymore, but we can not get rid of memory leaks in IE. We experimented with using a custom dojo build, but regardless, as soon as you start adding grids, sliders, panels, etc., the number and sum size of all the dojo files really starts mounting up…or if you have custom build, the single file is still a big file. We tried compression, but that introduced other issues. The grids being our biggest killer, we reverted to hand rolling our own html + css “grid”, we gave it some click, double click, right click, mouse over effects, column sorting, etc., the difference in performance is absolutely huge…it has transformed our app. The difference in rendering time is massively improved, and you barely even see the IE CPU rise, but when using the dojo grids, it would crush the IE task.
So whilst dojo makes it easy-“ish” to put together an app, and you are OK with the corporate looking styling (I realise you can override it), depending on how your application works, you may run into some performance issues. We are slowly stripping the dojo out, we are finding the overhead of dojo framework is too much for us. If we were to do again, a switch to a smaller js framework would be beneficial, or where it makes sense, “re-invent” the wheel slightly, and for example…roll your own js\ html\ css dialog box.
Nick – that’s very interesting (I understand the frustration mate!) – thanks for sharing. There are jQuery grid plugins but I wasn’t going to bother with them because I had assumed that everyone would use the dojo grid controls…now you’ve made me reconsider.
What is also important to understand (from a general audience perspective) is that browser layout quirks are not a dojo or jQuery issue but a CSS styling implementation using the framework/library. What I do not know (and my biggest correct concern going forward with this project) is that the jQueryUI and other packaged CSS styling will conflict with OneUI. I guess we will find out and deal with it when we get there 🙂
Will be interesting to see what, if any, issues you might find with CSS conflicts. Seems to me that both are css class based and therefore easy enough to override in any circumstance that may arise.
I’ve seen that kind of thing here too. Our custom build is around 700k and that is using the Dojo shrinksafe param when building. And that’s without chart stuff which we put into a separate build (around 300k). Big downloads, but I will say that a 700k file download is MUCH faster than doing dojo.require on a handful of widgets, which in turn call their own dependencies and you end up with 20-30 server calls.
Size aside, we’ve have good success with the Dojo grids, even in IE 7 which is still the prevalent browser used by the government. I don’t think we deal with tens of thousand documents, but on the scale of a few thousand, not too bad for our use.
Good Job Mark.
JQuery rocks
Hey, Doc! 🙂
The past several months, I’ve been working on many Notes client applications, but now we’re ready for a big web based application! So, back to jQuery (YAY!) and some dojo (boo!).
Outside of the XPages world, it seems that jQuery is overtaking everyone else. In fact, I heard that the next version of javascript is taking elements of jQuery! I remember there were Mootools, Scriptaculous, Prototype and TONS of others over the years! Just check the stats of how many Stackoverflow questions there have been for various js librairies: http://stackoverflow.com/tags. It’s not even close!
So, for the sake of argument, what if dojo shuts down within 3-5 years, and only Xpages are using them. Then what?
From the outside world, it just seems that jQuery is the better long term decision. Any thoughts?
Take care & thanks!
Steve