Dojo gets a speed boost on IE6 and IE7

My former employer, Cúram Software, was good enough to give me a couple of months to work on the performance issues that Dojo and it’s widget project Dijit have in horrible legacy browsers IE6 and IE7.  Some of the fruits of that labour have now been checked into the code base and will be included in Dojo 1.6, out in Q4 2010.

So what I/we learned from the exercise?

DynaTrace rocks!

To begin with, I can’t praise DynaTrace enough.  It’s a fantastic piece of profiling software that delves deep into Internet Explorer’s innards to find every little horrible Microsoft bug.  It can take a while to get used to, but that is just because it presents you with so much data, all of it useful, and anyone would have trouble finding a way to make it easily consumable.  Long story short, if you’re having performance issues with your site in IE, download DynaTrace.

Touching className makes IE cry

Pretty much every time you change the className property of a node, IE6 and IE7 reflow the page.  It doesn’t matter if the new value is the same as the old one, or whether or not the changed CSS class has any visual effect, IE will redraw the page, resulting in a lot of time being lost.

Dojo was changing className too often, for example in dojo.addClass, if the class being added was already present, it would still assign the changed value to className.  I put a fix for this into v1.5.  There were also many cases where Dojo would use a combination of dojo.removeClass and dojo.addClass to replace a class, which changed className twice instead of just once.  To fix this, I’ve added a new public api dojo.replaceClass, which only changes className once.

Dijit widgets often add CSS classes to the DOM nodes which they are creating after the nodes have been inserted into the document.  This is costly, and a large performance improvement can be gained by applying these classes earlier in the lifecycle, before inserting into the document.  Bill Keese (Dijit master) checked in the first of the fixes for this for the BorderContainer recently, and a strategy is being formulated for the many other widgets that can benefit from this.  This work should be completed for v1.6.

Risky but…..

A solution that we cannot use for Dojo, but which we found gave huge performance gains for my company’s application, was to figure out what CSS classes Dojo would apply to a node and write those classes out when generating the HTML.  For example, when creating a dijit.layout.BorderContainer, our HTML contains the CSS class dijitBorderContainer.  There is an inherent risk with this approach, as Dojo may change the CSS classes in a later release, but if you’re willing to accept the risk and the upgrade pain, you can get a nice performance boost this way.

Reading offsetLeft and offsetTop is costly

When your code reads the offsetLeft or offsetTop of a node, all pending changes to the DOM have to be performed first.  This can be very expensive – we saw a number of single operations taking over 500ms each!  Many Dijits were using the dojo.marginBox method to get the left, top, width and height properties of a node, when all they needed was the width and height.

To solve this, I introduced a new method, dojo._getMarginSize, a private method that just returns the width and height of a node.  This has resulted in huge gains in performance on IE6 & 7, especially when used with layout widgets like the BorderContainer.

Unexplained gaps in DynaTrace profiles

We hit a bit of a wall at one point when analysing the performance profiles, where there was a 1.5 second gap in the profile where it seemed like nothing was happening, but everything was paused with the CPU at 100%.

We eventually discovered that there is a horrible bug in IE7 where if you have a :hover style on something that is not an anchor tag, it causes the rendering engine to go crazy, get all confused, and push the CPU up to 100% for no reason at all.

The solution: don’t user :hover styles on anything other than <a> tags.  Ridiculous I know, but so is the IE7 rendering engine.

Give it a go!

So, the long and short of it is that Dojo/Dijit should now be a good bit snappier on IE6 and 7.  With our application we got the load time for a huge application down from 20 seconds to 5 seconds using these techniques, making IE7 far, far more usable.  Of course it just flies on any other browser, even IE8 which, all credit to MS for once, is far less buggy than the earlier incarnations.

So feel free to try out the Dojo nightlies, you should find them to be a good bit more responsive in IE6 and 7 than just a few days ago, and now that we have learned some important lessons, Dojo will be even faster for v1.6.

Dojo’s mobile widgets coming along nicely

I’ve been working a lot on Dojo’s new mobile framework (see HERE for my intro post on dojox.mobile.app) and the Image widgets are coming along very nicely.  I just checked in a new Thumbnail viewer, and enhanced the ImageView widget.  Check them both out at http://bit.ly/cU3akI.

Click the “Browse Flickr” selection to see both images integrated with Flickr, as well as a dynamic group search view using the TextInput and List widgets.  Given that these widgets use cool fancy HTML5 effects, you’re best off viewing them in a WebKit browser, so Safari, Chrome, webOS, iPhoneOS (iOS now I guess) will give you the best experience.

The ImageThumbView uses CSS3 transforms to position the thumbnail images, and animates the opacity with CSS3 to fade in/out images. 

Dojo’s new Mobile App Project

Dojo v1.5, which should be released in the coming weeks, will contain an early beta of a new infrastructure for building Mobile Apps.  Currently it is called dojox.mobile.app, but that is expected to change.  Check out the test apps (the bottom section) at http://www.skynet.ie/~sos/misc/dojoxMobile/tests/dojox/mobile/tests , which work best in WebKit, so use Safari or Chrome for best results.

Jared Jurkiewicz and Yoshiroh Kamiyama recently added the dojox.mobile project.  It provides some very nice widgets for use on mobile phones, such as views that can transition between each other, rounded lists, tab containers etc.

However, the focus of dojox.mobile is to be very small, so as to suit websites formatted for mobile devices.  When writing cross device apps that are hosted on a phone, the size of the JavaScript is less of a concern, so a much more powerful experience can be created.

Hence, dojox.mobile.app is born.

It is built on top of dojox.mobile, but adds many new features, with more on the way.

• Templated views that can be pushed and popped off the stack of views, all of which are lazily loaded.
• Templated lists
• Input widgets
• Image Gallery
• Dialog Boxes
• Popup Menus

are all available now.  The structure of a dojox.mobile.app application is modeled very closely to a webOS app.  The templates and code are in a similar folder structure, and the lifecycle for creating and destroying (popping) scenes/views are very similar.

The goal of dojox.mobile.app is NOT to replace or duplicate the functionality in PhoneGap.  PhoneGap provides low level access to many phone features. dojox.mobile.app aims to provide an easy to use, flexible application structure, and many widgets that you will find useful, all themed to appear native to each platform.  In a real world app, it would make most sense to use both PhoneGap and dojox.mobile.app.

One of the cooler widgets currently available is the ImageView widget, check it out at http://www.skynet.ie/~sos/misc/dojoxMobile/tests/dojox/mobile/tests/imageControlsApp .  Some of its features include

• Canvas based
• Touch capable
• Swipe across to change images
• Tap to zoom in, and then swipe to move around an image
• Progressive loading of images – first load a small version of an image, and later a larger version

dojox.mobile.app is currently tested mostly on the iPhone, but will soon support webOS and Android also.  The mobile world is an exciting place to be right now, and Dojo is jumping in feet first 😉

Huge performance increase on IE for Dojo 1.4

Performance charts have just been published for the newly released Dojo v1.4, and the focus that the team put on improving Internet Explorer performance has really paid off.

On IE6, IE7 and IE8 there are speed improvements across the board of between 25% and 40%.  That’s huge.

See the charts (courtesy of Pete Higgins) here – http://dante.dojotoolkit.org/taskspeed/report/charts.html?exclude=puredom+jquery126+prototype1603+firefox35+safari40+opera100+chrome30+chrome40+opera96+firefox36+firefox30+firefox20+mozilla19+safari32+defaultbrowser0

Run the tests yourself here – http://dante.dojotoolkit.org/taskspeed

First Palm Pre Dojo-powered app, Irish Rain

My first Palm Pre application, Irish Rain, has been published to the Palm App Catalog. See my first blog posting on it here.  Irish Rain is written using Mojo, Palm’s JavaScript framework, and the Dojo Ajax Toolkit, a project on which I’m a committer.

Irish Rain is completely free, and should help make sure that us poor Irish don’t get caught in the rain again.  However, I make no guarantees that your house won’t be washed away in a biblical flood!

Dijit Tree now ultra-stylable

The Dojo Tree has always been easy to make look just like you want, from changing the icons to changing the labels.

However there was always a limitation in that an entire row could not be styled.  Well, today I put through a fix for that, and you can now specify a CSS class and style for each row using the getRowClass and getRowStyle functions.

You can see a simple test of this at http://archive.dojotoolkit.org/dojo-2010-06-01/dojotoolkit/dijit/tests/tree/test_Tree_Styling.html , available from Oct 2nd 2009, and it’ll be included in version 1.4, which goes into beta any day now.  It shows how you can easily make the tree appear like an expandable, nestable list widget, with just a tiny bit of CSS.

I also plan on writing up a number of dojo.cookie articles over at dojocampus.org in the coming weeks on all the cool things you can do with the tree.

dojo.beer() event in London, Oct 3rd

The dojo.beer() circus is coming to London!  On October 3rd 2009 Sitepen and Uxebu are hosting an all day dojo.beer() event, including talks on all things Dojo from the core committers, a bit of hacking and a lot of beer.  Not neccesarily in that order 😉  See http://dojobeerlondon.eventbrite.com for more details.

I’m hopping over the Irish sea to join in the festivities, hope to you see you there

Getting started with developing on the Palm Pre

This post explains how to get up and running with Palm Pre development, including getting the tools, setting up the emulator, as well as getting debugging and the inspector working.

In the last few days I’ve started playing around with the development tools for the extremely cool new phone, the Palm Pre.  The coolest thing, from a developers perspective, is that all application development is done using HTML, JavaScript and CSS.  That means if you can write a website, you can write an application for the Palm Pre (though not necessarily a good one).

However, while Palm does provide a pretty good site, http://developer.palm.com, to help you get started, it’s missing some crucial information, which is scattered all over the web (trying to find out how to do logging is a nightmare).  So, this post will explain some of the steps you need to take to get up and running.  As I prefer to use Palm’s Eclipse based development tools, this post assumes that you are using it also, and not go into the command line stuff.

1. Getting the Tools

Follow Palm’s instructions here – http://developer.palm.com/index.php?option=com_content&view=article&id=1597 , to install their tools.

I strongly encourage you to also get the Eclipse development environment, which while it is a large download, is very useful for packaging and  launching your application with a single click.  Get Eclipse by following the instructions here – http://developer.palm.com/index.php?option=com_content&view=article&id=1639 .

The Eclipse page also includes the required steps for creating a new WebOS application, adding scenes (a scene can be though of as a single web page, and you application will be made up of one or more of them) etc.

2. Create a New Scene

After following the instructions on the Eclipse page to create a new application, create a new scene clicking “File-New-Mojo Scene”, and give it the name “main”.  You should see a number of files created:

• app/assistants/main-assistant.js – This is the JavaScript code that will be executed when your scene, or page, is rendered
• app/views/main/main-scene.html – This is the HTML that defines the displayed HTML for the scene.
• sources.json has also been modified to add information about your scene.

As we want the “main” scene to be displayed when the application starts, open the /app/assistants/stage-assistant.js file, and in the setup method you see there, add the following line:

this.controller.pushScene(‘main’);

That line loads your “main” scene.

3. Starting the Emulator

Palm provides a very cool phone emulator that runs on VirtualBox, which you installed earlier.  Start it by (in Windows) clicking Start > All Programs > Palm > SDK > Palm Emulator.

One thing I’ve noticed is that if you start Eclipse before starting the emulator, it throws errors and can have problems connection. So, start the emulator before Eclipse.

Sometimes you may also see an error when starting the Emulator stating that the Novacom service must be running.  To make sure it is, click Start > Settings > Control Panel > Administration Tools > Services.  Find the Palm Novacom service in the list, right click and choose start.

4. Launching the Application in Debug Mode

As you’ll pretty much always want to be viewing debug output from your application, start it in debug mode.  To do this:

• Click Run > Debug Configurations
• Right-Click “Mojo Application” and select “New”
• Choose your project in the “Project” drop down box.
• Choose the target to be “Palm Emulator”, or if you’re lucky enough to have a Palm Pre, choose Palm Device
• Make sure to check both the Inspectable and Mojo debugging checkboxes, and click Debug.

Looking at the emulator, your application should appear.

5. Logging

Debugging with WebOS is currently a pretty nasty affair, that requires a lot of command line wizardry, that I think only a tiny percentage of people will even attempt to use (if you’ve figured it out, well done!).

However, logging is relatively simple to set up, and that’s what I use.

As with developing web applications on Firefox, you can use the Firebug function console.log to print out messages, e.g.

console.log(“the value of the input is ” + event.target.value);

So, feel free to intersperse your code with whatever logging you like.

To view the logs, you need to log into the emulator/phone remotely using Putty, a SSH client.  Luckily this is included with the Palm SDK you installed earlier.

• Go to the bin folder in the SDK, probably in c:\program files\Palm\SDK\bin, and open putty.exe
• In Host Name, type localhost
• In Port, type 5522
• Save these settings for reuse later by typing in PalmEmulator into the Saved Settings box and clicking Save.
• Click Open.
• When Putty prompts you for a login name, type root
• When prompted for the password, just hit Enter, as the password is blank.
• Now start the logging application by typing log com.mydomain.myapp. If you’re unsure of what the correct string is, open the appinfo.json file at the root of your project in Eclipse, and the right string is specified as the id in that file.

Now, when you run your application, you’ll see your console.log calls being shown there.  It’s a bit verbose, and prepends a lot before your message, but at least it’s readable.

6. Using the Inspector

Palm includes the a DOM inspector with the SDK. Before running it, and after installing your application on the emulator using Eclipse, open a command window in the SDK’s bin folder, and type

palm-launch -d tcp -i com.mydomain.myapp

once again using the correct string for your application instead of com.mydomain.myapp

Now launch the inspector by clicking Start > Programs > Palm > SDK > Palm Inspector.  The Inspector window should now launch, and display the HTML of your application.

7. Write Something Cool

I’ll leave this as an exercise to you, the good reader.  However, you should now have the ability to log messages and inspect the content of your page, so you’re almost on par with the tools available for web development (a good debugger would be nicer though).

I might write some more posts in the future covering anything cool I found or wrote for the Pre.  I’m starting to use a specialized build of the Dojo Ajax toolkit to fill in some of the blanks that Palm’s Mojo toolkit leaves out, and that’ll probably require another post.

Have fun!

Massive TabContainer upgrade added to Dojo

I previously wrote about work I was doing on the Dojo Ajax Toolkit‘s TabContainer widget.  This work prevents the tab buttons from wrapping around when they are wider than the available space, and instead allows you to use either a drop down menu to select the tab (like Firefox/IE7), or to use left and right slider buttons to “slide” the buttons.

Well, thanks to some great collaboration with Dijit master Bill and a Dojo contributer called alle, the work has now been committed to the code base.  It should be available to view HERE from Aug 12th 2009 onwards, and will be in v1.4 when it is released.

If you can’t wait for it, you can either download a copy of the nightly code base from http://archive.dojotoolkit.org/nightly after Aug 12th, or checkout the code yourself from Subversion right now.  Note that code in between releases is not guaranteed to be stable, as many features may be in the middle of upgrades.

There are a couple of issues remaining to be worked on, such as improved right-to-left support, but for people who have been clamouring for this to make it into the code base, you can grab this now, and get the upgraded, more stable widget in v1.4

Cool Portlets added to Dojo!

Last week I put the finishing touches my Portlets for the Dojo Ajax Toolkit.  You can see them now on the test page at http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/widget/tests/test_PortletInGridContainer.html (it can take a while to load since it loads a hell of a lot of widgets and the code is not optimized with a build).

To see a description of what they can do, see my original post announcing them at https://shaneosullivan.wordpress.com/2009/03/11/cool-portlets-in-dojo

As a brief description, Portlets are widgets that represent individual applications used in a web portal.  They can be rearranged by dragging and dropping them around the page, and can often be customised with a number of settings.

The Dojo Portlets, in the dojox.widget project, support some useful features like:

• Customisable settings widgets, for setting user defined options.
• Loading Atom and RSS feeds to display as a list

and a good bit more.  See my previous post for a full description, or check out the test page.

Below you can see the Portlets using the blue Soria theme from Dojo.  There will probably be some small changes to the look and feel before v1.4 is released, but nothing major.  Note the different types of Portlets, from the Atom & RSS feed portlets on the left that can show more detail using tooltips or expandable secrions, to portlets containing generic widgets like a slideshow on the right.

Have fun!