Is jQuery The Best Option For Large-Scale App Development?


This post is directed at jQuery users interested in building large applications. Quite often, when you discuss the options that are available for developing large-scale JavaScript applications, you may wonder whether toolkits such as dojo may be more appropriate to use than jQuery. There are of course others, however this post will be focusing on dojo specifically given it’s level of comprehensiveness. I’ll try to address this at as high a level as possible to avoid too detailed a feature comparison.

It’s important that you don’t fall into the trap of thinking that just because jQuery is what you know best, it’s what you should always use because that would be untrue. The reality is that ‘what you use’ completely depends upon the type of problems your project is attempting to solve as well as your current level of skill.

jQuery is your best option if your project primarily requires a level of DOM manipulation, easier access to Ajax (both dojo and jQuery support deferrers), animation effects, hooks or events. It’s also highly popular, so if your company’s dev team are attempting to hire, you *may* find that there are more developers with jQuery knowledge available than those specialising in dojo. This is a moot point however given that dojo developers (generally) tend to be more experienced with the many non-trivial challenges involved in truly large-scale application development and (in my opinion) would be able to quicker pick up jQuery if needed than a jQuery dev may pick up dojo.

It’s worth noting however that jQuery is a library whilst dojo is more of an intensive, enterprise-level toolkit so there’s certainly more there to learn. dojo offers better solutions for OOP (and other patterns for code organisation), custom modules, internationalization, templated widgets, grids, charting, the ability to be used in non-browser environments and integration with other frameworks like Zend but it also better suited when you’re developing web applications that are significantly complex.

I would argue that jQuery has a slightly better level of documentation available and so, unless you’ve been heavily using JS for some time, you may experience a slightly higher learning curve when checking out dojo for the first time. This may be one area where you might find professional training useful, however there are plenty of dojo devs out there that picked up how to use it on their own.

I think that if you have an appreciation for the need to structure client-side JavaScript code correctly, have decent build and dependancy management tools in place, you could easily use either of the options above, but it’s important to always keep in mind that there *is* a point where it stops making sense to roll your own large-scale development kit using jQuery and just opt for dojo instead.

I’m not advocating that if you currently use jQuery you should drop it and go straight into using dojo, but rather that you keep yourself open to performing due-diligence before beginning a large project using either.

As some of my colleagues in the JavaScript community have pointed out before, this can save you both time and a significant amount of financial investment so just be sure to evaluate both options if you’re developing anything significantly non-trivial.

Hopefully that’s a balanced view that can be endorsed by both jQuery and dojo camps. I’d be interested in hearing any contrasting opinions on this as I know that there are some quite strong opinions on both sides.


  1. Two things I should mention to give context to my response…

    First, jQuery has been my JavaScript go-to since v1.2 (however long that has been), and second, I promote jQuery with one of my blogs.

    That being said, the first time I had to make a full-blown JS app I turned to ExtJS 3. I felt that the project needed a very tight, feature-rich UI and ExtJS had more to offer than jQueryUI at the time.

    As you say, we need to look at what is best for the project long term. Being shortsighted may make for a short career. I am planning a larger web app project and I am looking carefully at ALL of the technology and at the future. I am considering ExtJS 4, dojo, and Closure. I'm also considering whether I should stay with PHP or move to Ruby or JS on the server. Many considerations are necessary, from initial programming cost, to maintenance, to user experience.

    Keeping a broad view is important for bigger projects. Most of the time, jQuery has the right stuff. Progressive enhancement is a beautiful thing. However, an ERP app written with PHP and jQuery is not. Take it from me 😉

    • I think that not being too short-sighted is really key here, Colin and you're absolutely right in that respect. Over the past few years, I've seen colleagues go through quite similar transitions as what you described – JavaScript to jQuery to Something better suited. That's not to say at all that jQuery doesn't have it's place, but eventually if you're building something significantly large you may very well end up switching to dojo or ExtJS etc, depending on what your needs are and I don't think there's anything wrong with acknowledging that. We should all be open to switching between libraries and frameworks when necessary.

  2. Thank you.. that made me think a lot and try to learn Dojo and other JS libraries.
    I got used to jQuery because it is fast and constantly evolving, so it’s a great base for web applications for me. Other libraries were not that tempting but now I will try Dojo and some others to compare them.
    Again.. thanks and great article!

  3. I gave a hard look at ExtJS 3 and still ended up going with jQuery. It’s true jQuery doesn’t come with a framework bundled and I like that.

    After taking a deep look at ExtJS I found the subclass mess that GoF warn against. Tbh, I wanted to compare with dojo but the boss didn’t consider it (the examples being broken in Ubuntu/chrome did not help).

    As far as the script loader built in require(), I think a dedicated solution like requireJS or the dozen or so others fully satisfy your use case. In fact, there’s a few for practically any use case so I don’t know why I would one baked in. Also, the UI widgets are in several languages last I recalled.

  4. Hi Addy,
    First off, Thank you so much for your time.
    Everyday I can see some new frameworks emerge and this has turned into one of my nightmares. How on earth can I keep myself tuned in all of them so that I can decide which one suits me more? I am asking you because I do believe in you as a professional. Do you know all of them? Their cons and pros? If I have to keep pace with all of them, so when I can go out and play with my kids and have fun with my wife? When can I watch a movie? etc….
    I would appreciate it if you clarify this for me.
    P.S. I am a subscriber of your prolific blog!

    • Although it would probably be a useful resource for beginners to have a break-down and comparison of each of the frameworks that are available (as well as their pros and cons), I feel that just outright telling developers what to use would be doing them a disservice.

      Instead what I recommend doing is spending a little time investing in playing around with each so that you're aware of what they offer. I personally used YUI, ExtJS and Prototype long before I started using jQuery, but I think that spending that time gave me a better appreciation for what their capabilities were.

      It's a similar case with dojo – you may very well not end up using it heavily, but if your focus ends up being complex application development, you'll definitely stick with it.

  5. Interesting blog post allthough I'd like to see you add some comparisons between the libraries / projects – support for tests, maintainability, documentation, load times, execution performance etc.

  6. We are building a large scale javascript app and do not at all regret our decision to stick with jQuery.

    Coupled with backbone you have so much power and flexibility with the structure of your app.

    The most difficult part I find is building the widgets and user interface. Which is hard to do on a library that is not built for that specific task.

    Though I also don't like the idea of being constrained to the usability concepts of a certain framework like ext3.

    I believe usability is possibly the best selling point and best direction towards a more productive future. So I don't see investing time in designing custom usability as a waste.


    p.s. I wouldn't say jQuery itself is the reason why we went this way, its more the fact that we opted out of ui frameworks such as cappacino. We have really only used the selector engine and ajax method. Which means we could possibly get rid of jQuery but after they released version 1.5 with deferred objects we will probably just stay for good!

    • Though it sounds like the ship has sailed for your current project, you may want to take a look at Dojo's UI widgets for future projects. They provide a rich and comprehensive set of widgets, and they are extremely dedicated to accessibility. You can also extend/customize them to suit your particular needs. You can check out the 1.6 version here:

  7. If were trying to stay unbiased is it not worth mentioning YUI, Sencha (formally ExtJS), MooTools, Prototype, and Mochikit?

    It may be the case that neither dojo or jQuery are the perfect fit for a project, and a good javascript developer should strive to have at least an idea of the pros and cons of each major library.

  8. jQuery is a DOM, Ajax, events, and effects library. Dojo, YUI, and Sencha are different flavors of application development toolkits. There is no comparison, so that may explain this article's reluctance to make one. Anyone considering "building a large application with jQuery" is considering building a large application with jQuery and a host of other tools. They'd better know what they're doing: the 2006 paradigm of "get some elements and do something with them" won't get them very far; in fact, they'll be lucky if it doesn't back them into a corner.

    Yes, companies will find it easier to find developers who "know jQuery," but this argument is so easy to dismantle that it's laughable. A developer who lists jQuery on their resume is a far cry from a developer who knows how to assemble and maintain a custom application toolkit. The fact is that the tools provided by jQuery are such a minuscule part of a non-trivial application that a developer's knowledge of jQuery will be incidental to their ability to work on the project. Likewise, measuring a prospective hire's knowledge of jQuery will be a poor proxy for gauging their ability to work on a non-trivial project.

    When I talk with people who have worked on large JavaScript applications with more than one toolkit, we have spirited, informed debates, sharing our knowledge about the tools that we've used to solve common problems across toolkits. When I talk with people who haven't worked on large applications but feel entitled to an opinion anyway, the substance of their argument generally boils down to "jQuery is popular" or "you should do what feels good." Such shallow arguments do developers — and the companies that will pay for their mistakes — a huge disservice.

    • This comment really hit home for me. I am a fledgling JavaScript developer, having used mostly static, compiled languages in my college studies. For my first job I have been working on a Spring-MVC application that uses a fair amount of JavaScript. At first JavaScript made me want to break my monitor. As I became more comfortable with the syntax and more familiar with the jQuery library I started to feel that maybe I was starting to grasp it. I was very mistaken. What I did was realize that the codebase was actually extremely unorganized, using very heavily that 2006 paradigm you mentioned. I have been tasked with most of the JavaScript work that needs to be done and I am so desperately wanting to embrace a better method. Recently I have just been reading articles about design patterns and libraries. Unfortunately, I am still having trouble applying the knowledge. I would love to hear anything else you have to say about this topic.

    • Very well said… did we not have similar structured (silly) discussion (now) decades ago when putting out eye catchers like ‘VisualBasic vs. Java’? Time(machine) has shown that in-house the prior got the smart and sharp sibling C# in order to conquer emerging challenges. So – what may the lesson about popularity and time continuum teach? – Lived, suffered, and enjoyed myself about all that was and some that still is around – including home grown things – the problem is less the use of a particular tool or toolset, language, library or framework, but more so the lack of consequent and consistent application principles in software development and life cycle management. To whom do I preach to? To myself: after successfully implementing two non-trivial systems in Single Page Architecture and Adaptive Design (RESS) taking the tougher road, I decided to take it not that serious for the next thing at hand, because it wont be as complex. No need to take it that serious, it is just a small thing. I had to wait – I mean – work not many days to reap what I sowed: falling apart application and prohibitive high effort for even small changes/enhancements. „Errare humanum est“ did not give me much comfort – and for sure did not fix the issue either. Agreed, noteworthy tools support and even solicit beneficial thinking and acting – but even the best cannot compensate developer illiteracy or intellectual laziness.

  9. I have recently designed the front-end portion of a JS thick-client application and we are using jQuery. But only for the "View" part of MVC. jQuery templates are awesome btw. We wrote our own route handling object. The controllers just respond to route changes and any UI events from the View that require data from the model. We used $.ajax for the service/model layer and it's worked really well.

    We looked into Backbone (before writing our own MVC implementation) and it is now far more mature than it was at the time we started and I think Backbone is a great lightweight place to start.

    I have used Dojo a few years ago now and I must say I haven't looked at it much since then. I think it's got some great features from what I have read, but this project has worked it pretty well without it so far.

  10. I have been using JQuery in all of my projects, and I haven't ever felt the need to go to Dojo.

    I don't really see any concrete arguments as to why exactly JQuery is not suitable for large scale projects? What exactly does it have missing in OOP that can be the difference between success and failure of a large project?

    • Unfortunately, the majority of "jQuery developers" only know/use jQuery.

      When building something non-trivial you need to relegate jQuery from being some all singing all dancing magical silver bullet, to being just a DOM/Ajax library, and pull in other things for templating, code organisation, controllers/history management, pubsub, dependency management, etc, by the time you have done this you have pretty much rolled your own framework, and could have saved yourself some time and effort going with one that had all of those features from the start.

      For adding the hand full of standard effects most web pages use, most of the other frameworks can be a bit overkill, but if you try to build a complex web application in jQuery alone, all your going to find yourself with is spaghetti code.

    • A large scale application is more than just DOM manipulation. Think how you might approach MVC and indeed OO with jQuery (when did you last create a class in jQuery?). That said, jQuery is superb for what it is – but it's not always the right tool for the job.

  11. Great article again, Addy.

    I guess it is a matter of choosing a library; getting skilled in it and delivering something.

    The issue with there being so many new libraries popping up on the javascript landscape is that one is tempted to chase down the next best thing while halting development.
    This is obviously never a recipe for success.

  12. Pingback: fuzero » Blog Archive » jQuery是大规模应用开发的最佳选择吗?

  13. jquery can be used for large scale development(as everything else), but has very little to teach about the necessary development best practices and discipline needed to build them.
    should we ask the reverse question, is dojo a viable option for fast, time constrained development of small apps by relatively inexperienced developers?
    what a beginner should focus on to get things done fast and right with a large framework?

    • A fair argument to be sure and to that I answer use dojo base as you will see it is quite similar in functionality and capabilities as jQuery. The advantage with this is that as your application or project grows, you won't have to switch toolkits—you can start with the DOM/effects/selector engine conveniences of dojo base and end with nice JavaScript classes that support classical inheritance and a well-crafted widget framework and module system.

  14. i have always been a jQuery user for a long time,it was fast concise and a small footprint,however after advancing my JavaScript skills,it was good at just traversal,DOM Manipulation and selectors,i wanted something more robust advanced,i experimented with Mootool,prototype didn’t feel comfortable with them.till i encountered the Dojo toolkit,at first i abandoned it, after all i was used to the notion that all JS frameworks should be as user friendly as to now i use Dojo in basically 90% of my projects especially as Zend offers good integration with Dojo.Dojo is a complete toolkit,the beauty of dojo is you only get to create a class/widget once and you can extend it into anything you can think of.basically i think jQuery can still be good for Large Scale projects,but the Dojo toolkit was built for that purpose as it is Modularized.

  15. This post is very timely for me, as I have been finding myself reaching the point where it seems I have to do a lot of wrangling in jQuery to get some of the capabilities I need. I've begun looking at dojo and it seems pretty comprehensive, but I do wish there was more extensive documentation. I find myself needing a js framework that supports OO and a smooth integration between the UI and the data it represents. It seems that dojo accomplishes that pretty well, though I am still just beginning.

    • I think documentation is probably one of those key areas of dojo that a lot of people trip up on initially. It's not to say the docs available are bad, we really just need something a lot more comprehensive (as you correctly mention). Until they're improved, you might find picking up books like 'Mastering dojo' or 'Learning dojo' useful. There are plenty of good ones out there.

  16. We have been through this exercise in my company (a large enterprise) and we decided on Dojo and we are very happy with the decision. Dojo indeed offers enterprise level features such as accessibility, internationalization, layered architecture (data layer with bindings, notifications etc) and plays well with other libraries including jquery
    It does come with some cost as a handwritten JS specific to your needs will always run faster – but the cost savings and reduced dev time more than pays off for the slight performance penalties with stock widgets.

  17. Every jquery developer knows the important of this that's why every developers want to increase their skill in this.I also interesting in his but I am not familiar with jQuery

  18. I guess what I don’t understand is what separates the “large scale” from the “small scale”. Are you guys building Google Maps here?

    I’ve seen jQuery scale up to match the demands of a lot of projects by people learning how to write plugins instead of expecting them to be written for them. That’s the true reusability pattern of jQuery, and it seems like a lot of people don’t bother learning how to write them for some reason.

    They are the class building block.

    DOJO besides being “enterprisey” does not seem to be faster than an average jQuery plugin that you can find by googling for one of any of the 1000 features an average website might need. The plugins for jQuery are more performant in typical cases, and can be more easily swapped should another one be needed.

    When people talk about how they are writing “full JS apps” I start to question what it is they are actually writing. Sure something like Ember.js might be good if you’re writing a full app, or Google Closure Tools or a host of other things, but the UI has to be equally complicated to a Google project in order for you to go in pursuit of these other technologies.

    I personally think a lot of people try to force a larger toolkit onto the project they are working on because they want to learn something new or look cool. jQuery works for 90% of web apps today. Most people want simple enhancements on forms and crud apps. Pretending like a DOJO widget gives you “that much and so much more” is only true until you look into the details.

    I can give you particular examples of that.

    DOJO’s new grid widget seemed like a great idea until it came to implementation. While other jQuery plugins seemed more like what they were (a JS enhanced HTML table), the DOJO grid seemed to provide a more “enterprise” or “desktop” feel. Only problem is, that when you start to use the DOJO grid widget to do one of the things it’s supposed to be able to do easily, it starts to show how it doesn’t work how you’d expect.

    If you bring back thousands of rows in the DOJO grid, you’ll find yourself immediately wanting a server-side component. Good luck. They decided to write part of the sorting for the grid to make a semi-serverside API. One portion of that API uses non-standard query parameters (things like sort(name+)) the other portion (the paging API) uses things like accept-range headers…the third portion (the filtering portion) is not really even written, you can get the string of filters, but good luck implementing it serverside.

    This makes you hesitant to have the server do its job (paging, sorting, filtering) because the API is so complex. The programmers desire to simply throw all the 10000 rows at the client then, and allow the browser to sort it out.

    Turns out IE is just a little slow in doing that…and since we work in the real world, IE needs to be supported….not to mention, you know, the data over the wire when you are sending 10,000+ JSON objects.

    It ends up being slow, buggy, difficult to implement and brittle to change. Even getting the results into the grid required two different serverside implementations.

    The people who wrote DOJO appear to not have an ounce of mercy for someone who might have to actually use one of their widgets.

    In jQuery I would’ve swapped plugins 10 times by now (or written my own), in DOJO, I’m stuck. I don’t have enough time to write my own grid (obviously, because that’s why this was chosen) and there’s nothing to swap to.

  19. jsRevolution, OmniStation’s new JavaScript Framework and Build Tool, is the most robust commercially available framework on the market. It is designed for large-scale deployments of non-trivial applications. Our clients may have 100’s or 1000’s of classes, 10’s even 100’s of developers. While these clients will find the framework indispenable, jsRevolution is practical for certain applications with as few as 25 classes.

    jsRevolution’s many features include: Asynchronous Loading, Codeless Namespacing, URL Switchable Code View (from Dev to Deploy), Codeless Inheritance with build-time validation, Codeless Interface with load-time validation, Codeless Abstraction (sometimes referred to as Mixin), the ability to identify a resource as an instance class, Multi-Versioning (multiple versions of classes within the same application -simple to execute), and many other features.

    For more info or a demo, contact me at, or visit www.

Leave a Reply

Required fields are marked *.