Arcadian Visions

Don Box provides an amusing summary of XML vs. JSON that serves as a good back-cover to the recent iteration of this particular pointless debate.

What I find interesting about this is that none of these features that justifiably frustrate reasonable users of XML are required. You can happily use XML as a format for yourself without cluttering it up with any of this cruft. The phenomenon, in fact, is that seeing an ugly, inelegant usage of the technology actually dissuades people from using it in a simpler way.

The same effect can be seen in many of the Ruby on Rails vs. Java debates for building websites. While RoR has many merits, some of the arguments against Java highlight specific examples of Java usage as evidence against its worthiness as a language. Clearly, drawing such conclusions is unfair, but it is consistent with the way of the world in other matters. Consider, for example, companies not wanting their brand associated with anything they deem as inappropriate, or negative. That the same brand management is important to technology, with it’s ostensible attendant objectivism, is surprising. Perhaps the best way to kill a technology you don’t like is to use it in the construction of a notably unpleasant program.

Anthony JavaScript, Programming, Software Design

A wonderful feature of Lisp, or Scheme, is the way that the code is written as a data structure… or is it that data structures are written as code? Either way, there is not only the opportunity for fancy procedural generation and modification of program code via data structure manipulation, there is also an attendant sense of peace in the grammar of the language. I have been playing with a Ruby version of this concept on-and-off recently, yielding quite hack-ish results of dubious utility, but this idea is also relevant to last week’s discussion of JSON vs. XML.

Dare made a series of posts on the topic that everyone interested should probably read since they, and the comments they generated, cover so much of the relevant territory, but I’d like to focus on this post in particular since I think it provides the best overview of the issue.

Dare links to a post by David Megginson that compares the data exchange syntax of JSON, XML, and Lisp, but dismisses it as being irrelevant to why some people are choosing JSON over XML. I think he’s right, but I also think the syntax comparison is helpful. The key insight into the syntax is that JSON is indeed simpler to both write and visually parse for simple data structures, but that XML’s explicitness, particularly with close tags, is actually helpful when composing documents. Trying to write Lisp code without an editor that helps match up closing parentheses is an exercise in needless frustration, and I’ve seen countless C-style programs that include comments next to each closing brace to indicate the block that they are closing. Such helpers indicate a possible deficiency of clarity in the syntax of the language, and XML addresses this by naming close tags. The conclusion of the post is that all three languages are equally expressive in terms of functionality, and that syntax differences shouldn’t be a significant issue in deciding which to use for data exchange.

I think the comparison of the syntaxes is actually fairly interesting, but let’s return to the issue of JSON’s popularity. I don’t think string encoding issues are paramount on many people’s minds (both JSON and XML can happily be used on an internal project without thinking about this at all) with the reach of UTF-8 and UTF-16, and so-called on-demand usage (i.e. hack the DOM to get around browser security) is almost a wash since it has nothing to do with the data exchange syntax. The issue really seems to boil down to parsing and usage. For many people, JSON parsing consists of var data = eval(myJSON); while XML parsing is automatic as long as one doesn’t mind DOM as the usage mechanism. That’s really it. If you’re using a library that parses XML and returns a JavaScript object, do you care what the wire format was?

If we agree that evaluating executable code from a third party is a risky activity, then, even with JSON, we are forced to use a parsing library. At that point, what have we gained by using JSON over XML?

XML arguably has a lot of design warts in its sometimes confusing way of handling namespaces, potential string encoding complexity, and prototypical verbosity. However one can, perhaps improperly, use XML in such a way that avoids these issues. But the DOM APIs remain, glowering down on the lowly programmer trying to send a data structure that maps to 3 lines of text, but must be accessed by DOM API calls that nobody unfamiliar with DOM could guess. I think that is really the entire issue here.

Footnote: E4X may revive web developer enthusiasm around XML due to its support in ActionScript (and thereby Tamarin, thereby Firefox). The holdup here, if there is one, will be caused by IE’s lack of support for E4X.

Anthony JavaScript, Programming

Adobe is making some real noise on the platform front. I have written about the Apollo project, and now we have the announcement that Adobe will be providing key elements of Mozilla’s JavaScript runtime as part of the Tamarin project. Specifically, Adobe has a JIT compiler that will take ECMAScript bytecode and emit native instructions, supposedly yielding up to a 10x speedup. Also in the offing is a new garbage collector, whose impact isn’t really clear yet. I am probably most interested in the interplay between the GC and DOM because there seems to be a lot of dirt hiding in that crevice.

Tamarin will find itself used in a variety of Adobe products, including, eventually (probably) Apollo, as well as Acrobat and Flash itself. For its part, Mozilla’s implementation of ECMAScript v4 will be Tamarin, so we will likely all be seeing the fruits of this cooperation as development progresses.

There are a lot of positives here: Mozilla is arguably the gravitational center of JavaScript development (meaningful nod to Opera, too), and Adobe is providing some great technology that has already been proven in the field by virtue of the role it plays in Flash 9. The combination of the two will yield great things.

And now the part where I express my reservations: The tension between JavaScript’s privileged place in today’s software industry and its future as a programming language is at risk of coming to a messy boil. JavaScript is a very interesting language, there are upsides, and there are downsides. All in all, I am fine with it. Yet it would be nowhere if it were not the required language for doing client-side web development. The browser has become a significant platform, and JavaScript in the browser + PHP on the server has become a very potent combination. In fact, it is arguably the easiest way to write simple client-server data retrieval applications.

So now we have a language that has legitimate prospects of its own, that owes its success to the browser, and is a key component of the browser. This is where the tension enters. During today’s IRC chat with Brendan Eich, the question of why Mozilla rejected Mono as their VM elicited the response that Mono is too big, and not focused on browsers. Makes sense if you’re worried about Firefox, but is this really what you want to hear if you’re thinking about the browser as your application platform? The same question can then be asked of ECMAScript 4.

There are a lot of VMs out there, and the debates about whether various projects should use one or another typically rage back and forth with convincing points made on each side, but the debate about the VM for ECMAScript 4 has a built-in ending: Adobe’s technology is tailored for the browser. Good point. Eich says that Mozilla as a platform is strengthened by its focus on enabling Firefox the application (among others). This is a sensible approach for developing and testing functionality, but not for determining the extents of your technology’s reach. I fear that decisions made to make Firefox the best browser may cause the platform to languish, and the language with it.

The giant opportunity for everyone else: Provide an environment that makes client-server “AJAXy” applications dead-simple to write, while not worrying about shipping a lightweight web browser.

Anthony JavaScript, Mozilla, Programming

The video demos of Scrybe are, justifiably, getting a lot of hype. The application looks fantastic, and makes you wonder why smooth, swooshy UIs have been waiting for JavaScript and web browsers. It’s the sort of thing you might have started to do for an old-school desktop app, but then found that:

1. It’s a lot of work writing custom controls and animations for everything.
2. The performance hit just wasn’t worth it.
3. Breaking from UI conventions made users more confused and angry than captivated.

So how is it that these these seemingly fatal stumbling blocks have been removed by using a misnamed language as part of a slower software platform inside of a desktop application that does try to conform to UI conventions?

I have no completely satisfying answer to item 3, but it’s possible that greater mainstream familiarity with computer usage is giving interface designers some much-needed freedom. It’s also possible that smooth, swooshy UIs won’t seriously catch on. The reality is of course a combination of the two: competence with standard UIs turns to boredom after a while (people like new things sometimes), and tomorrow’s UIs will include the good swooshy from today’s experiments but leave behind the bad swooshy.

The first two items, however, I think are very interesting (I am just going to focus on the UI for the moment). There is a huge aspect of software as a service being more convenient for everyone involved, largely due to free distribution and invisible updates in this case. You can try experiments much more easily than with traditional retail software, and you can fix what’s not working without some ridiculous recall (note that a “recall” in the software industry typically takes the form of a paid upgrade version). What I wonder, though, is whether or not the proliferation of exciting (?) new UI concepts in web-based apps is in part due to the development platform. More specifically, the web has emphasized a separation of data, from style, from logic. It has also emphasized dynamic languages with garbage collection. None of these are new things (nothing ever is), but the web has perhaps beaten on these concepts sufficiently to make them part of everyone’s daily life. Maybe JavaScript, CSS, XHTML, ActionScript, etc., for all their warts, really are better than what we’ve been using.

In fact, it does make a bit of sense the way things have gone. It’s easier to make a browser than an OS, so we can think of the browser as an experimental OS with horrible performance. The browser actually provides an OSAL (Operating System Abstraction Layer) that application developers can build on top of, relegating the operating system itself to yet another commodity component of a computer. The interesting question moving forward is what the big players on the desktop are going to do. Maybe it’s time to say that if your desktop application programming model is C/C++ then you need to be on the lookout for new technology. Microsoft made a move in the right direction with .NET. Garbage collection and managed code are good things, and Linux is getting some of this benefit through Mono. Apple hasn’t changed their stance for quite a while, so seems to be a little bit left behind at the moment (nothing against Cocoa, it’s just lost some of its new-framework sheen). The big question on my mind is this: who will be the first to support a modern, dynamic language as a first-class application development language?

I know you can do various things with various languages today, but I’m looking for a bigger commitment. Microsoft’s hiring of John Lam seems like a move in this direction, and I’m still not sure what Apple’s up to on this front, but I sure am excited to see what happens next.

Anthony JavaScript, Software, Software Design

JavaScript is a fascinating language. Not entirely by its virtues as a programming language, but mainly by its integration with web browsers. It seems to be an accident of fate that the keys to the kingdom fell into the lap of this little language, but it is extremely heartening to see the Mozilla developers push the little language that could up the hill of respectability. Hey, if we’re all going to have to use one language, it may as well be a good one. I am referring to the vaguely recent release of JavaScript 1.7 as featured in FireFox 2.0. I encourage all developers, who haven’t already, to take a look at the list of what’s new. Some really fantastic stuff there, and if you build your own SpiderMonkey you can run a program like this (with the switch -v 170),

from the command line and get the expected output of

Michael Mann's "Heat" is pretty good
Wes Anderson's "Bottle Rocket" is pretty good
Robert Rodriguez's "Desperado" is pretty good

Nothing substantive here, but just a hearty congratulations to the Mozilla devs who worked on this.

Anthony JavaScript, Programming, Software Releases