DOMAssistant news – New plugins, TextMate bundle and ten times faster than the competitors in IE 8

A number of exciting things have been going on in the DOMAssistant camp, so I thought I’d fill you in with some of the latest. We’re talking plugins, developer tools and taking a glimpse into the future.

Plugin news

AJAXForms plugin

The first plugin has now been released, and it’s an AJAXForms plugin. It offers you a way to submit a form completely through AJAX without doing any postbacks of the entire page, and specifying what happens before the form is submitted, and how to handle the response.


DOMAssistant Team member Pelle has been working hard on creating plugins, and one of the more interesting ones is the DOMEffects plugin. It should appeal to all of you people who have been longing for those eye-candy things such as fades, animations etc.

The plugin is still in a beta phase, and Pelle would love to get some feedback about how it works, what syntax to use and so on. Please help him shape the future! πŸ™‚


Not being satisfied with the task of creating DOMEffects, Pelle has also put some time into the DOMValidator plugin, to use with forms to validate user input and such.

Same goes here: this one is in a beta phase too, although it has come a bit further than DOMEffects, and any feedback would be greatly appreciated.

TextMate bundle

Team member Roger looked into how developing with DOMAssistant can be made easier and even faster. The result of his work is a DOMAssistant TextMate bundle, and it also works in the Windows alternative E-TextEditor.

Ten times faster in IE 8

As you all probably are aware of, IE 8 beta has been released, and for me, one of the first thing I wanted to test was how well DOMAssistant performed with it.

You can imagine my surprise when I saw that DOMAssistant CSS selectors in IE 8 were ten times faster than its nearest competitor! This is only, of course, an indication of what the future might hold, but if the IE team delivers all the way, this might very well become a practical reality after the final release. πŸ™‚

DOMAssistant – use it

Naturally, you can see where all this is going; me and the team are very proud and happy with what’s happening with DOMAssistant, and we work very hard to create a good alternative for your development needs. So please, try it out and build fantastic things with it! πŸ™‚


  • Hi Robert, good stuff as usual.

    I have only one comment about one single piece of code …

    <code>/*@cc_on @*/

    /*@if (@_win32)

    if (document.getElementById) {

    // doStuff


    /*@end @*/</code>

    could you please avoid open + open / close or nested conditional comments?

    What I mean is that this should does exactly the same thing


    @if (@_win32)

    if (document.getElementById) {

    // doStuff


    @end @*/</code>

    but it makes life easier for both non-IE browsers, during comment parsing, and "minifiers" as well.

    Switching them I've successfully parsed the full file into 7.3 Kb, using service.

    I know you had problems as well, that conditional comment is not minified as expected even in your compressed version, while is able to minify conditional comments as well, there's javascript inside πŸ˜‰

    Your nested open without close case scenario is quite hard to understand correctly. However, did I say good stuff?

    Kind Regards

  • Robert Nyman says:


    Thank you!

    It is very interesting that you mention this, since I've considered it for some time (but never gotten around to testing it). The DOMReady function, as I'm sure you're aware of, is heavily influenced by the work of Dean Edwards and others with window.onload (again).

    My thinking has more been that they have tested it thoroughly and therefore have been a bit reluctant about changing things.

    But just as you say, the above code really should work, and if nothing goes wrong, I will include it in the next release of DOMAssistant (which will be out in a week or two, and have some nice things; stay tuned πŸ™‚ ).

    Regarding compression, I've been very happy with the mindset and result of YUI Compressor, although I'm sure is very competent. The minifying problem is still there, though, so well see if I will change it. πŸ™‚

  • dAN says:

    I somehow missed your DomAssistant lives post so I was delighted to hear this news after the low point of Why Bother

    DomAssistant rules!


  • Robert Nyman says:


    Thanks a lot! πŸ™‚

  • Hey, congrats Robert!

    The IE8 bit in particular is very good news πŸ™‚

  • […] Robert Nyman today wrote about my plugins as well as about some other exciting DOMAssistant news – like Roger’s new TextMate bundle – […]

  • Regarding compression, I’ve been very happy with the mindset and result of YUI Compressor, although I’m sure is very competent. The minifying problem is still there, though, so well see if I will change it.

    I do not use YUI Compressor, but if this does not do nothing with conditional comments (too simple in this way, guys :D), it means that packed it could produce more compact code, for the simple reason that @cc_on contains JavaScript, the same javascript that could be minified outside the comment.

    I would like to mantain this feature, since CC are widely used and with 3 IE box models (8, 7, 5.5 or whatever is it), libraires.Next will use them more each new release ( IMO πŸ™‚ )

    P.S. … ooops, does YUI Compressor use Rhino and does not Rhino is compatible with IE cc_on code? … he, he, he πŸ˜‰

  • Could you please change all instances of

    @if (@_win32)


    @if (@_win32 | @_win64)

    to provide Windows 64 bit support?

  • Robert Nyman says:


    Thank you!


    Ha ha! Well, yes, I do think it's very important to support Conditional Compilation as well. If it isnt fixed, I might consider testing another compression method.

    Out of curiosity, how does stand against Dean Edward's Packer?


    That is changed since a couple of weeks, and will be in the next upcoming release, since 64-bit support should of course also be in there.

  • has nothing to do with both Dean's Packer and Douglas JSMin … but obviously it's inspired by both projects.

    The minifier does not use regexp, it's a char by char parser more compatible than JSMin (function(){return /re/;} is an example of one of JSMin problems) .

    The client compression is an optional, but in this case, the algo to decompress the code is so simple, and for this reason widely compatible (more than one developer told me that successfully parsed files that Dean's packer was not able to do).

    However, this is totally different from Dean's one, and I think his algo is able to create more compact results (I focused more on compatibility with "strange" code) … anyway, what's can do, and no other compressors can yet, is to produce a single file merging both JS and CSS that will use the same keywords list (think about div.classname {} in CSS and the usage of "div" or div and getElementsByClassName("className") in JS … these words are both from a single list).

    This simply means than in a single file you can serve entire libraries and their dedicated CSS, while JS not comaptible or disable browsers will download only one or more basic CSS (try to disable JS in and look what do you download when you have JS enabled and what's different when JS is disabled).

    Sorry Robert, I know this is not the right place to talk about … but hey, it was your fault, you asked? I replied πŸ™‚

  • Robert Nyman says:


    No problem; on the contrary, I did want to know more! πŸ™‚

    Thanks for the explanation, it sounds great!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.