My HTML in Scala Wishlist

One of my favorite features in Scala is its native support for XML(link warning, shameless plug.) I love the "projections DSL" (for lack of a better term) that is the scala.xml package. It is great for slicing up XML, and is almost like having native XPath and XQuery built into the language. Using XML in Scala for HTML generation is not as universally appealing to people. Some people think it encourages mixing presentation and business logic and is not "clean." I have even heard folks say that this is a critical flaw in Lift. I completely disagree. Of course I also think MVC is an anti-pattern, but anyways... HTML support in Scala is great in my opinion, but could be even better. Here is my wishlist.

• Better understanding HTML semantics. For example, it is great that the compiler won't let me do something like this <div>Hello world</di>. However, I would not want it to even let me do <di>Hello world</di>. Similarly I should not be able to stick a thead outside of a table. If I have an anchor tag with an href attribute, then I'd like the compiler to do some validation on the value. Am I asking for too much? Well, that's I'm supposed to do, right? Is some/all of this possible with the help of XML schema support? Maybe so.
• CSS. HTML without CSS ceased to exist a long time ago. With all of the DSL possibilities in Scala, is there some way to allow CSS literals and create some type safety for me. For example, I if I fat finger the name of a style on a class attribute, the compiler should catch this. Also I can say from experience that introducing an object-oriented model is really useful in CSS. Finally, the XPath/XQuery-like support in Scala XML makes me think that something similar could be done for CSS selectors.
• JavaScript. Honestly I don't know what I would want here. I like JavaScript, but I know the idea of being able to write your web application in a single language is very appealing to a lot of people. If nothing else, it would once again be nice if the compiler would prevent me from doing something like <button onclick="foo()" ...> if there as no function called "foo" in scope.
• Tooling. Most modern IDEs support things like syntax highlighting, code completion, error checking, code formatting for HTML and XML+schema. I expect at least this much for XML/HTML literals in Scala. I'd also like to be able to step through and debug literals. Refactoring on subtrees of XML (extract method for example) would be sweet. Oh, and large XML literals should not overwhelm my IDE :-)

Parsing XML on the Client: JavaScrpt vs. ActionScript

Developer: Wow the JavaScript interpreter on Firefox 3 is awesome, but the one on the new Safari is even better. It is a great time to be a JavaScript developer!

Me: It is still a lot slower than ActionScript.

Developer: Oh don't quote me old numbers, the new browsers are so much faster.

Me: Still slower than ActionScript.

Developer: Maybe slower at doing useless things like calculating prime numbers. Who would do that in a browser anyways? The new browsers are fast at doing realistic things.

Me: But still slower than ActionScript.

Developer: Show me some proof on something realistic, like parsing XML coming back from an Ajax call.

Me: [Whips together a servlet for producing huge chunks of XML and some JS and a SWF for calling it and doing a DOM parse.] Alright let's see the results of these tests...

Everything is O(N), as you would expect, and can verify by doing a linear regression of XML document size vs. parse time. Safari 4 is much faster than Firefox 3, the ratio of their slopes (FF3/S4) = 2.95. But they both lose badly to ActionScript 3 (running Flash Player 10, RC2), (FF3/AS3) = 6.36 and (S4/AS3) = 2.16. Maybe IE can do better, should we give it a try?

Developer: Now you are being a jerk.

New Scala Article

IBM published my first Scala article today. It's on using Scala to work with XML. It was a lot of fun to write about Scala. I am very lucky to get to share something that I enjoy. However, it was also a little challenging. It is so easy to be so terse with Scala that it seemed to carry over into my writing. I thought it would have the opposite effect, i.e. I would feel like I would need to write a lot more to describe what was going on with Scala code than I would with Java. Instead I had to really force myself to be descriptive about things. I would look at some of the code and just think: "the reader does not need me to explain that, it is so obvious." That is a testimony to Scala. Its handling of XML takes advantage of its DSL-friendly nature. A lot of complex and powerful expressions in Scala simply do exactly what they look like they should do. Or maybe its just my mathematical mind that sees things that way, who knows. Anyways, I have another article in the works for developerWorks that will cover Lift, a web framework developed with Scala.

Attributes vs. Elements

I was reading an article on developerWorks that I didn't write... It was about XML and Java. Sound like a tired, old subject? This had an interesting take: How the choices you make when writing XML influence your Java application code. One of the central themes was on using Attributes vs. Elements. One of the basic points was that using attributes leads to faster code. I decided to test this theory.

I took a pretty simple XML document. It was actually one that I had written recently for a real problem. I created two versions of the same document. One used elements exclusively. The other used attributes whenever it was possible. I then tested how fast it was to access two pieces of data. One was "shallow", i.e. near the root of the document. The other was heavily nested. In both examples, the data was an attribute in the attribute favored approach. I repeated the test over 10,000 iterations and tested it against three XML parsing technologies: the standard DOM implementation included with Java 6, using XPath with dom4j, and using the StAX implementation included with Java 6. For the DOM and dom4j techniques, I also examined the parsing time.

The results were a little surprising. I found no differences with attributes vs. elements for DOM. This was true for both traversing the tree and for parse time. I don't mean a negligible difference, I mean no difference at all. It was so surprising that I had to double check my code a few times. The big difference for DOM was that the code for the attribute favored approach was definitely simpler, which was one of the points in the developerWorks aritcle.

The dom4j story was different. It was slightly faster to parse the attribute document, but it was a bit faster to retrieve values on the element document. I was surprised by this, but the differences were very small, probably not statistically significant (I didn't test this, though.) The code was virtually identical, of course, since we were using XPath for the traversal. The dom4j was much slower than the DOM approach, which is again not too surprising.

Finally, the StAX tests showed faster results for the attributes document. There was a larger difference than in any of the other tests. This makes sense because you don't have to go as far in to the attributes document (a start element event contains the attribute data, but does not contain text child node) and there are less events fired in an attribute document vs. an elements document. For example, bar is three events, but is two events. Also, StAX was faster than either DOM or dom4j, as you would expect. The StAX code for the attributes document was also slightly simpler than it was for the elements document.

So if you're using DOM or StAX, you should definitely favor attributes over elements. It will be less code and in the StAX case, faster code. If you're running dom4j and XPath (or maybe XQuery) based navigation, then it doesn't matter as much and elements based seems ok. This really is important, as a lot of these "modern" RESTful web services are heavy on the elements format over the attributes format. This is doubly bad for web services, since there's obviously a much larger byte-cost on elements style documents.

Update: As request, I am attaching the source code I wrote for this little micro-bench. I tweaked it a little as I realized there was an inefficiency in one of my dom4j methods. This tweak made dom4j faster on the attributes document, which is more consistent with the rest of the results. To run the code, you need dom4j and you need either Java 6 or Java 5 plus a StAX implementation. I ran it on my MacBook under Java 5 using Sun's StAX parser.

New Articles on IBM

There's a couple of new articles that I wrote that are now available on IBM developerWorks:

The Geronimo renegade: Using integrated packages: Codehaus' Woodstox: This is an article all about Geronimo's StAX implementation, Woodstox. If you're an old veteran of XML parsing like I am, you have to love StAX. Woodstox is not only an excellent StAX implementation, it is a killer piece of software. We use it in a lot of places at eBay because it is so fast.

Use JavaScript to make your XForms more robust: This is a very cool article about mixing JavaScript and XForms together. XForms has become kind of a forgotten technology, which is a real shame. It has so much to offer. I think part of the reason it is forgotten is because people don't realize that it is standardized and integrated with other technologies. It plays nice. It's not some one-off technology that lets you do some cute things in a sandbox. This article shows how everything in the XForms world is accessible through JavaScript. It's not a read-only kind of access either. You can modify models and forms, etc. I'm planning on writing some more on XForms and how it integrates with a certain well known AJAX framework that is usually referred to as a three letter acronym...

JSON vs. XML

I recently was dragged into a JSON vs. XML debate. There are definitely some people out there with strong opinions on this matter. I'm not really one of them. However, most web developers I've worked with like how easy JSON is to work with. That's good enough for me. Plus, some of the typical pro-XML arguments are particularly disturbing to me:

1. XML has strong typing. That's great if you're doing some kind of B2B data/document exchange. Is it really well-suited for the web? Do you want to run a schema-validating XML parser inside a browser? If your server dishes up an XML doc, do you really want your browser to reject it?
2. XML is extensible. Being able to extend a schema and thus add to a document is great, but do you really want data objects that have a lot more information than is needed by your browser? Perhaps you'll want to wait until the net neutrality debate is over before you answer that...
3. XML allows your client and server to use the same data model. Again this sounds great, but there are big problems. First, it implies your server is storing everything (or a lot of things) as XML. You better have some really good reasons for doing this, as either your neglecting the considerable strengths of relational data storage or you're probably misusing it. Second, you're creating a strong coupling between the Models and Views in your system. I know this has become more popular as it is viewed as a tenet of "lightweight" development, but it is a design flaw. That doesn't mean you should never do it, just that it must be weighed against the positives that it would bring. In my experience, even when such tightly coupled systems work well at first, they become a nightmare on versions 1.1+

Again, it's not that I'm against XML on the browser... I'm just wary of some of the arguments for it. I think it is often a wash between the two technologies, which is why I say "so be it" when a web dev tells me they prefer JSON because it makes some of the programming easier.