nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Esri support for Dojo over jQuery...

EricDaniel

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?

Encontre mais publicações marcadas com

Accepted answers

All comments

JeffJacobson

If you don't like Dojo (which I understand), Esri also has some plugins for Leaflet: Esri Leaflet

shay-geo

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/_ags_225bd9c041ac4ca5b7…

Thanks and Regards,

Shay~

StevenGriffith

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.

DeminHu

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.

KeG

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.

ReneRubalcava

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.

JeffJacobson

If you're after the jQuery style of selector syntax, check out dojox.jq.

dojox.jq has been "abandoned".

MattDriscoll

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.

JeffJacobson

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.

EricDaniel

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.

Anonymous User

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

JeffPace1

I promise this is my last post on this topic since I completely agree that our time is better spent making cool stuff rather than these holy wars. Yes, popularity should not determine what framework to use, but what is it about jQuery that makes it so popular? Is it for technical reasons, probably so. Is dojo better for GIS, maybe, sounds like it is for Esri but not for the opensource GIS community it seems. I think you nailed it when you said those opensource frameworks don't use a framework. And that is my main point with all of this and that's why I think you see the negative comments with Esri leveraging dojo heavily.

That would be great if someone could write up something on comparing dojo to jQuery rather than the bashing with no legitimate argument. I definitely don't have enough background in either to do that. Maybe Jeff could put something like that in a blog post or something?

Sorry, I am not the right person for that. I see value in both, and could care less about the differences. Both good tools, both useful. Both have shortcomings, both have value. I much prefer to learn a tool and get the job done than to complain that I can't use a different tool.

derekswingley1

...what is it about jQuery that makes it so popular?

There are a ton of ways to answer this but I think the killer feature was/is the DOM API. The native DOM API provided by browsers is a PITA. jQuery masks this from you by providing simpler and easier ways to grab some elements and do something with them. This is why I mentioned dojox.jq in my first reply in this thread.

Is dojo better for GIS, maybe, sounds like it is for Esri but not for the opensource GIS community it seems.

It's not that dojo is better for GIS, per se. It's that dojo provides a more extensive set of tools that we want to be available to use ourselves and make available to developers using our API. Internally, we use dojo's build system. For devs, we like the idea of having a class/module system baked into the API as well as a robust widget lifecycle system. We also use dojo because it normalizes browser inconsistencies but so does jQuery so this isn't really a point that sets dojo apart (but one worth mentioning since we're now talking about some of the pros/cons of using any framework).

I think you nailed it when you said those opensource frameworks don't use a framework. And that is my main point with all of this and that's why I think you see the negative comments with Esri leveraging dojo heavily.

As I said before, we use dojo to avoid replicating work already done by others in the web development community. We don't want to spend our time fighting browser inconsistencies or shimming our new features into legacy browsers. The dojo team has committed to doing that work and we are thankful.

EricDaniel

I promise this is my last post on this topic since I completely agree that our time is better spent making cool stuff rather than these holy wars. Yes, popularity should not determine what framework to use, but what is it about jQuery that makes it so popular? Is it for technical reasons, probably so. Is dojo better for GIS, maybe, sounds like it is for Esri but not for the opensource GIS community it seems. I think you nailed it when you said those opensource frameworks don't use a framework. And that is my main point with all of this and that's why I think you see the negative comments with Esri leveraging dojo heavily.

That would be great if someone could write up something on comparing dojo to jQuery rather than the bashing with no legitimate argument. I definitely don't have enough background in either to do that. Maybe Jeff could put something like that in a blog post or something?

derekswingley1

Hey Eric,

I'm happy to have this discussion and provide as much info as I can about why we use dojo. I've tried to imply this, but I think I need to be more clear: popularity should not be the primary reason for picking a tool/framework/technology.

jQuery is not the right tool to build our mapping API. It provides a great DOM API, event management tools and AJAX tools. That's it. It's missing a number of things which we would prefer to not re-invent.

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. There's plenty of vague dojo bashing, but that doesn't go very far as to making a case for switching from one framework to another. "Dojo sucks, jQuery doesn't" and "everybody else is using it" are not persuasive arguments. And the latter isn't true in the online mapping space.

Regarding other open source mapping options, the only one I know of that uses jQuery is jQuery Geo (which is still in alpha, at the time of this post). The rest, Leaflet, Polymaps, OpenLayers and others I'm probably forgetting, don't use a framework. So if you want jQuery with those, it's up to you to include it.

At the end of the day, it's all JavaScript. I think our time is better spent getting to know the language, our tools and how to make cool stuff rather than holy wars over which framework is best. I'm hoping you'll give our API (and dojo) a fair shake rather than dismissing it solely because it's not built on jQuery.

JeffPace1

Hi Derek,

Thanks again for the info and your candor on this, it is much appreciated. I definitely understand the reasoning but I think many in the community don't or just don't agree. I imagine you get this kind of negative feedback on using dojo alot. As seen in that blog post comments I listed above alone, about everyone is negative towards dojo. The open source community seems to embrace jQuery over dojo as well.

I get that you are hesitant to lean on the jQuery plug-in community but many of these efforts are probably bigger than dojo community all together. So that is being traded for relying on the dojo framework. The same argument against relying on jQuery plugins could be used against relying on a framework at all such as dojo or even jQuery. As I said before, I just see this as problem today and is only going to get bigger as time goes on due the popularity of jQuery.

If popularity were the determining factor we would be using Flex (sorry, tongue in check). Even where I work jQuery is more popular. And amongst developers so is IIS vs Tomcat, .net vs javascript, etc..

Dojo is an appropriate tool for the task, and it is just a tool. It works, and is worth learning.

To me the important message is they are not mutually exclusive. We use dojo and jQuery side by side in our app.

var tabs = jQuery(dojo.hitch(this,function() {
                            jQuery( "#infoPopupTabs" ).tabs({
                                selected: 1,
                                select:dojo.hitch(this, function(e, ui){
                                    this.readDetailSizePreference();
                                })
                            });
                        }));

For example of a tabbed infoPopup container.

Not being argumentative, just pointing out a preference for jQuery does not have to be preference against Dojo.

EricDaniel

Hi Derek,

Thanks again for the info and your candor on this, it is much appreciated. I definitely understand the reasoning but I think many in the community don't or just don't agree. I imagine you get this kind of negative feedback on using dojo alot. As seen in that blog post comments I listed above alone, about everyone is negative towards dojo. The open source community seems to embrace jQuery over dojo as well.

I get that you are hesitant to lean on the jQuery plug-in community but many of these efforts are probably bigger than dojo community all together. So that is being traded for relying on the dojo framework. The same argument against relying on jQuery plugins could be used against relying on a framework at all such as dojo or even jQuery. As I said before, I just see this as problem today and is only going to get bigger as time goes on due the popularity of jQuery.

derekswingley1

Hi Eric,

As I said before, no argument that jQuery is more popular. Dojo was not chosen because of the size of its user base/community; it was chosen based on the features and tools it provides.

Regarding canvas, we still support IE7/8. In those browsers, there is no native support for canvas. It's all VML, which dojox.gfx nicely abstracts away for us. There's also the android browser...I'm not sure about its capabilities with Ice Cream Sandwich, but at 2.x and 3.x it's canvas only (no SVG).

jQuery has a huge plug-in community and it's impressive what's available. But I'm not ready to advocate leaning on that community to support a product that we build.

A while back, Rebecca Murphey (prominent web development blogger, nothing to do with GIS) wrote about some of the things jQuery is missing. There's some great info in those posts:
http://blog.rebeccamurphey.com/on-jquery-large-applications
http://blog.rebeccamurphey.com/on-rolling-your-own

At the end of the day, we're not telling you that you can't use jQuery. We are saying that for the immediate future, we've made our choice, and we're not moving to another library that does a subset of what dojo does. I linked to examples in my previous post in this thread that shows using jQuery alongside dojo. If you must use jQuery, that's what we're recommending.

EricDaniel

Thanks for reply and great insight Derek. I just expressed this on the Ideas site but I wanted to do that as well here in case you won't see that. My concern here is as we all know jQuery is very popular , and very likely to become increasingly popular and likely increasing the gap between expericiend jQuery developers vs. experience with dojo. I see the same thing happening with JS API as HTML5/JS/CSS will begin to pull more people away from the browser plug-ins within the Esri ecosystem and beyond. So regardless of technical reasons, I think you will see continue press to support jQuery in favor of lesser known dojo framework. As a possibly gauge in how much more popular jQuery is, if you go to the popular Stackoverflow forum you will see dojo has been tagged in 2310 posts (595 followers) vs. 135,995 posts (20,100 followers) for jQuery, nearly 60 to 1.

As for technical reasons, does the HTML 5 Canvas not reduce a little bit of the need for the dojox.gfx? Also, I imagine there are many jQuery plugins that would help here like jQuery SVG which some might argue work much better than the dojo implementation. And what if jQuery adds vector graphics support in it's core library and most believe it works much better than the dojo version? Just seems like a matter of time if we all agree jQuery is much more popular that is going to greatly surpass dojo.

I may be completely wrong, but I just see a huge surge likely coming to GIS with jQuery experience over the next year and with many open source options going that direction in the GIS arena I see this becoming a problem for Esri JS API long-term.

Also, although an older post now, if you read through the comments section you will see the large number of well known in the GIS space that would like to see more effort put into jQuery over dojo. http://spatiallyadjusted.com/2010/09/20/arcgis-api-for-javascript-2-1-now-with-legends/

derekswingley1

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.

The API was initially designed to be built using dojo and we do not plan to change that. One of the biggest things that dojo has over jQuery is support for vector graphics via dojox.gfx.

...it's become clear in the last 1-2 years that jQuery is the premier JavaScript framework.

jQuery is the most popular JavaScript framework, no argument there.

In fact, this looks to be Esri's focus in the JS mobile space with jQuery mobile.

jQuery mobile was usable before dojox.mobile so we used it (and continue to use it) for some samples. But they're just that- samples. We have additional samples showing how to use libraries other than those included in the JS API if that's what you want to/must do. But we encourage you to give dojo a fair shake. It is just as capable as jQuery. If you're after the jQuery style of selector syntax, check out dojox.jq.

Is Esri going to begin to show more support for jQuery where we can completely utilize only that framework?

No, not in the near future. The ArcGIS API for JavaScript will continue to be based on dojo for the foreseeable future. We will continue to provide a compact build that is smaller than the full API. We're looking into making a more modular build system publicly available that will let you build an even lighter version of the API for your app that is tailored to your specific needs.

This same thing also recently came up on the ideas site and I posted a reply earlier this week: http://ideas.arcgis.com/ideaView?id=08730000000bsrjAAA

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.