JQuery 1.2 is upon us and, as usual, there’s already tons of carping discussion in the comments section of Ajaxian. I took a wander through the 1.2 release notes and the source code, and while I’m impressed with many of the new features, I’m a little disappointed with status quo of the Effects object. They’ve updated the queue and dequeue methods and made them public, but effects queues continue to be maintained separately for each element. This was a real stumbling block for me when I took jQuery for a test drive on a demo project last month. Compared to Script.aculo.us’s global effects queue, jQuery’s element-by-element queues provide far less precise control for combinations of effects on disparate nodes. It’s difficult to coordinate the timing of effects when you want, for instance, to pause the processing of all effects globally in response to an event, then restart some or all of them. The queue and dequeue upgrades are a step in the right direction, but I’d love to see a truly global effects queue that can be sliced and diced into named or element-based sub-queues as appropriate. In the meantime, I’m starting to agree with the widespread belief that jQuery is great for quick, unobtrusive effects but less appropriate for complex, large-scale applications. Am I just missing something? Would this feature be overkill for a library with jQuery’s stated aims? Let me know in the comments.
@Brian: “I’m starting to agree with the widespread belief that jQuery is great for quick, unobtrusive effects but less appropriate for complex, large-scale applications.”
Without citing any examples, I’m not sure how you’re coming to that conclusion especially with the # of large scale sites using jQuery.
@Rey: right now jQuery is an entry-level library until robust class support is provided. This is a very important feature when you build a large OO system (see for example OpenLayers). The Prototype core team understands this requirement, and they moved the release of true support for inheritance and superclass methods from the planned release 2.0 to 1.6.
@Les: So, the current release of Prototype is just an entry-level library as well, since it doesn’t have inheritance and support, right?
I left out something so I’m reposting my comment:
@Les: So, the current release of Prototype is just an entry-level library as well, since it doesn’t have inheritance and superclass support, right?
@Rey: I am enthusiastically exploring jQuery alongside lots of other libraries/frameworks in my role as RIA Evangelist at Pathfinder. Based on my one attempt to write a fairly simple Ajax app in jQuery, I found the conceptual framework for effects management less robust than what I was looking for – as outlined above. I’ve been reading lots of the commentary in forums across the ‘net, and the common thread seems to be that jQuery is a joy to use but isn’t yet as mature as some of the other frameworks. It does a lot of really cool things at the micro level, but it doesn’t provide as much scaffolding at the macro level. I don’t have a problem with the lack of baked-in inheritance; if anything, I am learning to enjoy the ability to define my own inheritance strategies rather than having one thrust upon me by the framework. But the way the effects queues work now, I don’t have the hooks I needed for this one particular application. I’d love some insight into how the jQuery team seeks to position their product in the future – as a comprehensive framework for applicaiton development, a toolset for unobtrusive JavaScript, or both. Depending on the answer, then my particular case is either a nonissue
or the starting point for a discussion about the framework’s roadmap.
@Brian: I’ll be at TAE so we can chat about it there. Also, as you’re doing your due diligence with jQuery, please feel free to contact me if you have any questions. Since I’m a member of the team, I have the full resources of the projects at my disposal.
“But the way the effects queues work now, I don’t have the hooks I needed for this one particular application.”
I think you’ll be happy to know this: I just found out that John had been working on a brand new global effect queue plugin and will be releasing it this Sunday, along with the new jQuery UI.
“I’ve been reading lots of the commentary in forums across the ‘net, and the common thread seems to be that jQuery is a joy to use but isn’t yet as mature as some of the other frameworks. It does a lot of really cool things at the micro level, but it doesn’t provide as much scaffolding at the macro level.”
This is an area where I’ve yet to hear of concrete, real-world examples where jQuery has failed to meet the needs of users. I’m in regular contact with the folks at Digg, one of the largest jQuery users, and not once have I heard that jQuery couldn’t meet there needs.
“I’d love some insight into how the jQuery team seeks to position their product in the future – as a comprehensive framework for applicaiton development, a toolset for unobtrusive JavaScript, or both.”
If you look at jQuery, Prototype and MooTools, they all target the same audience and manage to do a good job of serving both as a framework and a tool for sprucing up web pages. Apart from the OO arguments, they all provide VERY similar capabilities, and in terms of ease of use, jQuery simply is the hands down winner. What I tend to see is that proponents of other libs try to portray jQuery as non-scalable solely because of the lack of OO. I find it totally ironic to hear Prototype fans claiming jQuery is a toy when the current stable release of Prototype, v1.5.1, doesn’t support the very things that they’re chastising jQuery for. Through all of the conversations I read about OO, rarely do I hear discussions about object modeling, subclassing, ORMs, polymorphism, UML or use cases.
In addition, I truly question how many developers will have the skills necessary to properly leverage object-oriented development techniques. Having done object-oriented development for 8 years prior to developing for the web, I’m keenly in tune with the thinking that goes into building OO apps and I don’t see the typical users of these libraries becoming the big OO mavens. I see a minority of developers really utilizing the libraries to their full potential with the rest using them to add snazzy features to their apps. So when I hear an argument that jQuery isn’t enterprise-capable because it isn’t OO, I laugh. Tell that to companies like Digg, Intuit, MSNBC, Salesforce.com, & Cisco who rely on jQuery. Until someone can give me concrete examples of how jQuery has failed to meet their needs (not just anecdotal evidence), I will continue to contend that its just FUD. Here’s a very comprehensive list of sites that use jQuery successfully.
http://docs.jquery.com/Sites_Using_jQuery
I won’t debate the benefits of OO development and if done right, its very powerful. But if OO were that important, then everyone would’ve been using Dean Edward’s Base!
@Rey: do you have any plans to add robust class support in jQuery? When?
Prototype 1.6 RC0 supports classes and inheritance, and the code is very stable. I highly recommend it for large OO projects.
Here’s an example of a large OO system designed using this library:
http://www.slippymap.com/index.html
jQuery is a very nice mini library, but if you are working on a large application, I’d stay away from it.
@those in need of OO support:
First of all, JavaScript itself is object-oriented, and supports inheritance. Just because a library doesn’t provide support for a particular style of OO (usually mimicking a class-based language similar to Java) doesn’t mean you can’t use the object features of the language itself.
It takes a little extra effort to understand a prototype-based language, and JavaScript is not as cleanly and fully implemented as I would like, but I do OO development in it every day without support from a particular library.
Here’s a two part article that covers the basics pretty well:
http://phrogz.net/JS/Classes/OOPinJS.html
JavaScript itself confuses the issue in that it mixes in some terminology and constructs to try and appease the class-based crowd, without including some of the nicer features of other prototype-based languages.
Wikipedia has a good general article on prototype-based programming:
http://en.wikipedia.org/wiki/Prototype-based_programming
One of the most influential prototype-based languages was Self, developed by Sun:
http://research.sun.com/self/
Another of my particular favorites is Io:
http://iolanguage.com
Please try to understand what JavaScript is, where it came from, and what OO means (OO != class-based).
And by the way, jQuery rocks!
It provides buttom-up support for a wide variety of tasks very cleanly, without imposing any sort of top-down conceptual model or framework that you have to buy into, including OO style. IMHO, it is perfect for progressive enhancement up to fairly complex apps that fit in with a more natural web style.
If you are doing something different, say writing a desktop-style app, maybe jQuery isn’t the best choice. That’s cool, too. Use the best tool for the job. But arguing against it because it doesn’t support OO seems to miss the point as discussed above, though I can see how standardizing on an OO approach can help get a team on the same page, especially ones used to class-based programming.
@David: Can you provide some examples of large Web applications where jQuery is used as the base library? Let’s define large script as being >100KB gzipped. If you could provide some links, that would pretty much end the discussion for me.
Thx,
Les
@Les: Both Oracle and Salesforce have large-scale Intranet applications that use jQuery extensively, more than satisfying your “large script/application” desires. I’m glad to see we were able to help resolve this debate for you!
It’s interesting that you would argue this, especially considering that Dojo is often considered to be the king of corporate application development; and it includes namespace and packaging support, something that Prototype doesn’t provide. You’ll find Alex Russell frequently arguing that corporate, team, development is only really possible with a good packaging solution in place. So, arguing that having inheritance now, somehow, makes Prototype the best possible library for application development seems quite misguided.
Thus, I think it’s very safe to say that it’s possible to develop large scale JavaScript applications using a number of techniques: Object-Oriented with Inheritance (Prototype), using Namespaces and Packaging (Dojo), and Functionally (jQuery). Since, obviously, all three techniques have been proven to actually work in real-world situations.
@Les:
My point was that JavaScript is an OO language, though an odd one, and it is possible to write OO apps without using *any* library as a base.
If that is so, you don’t really *need* the library to provide an additional OO helper layer, though some may find it useful.
Hi, just to let you know that I developed a plugin that allows global effect queueing =). More info at: http://jquery.com/plugins/project/fxqueues