If you’ve been thinking about creating rich, flexible, client experiences in the browser, you’ll want to check out Scott Isaac’s excellent overview of what the Live team has been learning about their efforts.
One item caught my attention above the others. Scott describes how the team is transitioning from sending XML to the browser which is then parsed and translated into JavaScript structures which can be executed, to translating the XML into JavaScript on the server. In preliminary tests he sees a performance difference of over a magnitude. Great work around.
Why did I get a kick out of this part of the post? Well, the other day Bryan (you need to start blogging again Bryan!) came over for what amounted to a “technology day” for the two of us. We hashed over various new technologies–dabbled in Carbon and Cocoa development on the Dual Core iMac, walked through a couple dozen XAML apps, explored WinFX, and I showed him the ropes with Visual Studio 2005. I guess you have to know Bryan to really appreciate this, but maybe I can help here. You see Bryan is tremendously bright and I have tremendous respect for his insights. In particular, his passion for understanding programming languages and building tools gives him a perspective that I learn a lot from. He’s also a contrarian and a bit of a crumudgeon–in a good way. He’s been authoring code for almost 30 years now–almost all of it targeted to “micro-computers” and he’s seen a lot. To put it his way, he’s seen a lot of the same mistakes made over and over again, and quite frankly it discourages him. That’s why he was so interested in walking through all these new acronyms and apps with me the other day. He wanted to assess these new techs for himself.
Anyway, back to the XML-to-JavaScript performance issue. One of the areas where Bryan’s been insisting for years that things went astray is with the language (or should we say languages) employed in browsers. He’s not impressed with HTML, JavaScript, nor XML. None of them. Why? Because he doesn’t see the gain over what they could have achieved if they’d employed some existing languages, such as Lisp or some other declarative-like language. Instead, he argues, they went off and created their own incomplete languages that are now being patched together.
Bryan would have much rather seen XML sidestepped, for instance, and something like Lisp chosen instead. Why? Lisp would not only give developers the power to represent their content, but also the power to manipulate it. HTML falls into the same category. Well, and JavaScript, CSS, XSL, and on and on are patches for some fundamentally poor choices that were made, he argues.
In his mind, he reconstructs the decisions that were made at the time this way: “We only need to do X. So let’s build a simple language that’ll do that just that. We don’t need anything more.” Statements like this will raise Bryan’s eyebrow. He’ll explain to you how that’s what you say today, but if your technology succeeds you’ll have to design for scalability now. Even if you choose to not implement everything in the language today, you have to design the language so that it can scale. If you don’t, you’ll wind up with….well….HTML, XML, JavaScript, CSS, and on and on. To him, someone saying “We’ll never need such-and-such” in a language is a red flag. He doesn’t buy it.
Of course, he knows that sometimes changing the representation of a problem a little can help to solve not the whole problem set, but a portion of it. And so he does see how these technologies have been leveraged in some creative ways to get things done. But, Bryan being Bryan, can’t help imagine what could have been.
There’s another “of course” here too. It helps a lot if you can see into the future and imagine how a technology being designed today will be used tomorrow. Yeah, it can’t be done. The best approach is to “be like a banker” and assess things based on what’s happened in the past. And to Bryan the banker’s choice would have been to constuct the Web with a more complete language.
Oh, and Bryan would all couch this with one big caveat–just to make sure you don’t make any hasty decisions: A language–or anything for that matter–that’s too general becomes, well, not so useful. There’s a balance that has to be achieved here. To me, time will tell if the choices were good.
And this takes me back to what Scott was discussing, about pre-translating XML into JavaScript. It’s rather interesting to see here what’s going on. Maybe XML is the best way to represent a problem (and manipulate it) and maybe JavaScript is the best way to glue page content together with and for the user, but it’s interesting to contemplate what could happen if XML had the expressive power to manipulate itself or JavaScript structures could become declaratively friendly enough to become a static representation of choice.
Personally, I don’t mind having more than a hammer, hacksaw, and a screwdriver in my toolbelt–if I can get things done that I want to do–but I do agree with Bryan that the right tool can make all the difference.