Printable View
I know the answer is different depending on the project but I'm trying to find out the differences between these two JavaScript frameworks.
I've only just started to look at them but from what I can see jQuery is easier to learn but I like the way the DoJo loader works. jQuery can do the same as DoJo but looks like it relies on modules built by others to manage this.
So basically I'm looking for what the strengths and weaknesses of each are.
Thanks,
What concerns you about that? Quality plugins are widely available, and you'll probably get more choices than whatever's packed by default with Dojo.Quote:
jQuery can do the same as DoJo but looks like it relies on modules built by others to manage this.
Personally I like jQuery's syntax, and have not encountered any notable drawbacks or missing functionality. Dojo's syntax looks verbose and unintuitive to me, but I've never really used it so can't speak to its value.
The jQuery library and the plug ins and such available for it are incredible - our entire development work for the past 18 months has been jQuery.
I've not done DoJo - but what do you mean by the LOADER IS BETTER??
The issue is that the documentation is from different sources and varries in quality, how much of an issue this is I'm not sure. I agree with you on the syntax of jQuery though.Quote:
Originally Posted by SambaNeko
I wasn't saying its better I'm just saying I like it how you don't have to load the whole library, just the modules you need and its not important about the order you declare them.Quote:
Originally Posted by szlamany
Does jQuery use a loader too? I thought it was lightweight to start with, or is that for loading the plugins?
Obviously a biased view but this is what Dojo has to say about jQuery, couldn't find an equivelent from jQuery about Dojo.
Quote:
Originally Posted by http://dojotoolkit.org/reference-guide/1.7/quickstart/introduction/whydojo.html
That's actually a pretty good review of jQuery from the dojo site - don't you think??
These are all the jQuery associated files I'm using at this point - the jquery-1.7.1.js file is the main api. That's not even MIN'd
Then the jQuery-ui-1.8.1.custom.min.js is the standard UI stuff - like accordions, tabs, really great modal-like dialog boxes.
I use the really great SlickGrid tool for data manipulation in the web app.
Check the firebug NET window - look at how fast at that loads...
Code:<head runat="server">
<title></title>
<link href="themes/custom-theme/jquery-ui-1.8.11.custom.css" rel="stylesheet" type="text/css" />
<link href="css/slick.grid.css" rel="stylesheet" type="text/css" />
<link href="css/examples.css" rel="stylesheet" type="text/css" />
<link href="css/slick-default-theme.css" rel="stylesheet" type="text/css" />
<link href="css/jquery.ui.timepicker.css" rel="stylesheet" type="text/css" />
<link href="css/jALDropDown1.7.3.css" rel="stylesheet" type="text/css" />
<link href="css/AWCOffice.css" rel="stylesheet" type="text/css" />
<link href="css/Final.css" rel="stylesheet" type="text/css" />
<script src="Scripts/jquery-1.7.1.js" type="text/javascript"></script>
<script src="Scripts/jquery-ui-1.8.11.custom.min.js" type="text/javascript"></script>
<script src="Scripts/jquery.json-2.2.min.js" type="text/javascript"></script>
<script src="Scripts/jqia2.support.js" type="text/javascript"></script>
<script src="Scripts/jquery.event.drag-2.0.min.js" type="text/javascript"></script>
<script src="Scripts/jquery.event.drop-2.0.min.js" type="text/javascript"></script>
<script src="Scripts/slick.core.js" type="text/javascript"></script>
<script src="Scripts/slick.editors.js" type="text/javascript"></script>
<script src="plugins/slick.rowselectionmodel.js" type="text/javascript"></script>
<script src="Scripts/slick.grid.js" type="text/javascript"></script>
<script src="Scripts/slick.dataview.js" type="text/javascript"></script>
<script src="Scripts/jquery.ui.timepicker.js" type="text/javascript"></script>
<script src="Scripts/jALDropDown1.7.3.js" type="text/javascript"></script>
<script src="controls/slick.pager.js" type="text/javascript"></script>
<script src="controls/slick.columnpicker.js" type="text/javascript"></script>
<script src="Scripts/MicrosoftAjax.js" language="javascript" type="text/javascript"></script>
<script src="Scripts/MSAjaxDownload.js" language="javascript" type="text/javascript"></script>
<script src="Scripts/jquery.blockUI.js" language="javascript" type="text/javascript"></script>
<script src="Scripts/jquery.cookie.js" language="javascript" type="text/javascript"></script>
<link rel="stylesheet" href="css/jquery.jDownload.css" />
<script type="text/javascript" src="Scripts/jquery.jDownload.min.js"></script>
<script type="text/javascript">
In my experience, this is a non-issue. Worthwhile plugins tend to have good documentation and examples. The jQuery community is also large and active - if you're having trouble with a plugin, you can likely find other users to discuss with.Quote:
The issue is that the documentation is from different sources and varries in quality, how much of an issue this is I'm not sure.
I think szlamany's example there is using more JS files than I've ever put on a single page, but it demonstrates jQuery's plugin loading model: you just add script includes for each plugin you want.
Looking at the file sizes I've run a few tests and they more or less come out the same. The problem is that for Dojo the "UI" part doesn't come as a bulk module. Depending on what type of UI controls you use on the page it loads the relevant js file, these range from <1KB to 9KB. So for the example below I made a busy Dojo demo page that used a variety of different UI controls:
Minified jQuery: 92KB
Minified jQuery UI: 203KB
Total: 295KB
Minified Dojo: 135KB
Extra JS files: 202KB (or 114KB)
Total: 337KB (or 249KB)
The figure in brackets is when I removed some of the controls I'd rarely use if at all. Its interesting to see they are close in size, but because that can change either way it takes that out of the decision.
Yea I see your point with the different sources but have you ever had any compatibility issues between different versions of jQuery and its plugins? I suspect if at all its a rarity.
Once you select a version it's a constant - it doesn't change. Won't the client simply cache it? I've seen professional suggestions to pull from the google api site anyway - it's truly a constant at that location.
The drop down that you seen "named" in the image is not a good dropdown - I've encountered issues with it and wish it was no minified so I could at least patch it up a bit.
The SlickGrid goes over the top embracing the CSS and the coloring and what not - really seems like a natural UI.
Have you seen this site where you choose your colors - the jquery themeroller. I have a customized pull from this site that I use.
http://jqueryui.com/themeroller/
Go to the GALLERY - select a theme - then go back to the Roll your Own to customize it.
For example - select the START template - and see how the buttons and hover over re-coloring works.
Does DoJo do that out of the box?
Does it do the DIALOG BOX - click that little baby...
The application this is for will be over SSL so I was thinking js files served over https weren't cached but been looking into that and if you send the right cache control headers it will be (and the google CDN does). Strangley enough the Docs for the google CDN only lists the https addresses yet you find a lot of people give examples with http. (https://developers.google.com/speed/libraries/devguide)
Yea I'd briefly looked at the Theme Roller and its definitely a strong case for jQuery as I need to skin the application for many different customers. Currently this is done by the customer having a CSS file that overrides the default.
Dojo does offer something similar, it comes with 4 default themes (Seen Here) but you can create your own too. I dont know of anything as easy as Theme Roller for it though.
Yea it has dialog boxes, modal and not, see the link for the themes (top of the menu). Are the drop down lists not included in jQueryUI? Or was there another reason you used a different plugin for that?
The reason I mentioned the versions was that this applciation keeps moving on so if I used jQuery 1.7.2 then later on want to take advantage of features from a newer version I dont want to find plugins stop working and rewritting the dependancy on those plugins.
Thanks to you both for the info its really appreciated.
jQuery has an AUTO-COMPLETE that they have as the solution to drop down - and I definitely use it - extensively.
But sometimes a simple 3 or 4 or even 20 option drop down is nicer. I could probably write it myself - they certainly don't seem to be complicated - it's all about having it look like a jQuery widget and use that same theme settings and such.
I recently moved to the next version of jQuery because I was finding problems that the newer version fixed. I do not recall anything breaking because of poor backward compatibility - after the move all seemed ok.
I am deathly afraid to move to the next version of SlickGrid - that version just came out. I was taking a big gamble using a grid that I did not code myself - but after a while my JS skills became good enough for me to both debug and hack the grid code itself.
I don't know much about DoJo but the selector logic in jQuery is really cool - look at some of this code.
That is one hell of a lot of DOM manipulation happening with very obvious method names and DOM target identifiers.Code:function makeReader(strId, blnDisplay, objReturn) {
var wesRP = $("#" + strId);
if (wesRP.find(".acs-panel-btn-close").length == 0) {
$("#acs-button-list .acs-panel-btn-close").clone().prependTo("#" + strId).removeAttr("id").attr("title", "Close Reader Panel");
$("#acs-button-list .acs-panel-btn-prev").clone().appendTo("#" + strId).removeAttr("id").removeClass("acs-panel-btn-prev")
.addClass("acs-reader-prev-next-hidden").addClass("acs-panel-btn-reader-prev");
$("#acs-button-list .acs-panel-btn-next").clone().appendTo("#" + strId).removeAttr("id").removeClass("acs-panel-btn-next")
.addClass("acs-reader-prev-next-hidden").addClass("acs-panel-btn-reader-next");
wesRP.append('<span class="acs-reader-cache"></span><span class="acs-reader-totalcols"></span>');
if (!blnDisplay) {
$("#acs-button-list .acs-panel-btn-refresh").clone().appendTo("#" + strId).removeAttr("id");
}
$("#acs-button-list .acs-panel-btn-print").clone().appendTo("#" + strId).removeAttr("id");
wesRP.append('<span class="acs-reader-aggregators"></span>'
+ '<div class="acs-reader-grid"></div>');
This code takes a RETURN status for whether a report has completed from an AJAX call - based on what comes back it messes with HTML content - find all the buttons with .ACS-DOWNLOAD as a CLASS and adds DATA to those DOM objects - and removes and sets various flags in the DOM.
If DoJo looks and acts just like this then your have to dig deeper for differences that might be meaningful to you.Code:} else if (objReturn.reportstatus) {
if (objReturn.message == "S") {
var t = setTimeout("ctrlWebService('reportstatus', '" + objReturn.rptid + "','','" + strWho + "')", 1500);
} else {
switch (objReturn.message) {
case "C":
$("#" + strWho).find(".acs-report-status")
.html("Report Status: Completed")
.parent()
.find(".acs-download")
.data("rptid", objReturn.rptid)
.closest('.acs-ddreflector')
.removeClass("acs-report-running")
.addClass("acs-report-complete");
break;
case "E":
$("#" + strWho).find(".acs-report-status")
.html("Report Status: Selection Errors")
.closest('.acs-ddreflector')
.removeClass("acs-report-running");
break;
case "Q":
$("#" + strWho).find(".acs-report-status")
.html("Report Status: Query produced no results!")
.closest('.acs-ddreflector')
.removeClass("acs-report-running");
break;
}
}
fwiw, I'm the guy who wrote the dojo loader. Since that machinery came up on this thread, I'll try to give some feedback.
The short answer: if you're just doing simple DOM manipulations, it doesn't really matter. However, once you start doing more--and any well-designed/significant app will need to do much more--then you won't be using JQuery compared to Dojo, but rather, you'll be using (JQuery + plugins written by whoever) compared to Dojo.
Of course many plugins in the JQuery universe are well-done. But that doesn't change the fact that they come from different sources, written by different people, with different design ideas, released on different release schedules, with different IP protections/guarantees.
In contrast, Dojo includes an expansive set of machinery--widgets, mobile, charting, vector graphics, a spectacular new grid--and on and on. All of this functionality is constructed by the same team in a coordinated manner and all subject to very strict IP protections/guarantees.
While it is possible to be successful with either technology, you'll need to go beyond JQuery quite quickly (to plugins) whereas you'll be able to stay within Dojo indefinitely.
As for the Dojo loader. It is an AMD-compliant loader (https://github.com/amdjs/amdjs-api/wiki/AMD). Dojo is implemented in terms of AMD modules and includes a powerful builder application to optimize modules for deployment. A book can (and is being) written all all of this, but the bottom line is that this system controls complexity, improves interoperability, and is fairly future proof when/if native JavaScript modules come.
Here is another post by my colleague Eugene Lazutkin about comparing libraries.
http://stackoverflow.com/questions/3.../394668#394668
Good Luck!
I like how - if you just scroll up - there's a more highly-voted (and "accepted") post above that one in jQuery's favor. Not that popularity is everything (though it's not negligible either).Quote:
Originally Posted by rcgill
It's neat to hear from a framework developer, in any case. Thanks, rcgill.
Thanks for the comments, I think its pretty safe to say we'll be taking the Dojo route. Thats not to say its the answer for everyone but for our requirements and future plans the boxes get bigger ticks. :)
Would you mind sharing some of the bigger reasons you selected dojo?