First of all, getting Ext running is slightly more complicated than getting jQuery running. jQuery is a simple matter of including jquery.js in your HTML and then writing your script. Ext requires first it’s own CSS file, then an adapter which uses another library (jQuery, YUI or Prototype) but can also use the newish ext-base.js which doesn’t depend on external libraries, and finally you include ext.js itself. I went with the pure Ext solution but tried out the jQuery adapter and found it didn’t work for me – I’m sure I was doing something wrong but didn’t care enough to fix it and went back to Ext.

Secondly, Ext is rather huge. Not surprising considering what it can do but the whole thing (ext.js, ext-base.js and stylesheet) still comes in uncompressed at just over 512KB. Sorry, I should mention that that’s with Ext’s default minification – the debug versions are a bit over 1MB! In comparison, jQuery is roughly 70KB before any minification is applied. So what do you get for all this size? Quite a bit actually.

The customer info area of my application is designed with a list of customers on the left and an area for details on the right. With pure HTML and CSS a nice-looking layout here, similar to a desktop app, is really difficult to achieve. With Ext it’s almost trivial and you can use a logical declarative style of recursive JavaScript objects to define the layout – similar to how it would be done in Java Swing, for example. With Ext you can also easily get “bonus” features like resizable panes, content areas that adjust to the size of the viewport and a default style that looks pretty damned good (and you have to option of using different themes). Without any trouble I was able to get a simple list working which allows clicking on customer names to load their details asynchronously in the details panel, as well as allowing dynamic updates and the like.

The standard things that I use with jQuery – selectors and AJAX support – are also well supported in Ext, even if they are slightly more verbose. Ext also includes a nifty feature in it’s simplistic load() method that allows you to set a loading message, something that I believe you have ot do manually in jQuery.

Ext also supports a wide range of widgets and the like out of the box. Data grids are all the rage now and Ext makes it simple to get them up and running. Tree views, buttons, colour pickers, date selectors and a bunch of others are provided as well. If there’s something missing you might be able to find a plugin for it.

Overall, I’m really enjoying working with Ext. It makes some fundamental yet complex things ridiculously easy and provides enough of a framework to get almost anything working with a bit of lateral thinking and liberal application of nested layouts and the like.

So I guess the obvious question now is if I prefer Ext or jQuery? Honestly, the two are just aimed at completely different areas. If you’re making a web site that needs some fancy JavaScript effects, a bit of AJAX and you want it to be light and accessible, then I’d say jQuery is the way to go. If you want a RIA with lots of advanced functionality and don’t care about those plebs who don’t have JavaScript then I’d say Ext is definitely the preferred option. If I had to pick I’d say I like jQuery a bit more since I prefer writing enhanced web sites rather than desktop application wannabes but this is really just a personal choice. Both libraries offer the same basic functionality and jQuery can certainly be extended to do pretty much what Ext does so choosing either will probably let you do what you want.

So far, the supported features are: authentication with username/password, viewing of the queue, uploading new torrents (from a local file or a URL), auto-refresh and pausing/resuming downloading. This enough for basic administration but one rather essential feature that is missing is the ability to change the queue position of torrents, such as to move something up or down. There are also no settings available so it relies on you having the system set up beforehand and not wanting to change anything.

Another key problem with running WebUI on Deluge is that the program itself requires a full desktop to be running as it requires GTK+. This means that you can’t run it on a server that has been set up to run a minimal set of software daemons from the shell. There’s no real reason why a torrent program needs a graphical interface so maybe a “headless” mode will be enabled on Deluge in future versions.

One interesting design decision made is that images and stylesheets are in a different directory to the templates. From the sounds of the directory they’re in (static) the intention is to have the unchanging components served from a different directory which could theoretically be on a completely different server. This is good practice for high traffic sites and is a common way of optimising a web site but I have to wonder why it was employed here. I assume that a personal interface to your BitTorrent client would not qualify as a high traffic site and the templating system is extraordinarily handicapped by having stylesheets and images in a different directory that is not related to the template in any way.

I would like to take a look at the plugin further and see if some improvements can be made, such as allowing full AJAX operations. I think using AJAX refreshes would be particularly beneficial as full page refreshes are terribly wasteful in terms of bandwidth and not very nice from a usability point of view. Other improvements should just be a matter of changing the template – for example, making the layout fluid rather than fixed width.

The WebUI plugin for Deluge does look promising and could eventually replace Azureus as my BitTorrent client but there are some important problems that would need to be addressed first.