On the Unsanity website this week, a heated discussion broke out regarding some problems Leopard users were having with an older version of the company’s Application Enhancer (APE) module. What ensued both there and across the web–wherever those “blue screens of death” were discussed–was a revival of the ongoing argument about how “safe” APEs are. Most of the writers also bundled InputManagers and SIMBL (Simplified InputManager Bundle) plugins into the mix, which just pissed off the developers who know how different APEs are from those beasties. Meanwhile, developers of APE haxies and InputManagers have had to continuously address legitimate concerns about the security of their products and their impact on system stability, and so they’ve tended to become a bit defensive even in constructive arguments. I was so distressed by it all that I was moved to write the following lengthy entry on Unsanity’s forum. It turned out to be an article I’ve been meaning to write for a long time now, and for this Mars report I’ve spent some time cleaning it up and adding information to it. I hope it adds something mostly positive to the debate about the value of these kinds of system enhancements. At the very least–if you have the patience to wade through my overlong prose–you’ll be rewarded with a list of 30 “system enhancements” that I use (or have used), which try to explain why I find them so useful and necessary to my Mac Life.

Full article

Since my original report on the browser and platform compatibility of some 50 Ajax JavaScript libraries in March, the market has continued to produce new toolkits at a rapid pace. I recently finished grading all (but one) of the 8 libraries added since March, and I’ve revisited the scores of another 8. With that, the time seemed right for a report on how Ajax library developers are doing at achieving cross-browser, cross-platform compatibility in the tools they’re giving us–tools which programmers around the world are using to hammer out their unique vision of Web 2.0.

I’m very pleased to report that the trend is moving strongly toward full compatibility. Of the eight new libraries, a full five of them achieve top grades of “A”. That’s a much higher percentage of the total than in March, and of the three non-A libraries, only one was a D (D+ actually). One was graded C+ and the other B. Of the revisited libraries, I was able to raise grades for three–Backbase, ICEfaces, and MochiKit. Only one library had a lower grade (Rico, down from A- to B), and the rest were unchanged.

Only two of the 8 new libraries have commercial licenses you’d have to pay for, and in one case you are really only paying for the IDE. Three of the new libraries require a java server architecture in order to be happy, one would prefer Cold Fusion, and the others are pure client libraries that are agnostic with respect to the application server. One library was added just a couple of days ago (Jitsu), and I haven’t had time to review it yet–but you’ll find it summarized here with the rest. Only one of these 16 libraries is DHTML with no Ajax controls–Uize. Even without Ajax, however, I think you’ll find Uize to be one of the most interesting here–especially in terms of visual richness.

Full article

As I mentioned in an earlier post, the whole Ajax/Web 2.0 thing that’s happened this last year reminds me vividly of the mid-1990’s. Back then, the web was brand new, it was exciting, everyone was learning how to build web applications, developers were totally turned on and creative, everybody was pointing out cool new apps and sites, and the potential of this new computing platform seemed unlimited. Leading the charge was a young company that built software for every operating system under the sun, and they clearly had a solid vision of where they were headed. During 1994-96, Netscape introduced one astonishing new client-side technology after another to what a web browser could do–tables, animated graphics, client-side imagemaps, frames, cookies (yes, these really were a vital improvement to the web client), and something they called Javascript.

Each of these technologies offered dramatic new ways of presenting information in a web browser, and developers who loved new gadgets glommed on to every advance, racing each other to see who could do the coolest things with these first. A lot of mistakes were made–a lot of really ugly eggs were hatched–but excitement and optimism were the buzz feelings. With Netscape in charge, you felt like you do when working as a protege with a master hacker: Does this guy ever stop pulling amazing tricks out of his sleeve?

One of the promises of Netscape’s vision was that the web–and, in particular, the web browser–could make one’s choice of operating system irrelevant. The web could level the computing playing field, since applications built for the web were applications for all, regardless of what OS you happened to prefer. What worked for NeXT, OS/2, Irix, Solaris, and Windows would also work just fine on Linux, Mac OS, Be OS, HP-UX, and BSD. The web browser could be the OS, and the only limiting factor in what you could do would be your hardware and connection speed. Microsoft’s lock on the computer desktop could be broken, and new competitors in operating systems and computers could unleash the full potential of the personal computer to improve our lives–both at work and at leisure.

Only, it didn’t quite turn out that way.

This article inventories the Ajax/DHTML toolkits now available and grades each from A to E on the degree to which they adhere to a cross-browser ideal. The good news is that if you want to build astonishing Web 2.0 applications in 2006, you’ve got a lot of fine Javascript libraries to choose from! And nearly all of the Grade A libraries are open-source, so you can build without shelling out a license fee for the privilege. The bad news is that some of the most prominent players in the field fall far short of that mark.

Full article