The rest of my team may not agree with me, but I greatly prefer the Dojo Toolkit to jQuery, when it comes to Javascript libraries. Why? Perhaps it's because I want to justify the hundreds of hours I've spent learning and re-learning the API as it continues to evolve. But I like it because they're inventing the future, actively trying to make Javascript a full-fledged environment for any kind of programming.
Dojo Toolkit is a collection of widgets, patterns, and libraries for everything from event management, publish/subscribe functionality, and mobile widgets to syntax highlighting, class constructors, and in-browser data stores.
Before Drupal made jQuery part of core, there were a fair number of sites using Dojo with Drupal. Nowadays, pretty much none do -- the Dojo developers who used to use Drupal have moved on to server side Javascript platforms like Comet and Persevere, and now Node.js. Dojo also has a lot of uptake among Rails developers, and Zend Framework. But in Drupal, it's widely ignored.
We have sprinkled some Dojo widgets into a variety of sites, including a dojox.gfx-based seating chart widget, and a custom CCK widget that's a much nicer auto-complete than the standard Drupal one for use with a specific node reference with associated data.
At the moment, integrating Drupal with Dojo is a lot more hassle than it should be. While we have built a basic Dojo Toolkit module, it's a long ways from being something that useful. Javascript aggregation breaks Dojo, builds are still way too hard, and jquery_update/jquery_ui modules often break Dojo. And most anything you want to do in Dojo requires loading an ungodly amount of Javascript before it's ready to go.
But Dojo 1.7 changes all of that with an entirely new way of including just the files necessary for the items you want to use. I'm in the midst of rewriting the Dojo Toolkit module to support the new AMD (Asynchronous Module Definition) format, with asynchronous loading right now, hoping to carve out a few hours to wrap that up in the next week.
Once that's in place, we're really excited to start leveraging some of the coolness that is Dojo. Like:
- Dojo Mobile -- mobile widgets that make web applications feel more native
- Charts -- Dojo has a great chart library, with animations and in-browser data -- perfect for playing around with different scenarios
- Trees -- more on this later, but we see a lot of opportunity for modeling hierarchical data using Dojo Trees with Drupal on the back end...
If any of this sounds useful to you, drop us a line or leave a comment below!
what's hot now in drupalland?
Before Drupal made jQuery part of core, there were a fair number of sites using Dojo with Drupal. Nowadays, pretty much none do -- the Dojo developers who used to use Drupal have moved on to server side Javascript platforms like Comet and Persevere, and now Node.js. Dojo also has a lot of uptake among Rails developers, and Zend Framework. But in Drupal, it's widely ignored.
I came here on a link path from dojo toolkit while researching deploying drupal site to alternative viewports such as mobile devices: phones, tablets, etc. Your mention of Node.js as the goto framework - do you feel it is still the frontrunner for enabling drupal sites to do mobile well?
Drupal can do mobile well --
Drupal can do mobile well -- it's just that it didn't help you that much for REST-based Ajax calls. It's not that hard to build that functionality into Drupal, and we've been doing that for years, creating JSON feeds with a menu callback, or implementing Services module with some code to make the actual API more usable.
In Drupal 8, we get web services right in the core, so that gets much better, on a par with any other PHP framework.
What Node.js does that's hard to do in Drupal is push. If you want to have a lot of connected clients retrieving immediate updates based on events happening on the server (or other clients), PHP is a bad platform, and Node.js is great.
With PHP, you do have options -- you can poll (which causes scaling issues and lots of extra load), you can use Bosh (keeping long-running connections open to the server, again causing scaling issues with the single-threaded, single-process nature of PHP), or you can delve into the new PHP socket functionality which is more equivalent to what Node.js is doing, but now you need to think about the RAM consumption issues you normally just ignore because you don't have any long-running PHP processes.
That's where Node.js shines.
It's my goto framework, because I know Javascript pretty well, and I can get my head around closures and callbacks and such, and have enough experience with it to be productive. I won't say it's THE goto framework, because there are plenty of others -- you can certainly code up something just as good in Python, Perl, or Ruby, and I'm sure there are a few hundred viable ways of going about this.
So in short, if you have a system where you want to have a lot of constantly connected clients retrieving updates as they happen with minimal delay, Node.js can be a great complement to Drupal. If you just want to build a mobile-friendly site, Drupal 7 does just fine all the way around. If you want to make a light-weight, highly interactive, Ajax-driven site, you might find it a bit easier to start on Drupal 8, as long as you're willing to live with some pain of running pre-production, unstable code...
Add new comment