Esri support for Dojo over jQuery...

7743
20
12-15-2011 09:22 AM
EricDaniel
Occasional Contributor III
It seems clear that since the Esri JS API was released that Esri has showed a strong favoritism towards Dojo for some reason and I'm sure they have had their reason for this.  However, I think it's become clear in the last 1-2 years that jQuery is the premier JavaScript framework.  In fact, this looks to be Esri's focus in the JS mobile space with jQuery mobile.  It would certainly be nice if we could use the same framework for both desktop web and mobile without feeling like we lose a bunch of extra support and widgets that Esri provides when using the Dojo framework.  Secondly, we would not have to include both libraries. 

So my question:  Is Esri going to begin to show more support for jQuery where we can completely utilize only that framework?  Do others agree with this direction?
20 Replies
by Anonymous User
Not applicable
I'd like to weigh in here, as I hope my experience with these and other libraries might be useful to the discussion.  You'll have to form your own opinion as to whether or not that's true :).

Although I am an Esri employee, my position in Tech Marketing makes me more of an end-user of the software than most folks at the mothership.  I have been heavily involved in building the Public Information Map Template that we've had available in the ArcGIS.com code gallery for a while now.  This started off as an esri.com application for illustrating how telling stories around events with maps can be useful in gaining a greater understanding of the event.  It's been used a lot on esri.com since then, especially on our disaster response pages

When we initially built this application, we were under very tight deadlines, and had to get the app running live and looking good.  We didn't have time to pick and choose our architecture, so we went with what we knew:  I was the GIS guy building the mapping functionality, so I went with dojo.  The front-end web developer I was working with is JQuery 'til he dies, so the front end stuff is all written in JQuery. 

When we first did this, I was more than a little horrified.  "At what cost!?!?" I cried as we forced our users to download not one, but two large javascript libraries. 

You know what?  The impact has been minimal. I expected folks to give us all sorts of negative feedback about downloading all that client code on page load.  We haven't heard a peep, and I feel that the performance of the template is actually very respectable for all that it does.  Any performance problems I've had to overcome in refining this template are related to all the data the application has to go out and get on page load, certainly not downloading both the dojo and JQuery libraries.  In addition, it runs really well on any platform.  When the iPad first came out, I got a kick out of seeing a very early version of this browser-focused app load and run really well in iOS Safari.  In addition, we met our deadline in large part because JQuery and dojo took care of any potential browser support marathons.

My experience from this has been to open my mind to the arsenal of great javascript libraries out there, especially the ones that really rock in one specific area.  In that spirit, I recently built a simple tablet-focused prototype with Sencha Touch just to see how it worked.  It worked great, and the compact Javascript API performed as expected.  I've since started seeking out other libraries to include in my projects.  Some are no-brainers, like Modernizr.js.  Others might help with loading efficiency of large applications (RequireJS, JSLoad, etc., etc.).  To pervert a phrase used with great effect by Apple - "There's a library for that."  No matter what you're doing, someone has probably built a javascript library that either plugs right in or comes really close to getting what you're after. 

My attitude now reflects what Rebecca Murphey and Derek Swingley have both said - it's just javascript.  My choice of what to include in my app is up to me.  I can take a best of breed approach, and my experience is that folks won't march on my home with picks and shovels if I include a few different javascript libraries (Your experience may vary). I can start with dojo, and if I need to move to something like Ext - or if I'm just more comfortable with it - I can just load the compact version of the API and run with it.

It's worth saying: For pure GIS development work in javascript, nothing beats dojo in my opinion.  Dojo.declare() alone is enough to separate it from the other major libraries.  It offers flexibility and code re-use options that can really make javascript feel like much more than a scripting language.  However, for front end development work, Dojo might require a bunch of CSS and image work.  If I'm too lazy for that, I can roll in JQuery, or YUI, or Ext. 

This is just my experience.  I'm not a javascript expert and don't claim to be.  I just have to be knowledgable about what my options are and pick and choose them to match the functionality I need in my apps and the time I have to build them.

Hope this is helpful.

Jeff
EricDaniel
Occasional Contributor III
Thanks everyone for the comments.  Excellent points!... In summary, embrace the JavaScript library that make sense for your situation.  The tough part for beginners will be direction on when to use a given library over another.
0 Kudos
JeffJacobson
Occasional Contributor III
One thing I'd like to see is a write up of things that dojo does poorly and could be improved by switching to jQuery.


I'm not advocating that Esri switch to jQuery, but here are some reasons I prefer to use jQuery over Dojo.

  • jQuery has better documentation than Dojo. Not just jQuery and Dojo's own websites, but it's easier to find outside tutorials for accomplishing a task with jQuery than with Dojo using a search engine.

  • Most things are more complicated in Dojo than jQuery.  For example, try going through the both the jQuery Mobile and Dojo Mobile tutorials. I found that it is much easier for me to create my own widgets in jQuery (using the jQuery UI Widget Factory) than it is to create "dijits".

  • The Dojo UI controls are weird.  When you create a Dojo UI Button, it changes the HTML button element into a span element. When you create a jQuery UI Button, it remains an HTML button.

When I create controls for developers who have no GIS experience, I currently create them using jQuery UI Widget Factory using a minimal amount of Dojo as required for the ArcGIS JS API.
0 Kudos
MattDriscoll
Esri Contributor
I'm not advocating that Esri switch to jQuery, but here are some reasons I prefer to use jQuery over Dojo.

  • jQuery has better documentation than Dojo. Not just jQuery and Dojo's own websites, but it's easier to find outside tutorials for accomplishing a task with jQuery than with Dojo using a search engine.

  • Most things are more complicated in Dojo than jQuery.  For example, try going through the both the jQuery Mobile and Dojo Mobile tutorials. I found that it is much easier for me to create my own widgets in jQuery (using the jQuery UI Widget Factory) than it is to create "dijits".

  • The Dojo UI controls are weird.  When you create a Dojo UI Button, it changes the HTML button element into a span element. When you create a jQuery UI Button, it remains an HTML button.

When I create controls for developers who have no GIS experience, I currently create them using jQuery UI Widget Factory using a minimal amount of Dojo as required for the ArcGIS JS API.


These are good points and probably my biggest gripes with Dojo as well. I do like the new AMD way of writing code though. Dojo.query makes it almost as easy as jQuery.

I would add theming/styling to the list as well. The dojo dijits have odd UI/UX and use many unnecessary and invalid HTML elements and sometimes use tables for layout. If you want to use a theme for all but one widget, it's difficult.

The documentation is a big issue. The documentation is often missing things or not detailed enough. It's also hard to switch between the documentation and reference guide when looking at a function.
0 Kudos
JeffJacobson
Occasional Contributor III
If you're after the jQuery style of selector syntax, check out dojox.jq.


dojox.jq has been "abandoned".
0 Kudos
ReneRubalcava
Frequent Contributor
dojo/query does most DOM selection that jQuery does.
Just to chime in, I really think a lot of people give Dojo a bad rap. Since 1.7 the docs for Dojo have vastly improved with lots of credit to the Sitepen guys. The reference docs are not the easiest to navigate, but the other documentation works great. You find more jQuery info online in general because of the popularity. The implementation of dgrid for dojo is a big improvement over dojo DataGrid.

My biggest gripe with Dojo is the way dijits are an overabundance of divs/spans. Styling can take more work than I'd like sometimes, but overall I have been very happy with the Dojo tools I have at hand for the work I do. I've pretty much removed jQuery from my Esri projects without missing anything.
0 Kudos
KeG
by
New Contributor II
does dojo have something like ThemeRoller? that really makes jQueryUI element styling very easy.
someone also noted here that they like the new dojo AMD business.
i have an issue with that as it is a major change to the dojo library that caused me headache when upgrading to the latest esri js api.
Why should my code have to change because the dojo people found a new way to do something and esri adopted it?

additionally, the dojo documentation is a disaster when you look at it as an outside who has worked extensively with jQuery and their docs.

the esri js api is not like the other client apis in that there is no "JS Map Viewer" - a comprehensive, foundational, proof-of-concept codebase that comes from esri as a guide and starting point to produce a full featured mapping application. What we have are hundreds of samples that all perform one task only.

I can't think of a better example of this than the table of contents slash legend. There are esri samples for adding a layer list, toc, legend whatever you want to call it. But there is no sample that lists the names of the map layers, the legend swatch AND a checkbox to turn the layer on and off. To achieve something like that you need to roll your own. which means you need your app to have a centralized 'brain' to monitor all of the layers and legend swatches.

Where i'm going with all this is that i think jQuery is a better choice for building that 'brain'.
Don't get me wrong, the esri samples are great, i am thankful for them and use them daily.
But its somewhat akin to learning how to speak a foreign language using a dictionary.
0 Kudos
DeminHu
New Contributor
I just started to learn ArcGIS Server Javascript API last week.

I was frustred with dojo as a beginner, now  I am  learning and using JQuery to do most my tasks, I am only use dojo for  some ESRI tools.

I agree with VBAHole.
0 Kudos
StevenGriffith
New Contributor III
FWIW, there's no reason to not use JQuery. I've just published an extensive application (http://www.sloplanning.org/PermitViewMap) that is primarily JQuery, but I use dojo where necessary to integrate with the Esri APIs. Works like a charm. The point is, arguing about dojo versus JQuery is just a waste of time: use what you know and can find support for. 😉

Steve G.
0 Kudos
shaileshgavathe
Occasional Contributor II

Hello Steve G,

I just saw in your sample PermitView.

It's so smooth and good app with jquery that i saw in a while. I was looking for such examples.

One thing i noticed that in your print map, there were buffer circles in the final map. I was wondering, how were you able to get buffer graphics exported to map? Did you use buffer_analysis inside of your python script or did you export graphics from javascript and sent it to export_map?

http://www.sloplanning.org/arcgis/rest/directories/arcgisoutput/Utilities/PrintingTools_GPServer/_ag...

Thanks and Regards,

Shay~

0 Kudos