A Trifle Absurd

It was inevitable, I suppose…

Someone’s gone and implemented a simple Unix-like system—wait for it—in JavaScript. The coolest (and/or most disturbing) part is the working implementation of vi.

Makes me think we need a new instance of Zawinski’s Law for software platforms, something like: “Every platform attempts to expand until it can run Unix…”

Without the X

The “Ajax” moniker seems to be catching hold, and I don’t mind too much—it’s nice to have a name for it. As others have already pointed out, though, the “X” (for XML) is a misnomer. Many Ajax applications (e.g. GMail) don’t use XML for their back channel. If you send data as JavaScript, then a simple eval() does all the parsing work on the receiving side.

I’ve bootstrapped Trifle as a simple read-only tagbase browser. The client receives data as JavaScript, which works great. Now I need to handle the other direction: JavaScript code posting updates to the server. But whatever code is running on the server, it probably won’t be JavaScript, so sending data in JavaScript form is pointless.

I could try to get sneaky and take advantage of the extreme similarity of JavaScript and Python data notation: lists, dictionaries, strings, and numbers have almost identical syntax. That would inevitably bite back, though, especially the “almost”.

So what other format would be easy for JavaScript to generate and for your average text-munging language to parse? Yes, there’s XML, but the DOM (for generating it) isn’t what I’d call convenient. Maybe a simple line-based text format will fit the bill. A general “verb url data” syntax could cover everything I need.

And no, it’s not like I’m abandoning XML. I’ll eventually extend the server side of Trifle to accept and generate XML, so that it plays well with others. For direct server-to-JavaScript-client communication, though, XML doesn’t cut it in this case.

Bookmarkability

Modern-day web applications are hard to make bookmarkable. If you’re using script trickery behind the scenes to get new data without reloading the page, the page updates—but the address bar doesn’t. Bookmarking the ‘new’ page will grab the address of the old page instead.

Some apps, like GMail, just ignore the problem, and thus prevent deep linking. Google Maps uses a workaround: a link on the page itself that gives you a bookmarkable version of the current page. But can we do better?

There is a way to change the URL in the address bar without causing a reload: just set location.hash. The value is tacked on to the displayed URL (plus a ‘#’, of course), and gets saved in bookmarks. When a bookmark is used, that part of the URL isn’t sent to the server, but we’re assuming a script-heavy web application anyway: just check for the location.hash value in an onload handler.

There’s a snag, though. If the user is already at “http://your/url/#foo” and navigates to “http://your/url/#bar” (via another bookmark, for instance), the browser won’t tell you about the change. Other than fantasizing about an onhashchange event, there’s not much you can do about it. Well, you can use setInterval() to poll location.hash for changes, but you’re stuck between having a long gap between checks—and therefore slow update performance—or slowing things down with frequent checks.

So is there no good solution for web-app bookmarkability? Not that I’ve found.

Open-Source JavaScript

A DHTML application’s source code is immediately visible to anyone who cares to look. You can keep it proprietary, but you can’t keep it secret. So why have there been so few open-source JavaScript libraries? Up till now, few apps have had a large enough chunk of code in JavaScript to justify splitting something out as a library. But as interest grows in rich JavaScript-based applications (a.k.a. Ajax, a name I’m not too fond of) and the average code size grows, we should see more libraries.

TrimPath is a relatively new umbrella project for just that. It currently houses three projects: a client-side templating library, a DSL for SQL-esque queries, and a spreadsheet engine. Steve Yen is the instigator and author of these projects; he has a blog on the TrimPath site.

Good stuff, and we need more of it. Which, in the open-source world, means that I should be doing more of it. Okay, I’m off to program.