Archive for January, 2007

* HTML Rendering Pains

Posted on January 30th, 2007 by Dave Johnson. Filed under AJAX, Benchmark, Grid, JavaScript, RIA.


We had a recent project where a client was trying to render 150 columns and 100 rows in a Nitobi Grid. Now, to most people, this sort of use case may seem very strange, but in reality, rendering thousands of cells in a rich user interface is a regular occurance with our sort of customers. Due to these extreme requires of our users, for the most part I am _very_ happy we chose to implement our data rendering engine with XSLT rather than standard string building :)
However, this time we hit the wall and the application was dog slow. Even though we were using very fast XSLT to generate HTML from XML data which was then inserted into the document, we still ran into a big bottleneck using the HTMLElement.innerHTML property. The HTML structure was not that complicated to begin with. It was just some floated DIVs that made up the Grid rows / cells anas I started by just removing attributes until we got to the bare bones of the structure. Even then there were problems and the structure had to be changed completely.

In the end it was due to a mixture of three problems. Here is what we did to fix things:

  • Shortening the element IDs. With longer ID attributes on the HTML elements the browser was having a hard time processing them. This sped things up a little bit.
  • Used TABLEs elements for the structure. Changing from DIVs to TABLEs made a dramatic improvement of over one order of magnitude. The floated DIVs require a lot more processing on the part of the browser so that makes sense.
  • Removed inline events. Having inline events such as mouseover and mouseout specified on the HTML element was a bad idea. If we had tried to attach all the events through script we would have seen the same problem I am sure. The solution there was to assign more general event handlers higher up in the DOM hierarchy and let the events bubble up to a single handler. This improved the performance by almost another order of magnitude.

Things like the styling, number of classes or any additional custom attributes had pretty much no effect on the performance.

.



* Ajax Deleting

Posted on January 25th, 2007 by Dave Johnson. Filed under AJAX, DHTML, JavaScript, Web, Web2.0.


The topic of this post is about deletion using Ajax. Truth be told, it’s not really even about Ajax but about the deletion pattern and related user experience in general.

So often it is the case that when a person deletes some data - like a photo tag in Flickr for example - the application insists on confirming that the user really wants to delete the item. This kind of interaction is really annoying when you are deleting several items from a list or even just one when you are a “power user”. In fact, more often than not, the user wants the delete to occur immediately and requires no confirmation. The confirmation dialog is just an over-engineered catch all for those rare cases when the user presses the delete button in error. In the case of Flickr photo tags then who even cares if you accidentally delete one tag?

There are a few good options for Ajax delete that I think one consider when building data intensive web applications.

  • Make the delete button smaller but communicate its meaning more clearly.
    Using large and unfamiliar buttons for signifying a delete action makes it easier for a person to make a mistake - thus re-inforcing the need for a confirmation dialog. A smaller button means the user has to work a little harder to perform the delete operation, but not quite as hard as confirming the delete, and the more clear the button is for deleting (through a tooltip or whatever) then the fewer inadvertent deletes there will be.
  • Store all deleted data the client before executing the deletes.
    Although it could be a good option, the previous suggestion still provided no way to undo a delete. To that end, rather than having a difficult confirm dialogue the developer can take a different approach to deletions such as batch deletions with a single confirm dialogue or even an easy way to roll back the deletes if they are in error. I imagine the reason for using a confirm dialogue is because it is easiest for the developer, but certainly not the user.
  • Use a timer on the delete action giving the user the opportunity to cancel the delete.
    Finally, an approach that could encompass both of the previous suggestions would be a delete timer. This would be an animation to indicate that the item is pending a delete in say 5 seconds. The key here is that this is ample time for the user to cancel the delete if they want but otherwise the deletion will continue if the user does not take any action to prevent the delete from happening.

At any rate, this is one area where most web application fail miserably and there are great advances to be made with Ajax based applications.

.



* Update - Complete UI Alpha Release

Posted on January 15th, 2007 by Dave Johnson. Filed under AJAX, JavaScript, Nitobi.


It has been a very long weekend but I think we will manage to get something out the door later today! It will likely include fairly basic documentation, as well as a single sample for the Fisheye menu, Tree, TabStrip and the Framework, and of course the code itself. We didn’t quite manage to get the docs all dialed (that one was my fault) but there are a few things that I am pretty excited about.

  • The first thing is that we finally have a cross platform installer - w00t!
  • The second thing is that the Framework is pretty awesome - and by awesome I mean, like, totally sweet. There should be at least one sample with some nice stuff particularly to do with making your own widgets using a declarative approach and all the goodness that comes along with that.
  • Finally, I am stoked on the fact that for the enterprise customers we will be providing much better code management tools - i.e. build, compression, deployment type stuff.

I will be getting some of the exclusive alpha stuff up on the blog over the coming week, hopefully even some screencasts or video.

I know that some of these things have been a while coming but everyone is working extra hard to get this stuff out there and we are hoping to see a good discussion going on over on the alpha release mailing list!

.



* Internet Explorer Standards Mode

Posted on January 12th, 2007 by Dave Johnson. Filed under CSS, DHTML, InternetExplorer, Web.


I love Internet Explorer. Today we discovered that in IE7 CSS pseudo classes like li:hover work fine in standards mode but not in quirks mode. What on earth were they smoking when they decided to add functionality to standards mode and not quirks mode? w00t!

.



* XML vs JSON: A Second Sober Look

Posted on January 8th, 2007 by Dave Johnson. Filed under AJAX, Declarative Programming, Performance, XML, XSLT, markup.


There has been a recent fleury of discussion about XML vs JSON. What a great topic for the holidays.

Although I have been talking about this topic for some time, some XML bloggers have recently started to discuss the topic (Tim Bray, Don Box, David Megginson, Dare Obsanjo and all the comments). For the most part the discussion is pretty tame and nothing really new.

Tim brings up the good points about extensibility and encoding. He also importantly acknowledges the fact that JSON is applicable in certain cases. To his points I would add the fact that one is able to use XPath with XML making it very powerful for quickly finding data. XPath is one XML technology that many ignore, particularly in the JavaScript sandbox.

The other important points are really in direct response to Dare Obsanjo’s posts from last week: Browser Security Model and Browser Programming Model. First of all, Dare suggests that one reason for JSON being so popular is due to cross-domain JSON (also called JSONP or JSON with Padding). Ignoring the data format, this pattern is applicable to any kind of data, including XML (XML with Padding is equally valid). There is no reason that Yahoo! could not provide a cross-domain XML API along side a cross-domain JSON API. In fact, I urge people to email everyone they know over at Yahoo! to do so for all their properties such as del.icio.us.

There are also a few points I have in response to the second post about the difference between the programming models of JSON and XML. The main thing that I noticed is that the example presents is not a realistic use case. What is most commonly done with data in an Ajax application is that the data is rendered to HTML. The fastest way to render data to HTML is using XML and XSLT. The other thing that he does not look at is cases where the data needs to be sorted or filtered, in which case XML and either XSLT or XPath provide a very nice solution. Of less importance, Dare also states that one should use a JSON parser in case of security concerns, however, the JavaScript based JSON parsers that I have used have had very extremely poor performance - even worse than plain eval().

The other interesting thing was a comment made by Kevin Hackman from TIBCO in the Ajaxian post. Kevin mentioned the fact that TIBCO uses XML to maintain the JavaScript state - i.e. each JavaScript object has a related XML document where the the object properties are stored and accessed using standard JavaScript accessor methods - which helps in terms of application memory usage. This is something that the soon to be released Nitobi Complete UI Framework also does, although for slightly different reasons like the fact that objects can then be easily serialized for use with server frameworks like JSF or ASP.NET.

At any rate, I am happy to see that some others are joining in on the discussion and if nothing else I hope that people start to talk more about using XSLT and XPath in the browser.

.