Book Review: Foundations of Ajax, Asleton and Schutta, Apress

Summary: friendly enough introduction, but could have been much better

This is a rather unambitious book. It's fairly good at what it tries to do, but it doesn't try to do very much. While Manning's Ajax in Action tackles the subject from the standpoint of engineering desktop-replacement applications, Foundations is content to talk about Ajax as a means of adding small-scale usability enhancements to a web application you're already building. Likewise, they assume you already know all you need to know about whatever HTML and about web development platform you're using, and just need to sprinkle some Ajaxy goodness on your site.

Of course, there's nothing wrong with that. And I have little doubt that there are a lot more people looking to use Ajax to spruce up an existing site or application than looking to build major web-based applications. And lots of those people will already know other aspects of web development and not need a rehash. For these sorts of developers, books like this one will fill an important niche. And Foundations has a lot to recommend it. It's well written and edited, and it has a friendly learning curve. It also covers building a toolset for working effectively with JavaScript, including such useful tools as JavaDoc, JsUnit, GreaseMonkey, and Venkman.

The main way in which this book shoots too low is by providing its straightforward examples only for Java on the server side. For a book that clocks in a thin 273 pages, it surely would have been easy to take the 50 pages of Java examples in chapter 4 and provide parallel chapters that implement the same examples in, say, PHP and ASP.Net. If the authors had merely done that, I would have absolutely no hesitation in recommending this book to Ajax newcomers. As it is, I can't help thinking that this book should be called Foundations of Ajax in JavaScript and Java. And since only the simplest of examples (the ones without any server-side interaction) will work on other platforms, this book will be completely useless to a large portion of its target audience. What a shame.

Tags: AJAX, JavaScript, book review

Initial impressions of Seamonkey 1.0 and Composer

I noticed yesterday that Mozilla SeaMonkey hit 1.0 a few days ago, so I decided to check it out and see if it works any better than I remember the old Suite working. If you don't know, SeaMonkey is the volunteer effort to keep what's left of the old Mozilla Suite alive, with an integrated client for email, browsing, and HTML editing. It was abandoned by the Mozilla organization in favor of Firefox (and Thunderbird as an email client).

When I last used Suite (which was a while ago, certainly), it was sluggish, visually ugly, and generally hard to recommend, even over IE6, but I was still curious to see how things were going with it these days. I don't have any use for a desktop email client -- I use webmail, except at work where I have Outlook -- so I'm not really interested in the integrated email/browser aspect of SeaMonkey. But it would be nice to have a decent HTML editor, especially since I have a visceral dislike of FrontPage, and I suspect I won't like DreamWeaver much better.

I do my website development either in Visual Studio (for C#-based projects), or good old TextPad (for other stuff), and I can certainly do fine without a WYSIWYG editor. But sometimes it's nice to have that for simple things, especially if you can control what kind of HTML it emits.

So, anyway, I loaded it up. My first impression: man, that's ugly. It's still got the old Netscape 4 icons, which were ugly even back in the days of Netscape 4. So I switched to the Modern theme. Yikes. Even uglier. Fortunately, there was a menu item for Get New Themes, so I was able to root around in there.

Of course, most of the themes are for Firefox now, and most of the ones that aren't only for Firefox are either old, or simply haven't been updated for SeaMonkey 1.0 yet. What was available was either cheesy theme skins, like wood paneling, or variants of the "Modern" theme that weren't any better. Finally, after about an hour of this, I found a theme that looked pretty good, "Mostly Crystal," by CatThief. It was a close relative of the standard Mozilla theme, only the icons were kind of shiny with a glass look to them. Most importantly, they were interface compliant, and they weren't a massive eyesore.

So now I have an application that looks just fine. The only downside: if there's a way to switch it over to small icons, for the life of me, I can't find it. Oh, well.

Now to browse a little. Initial impression: just like Firefox. Which is just great by me. I like Firefox. More importantly, it's not sluggish, and everything seems to works just like I expect it to. Yay.

So I moved on to Composer, which is what I'm really interested in. Even better, there's a setting to make Composer start up instead of Navigator on startup. That's good, because if I'm going to use SeaMonkey for anything, it's going to be as an HTML editor.

The editor seems to work pretty well for most things. You can tell it to use styles instead of heinous HTML 3.2 artifacts like <font>. You can't tell it to use XHTML transitional, so you get old-style <br> tags that don't terminate themselves properly for XHTML, and a lot of <font>s. All the style information is inline with the tags, and it uses spans with styles in place of <strong> or <em>. Possibly most annoying, hitting enter after a paragraph of text inserts a <br>, and doesn't give you a new paragraph. For cases where you're picky about your HTML (i.e most professional work), these issues are probably a dealbreaker.

On the plus side, if you use <strong> tags correctly in the source view, they appear correctly in the WYSIWYG view. In fact, pretty much everything I tried in the source view came up correctly in the WYSIWYG view, including absolute positioning, separated styles, etc. So if you set up an XHTML template correctly, Composer might be a good way of entering text into it and seeing it render correctly -- though you'd still have the <br> issues.

Composer also gives you the ability to edit arbitrary text files (and, by extension, CSS files). SeaMonkey also comes with the Mozilla DOM Inspector and Venkman JavaScript debugger, both of which are fantastic tools. Though, honestly, all the Windows get unwieldy pretty quickly. Every HTML file you have open in Composer lives in its own window, and there isn't a site browser of any kind. Venkman runs in its own window. DOM Inspector runs in its own window (I couldn't get the sidebar version to work). Also, for debugging, Venkman binds to Navigator and not Composer, so you have to leave a Composer window open as well. That's a lot of windows to shuffle to do any real work, so it's not exactly an IDE.

Conclusion: in it's current state, Composer is a pretty usable ad hoc HTML editor for simple pages, but not something you can use as a production tool for a serious website. I'm going to keep it around and see if I end up using it for anything. The navigator portion of SeaMonkey seems like a good solid browser, but if there are advantages over Firefox, I didn't find them.

Another interesting note: in trying to find out more about the state of Composer, I discovered that there is a successor to Composer that has been under development as a standalone web IDE called NVU. It has a site management tools and it allows multiple HTML files to be edited in the same window using tabs. It has a CSS editor. It doesn't have JavaScript capabilities or integration with Venkman in the base package, but it's available as an extension. I'm going to play with it some, then I'll post another update on the subject.

Tags: browsers, Mozilla, SeaMonkey, Firefox, Composer, html editor

Another thought

Tags: blogging

Why isn't there a DOM for JavaScript?

I've been working a lot with JavaScript, along with all the other current web building blocks: XHTML, CSS, XmlHttpRequest, etc. And I've really grown to like the HTML DOM as a means of managing the display model for a web application. I've also grown to really like JavaScript, despite the somewhat annoying limitations imposed by trying to keep the size of your code and the number of files the code is in small.

Something I've started wondering about, though, is why there isn't something analogous to the DOM for managing JavaScript code itself. It's not so much a document, so I suppose I ought to call it a Code Object Model -- but given the confusing acronym that would result, let's just call it a Reflection Object Model (ROM). This is a lot like the kind of reflection you can do with Java or C#, of course, but with one important difference: everything important in JavaScript is dynamically bound, so you aren't limited to looking at your code, you can freely modify it.

Of course, JavaScript has reflection already, but it isn't very atomic or friendly to code-level manipulation. You can recover an entire function or replace it with a different one easily enough, but if you want to traverse inside the code, examine an internal variable, and revise it, you'll either have to use regular expressions or parse the code yourself.

What would be more useful is if there were an integrated model that you could use to traverse an operand-tree style model of the code. So your code might look something like this:

var fm = ROM.GetFunctionModel("myfunction");

// iterate through lines of code
foreach (var statement in fm.childNodes) {

   // find statements where the top-level operation is
   //   an assignment
   if (statement.operator && statement.operator ==
         ROM.Operator.Equals) {
      var eq = statement.operator;
   
      // find cases like a = b + c, where the right 
      //   side of the assignment is compound, as
      //   opposed to a = b cases;
      // also, only cases where the operation is addition
      if (eq.childNodes[1].isOperator() &&                   
            eq.childNodes[1] == ROM.Operator.Addition) {
         var add = eq.childNodes[1];

         // find cases where the right side of addition 
         //   operation is the number 2
         if (add.childNodes[1].isNumber() &&
               add.childNodes[1].literal == 2) {

            // replace the number 2 with the number 3
            var newElem = ROM.Number(3);
            add.replaceNode(add.childNodes[1], newElem);
         }
      }
   }
}

This hypothetical syntax probably isn't perfect, but it should give you a pretty good idea of what it would look like to manipulate code programmatically at runtime using a ROM.

By the same token, ROM would have a perfectly good code emitter, as well. Generate code using the ROM, then emit valid JavaScript into an easy-to-download, human-readable file. Statement objects could even have a comment attribute which would insert comments into the code appropriately.

I'll have more on this later.

Tags: JavaScript, reflection, Reflection Object Model, DOM