Archives

I’m as geeked about jQuery’s 1.3 release as the next developer. But I’m even more excited about the new API browser developed by Remy Sharp and available here.

For as long as I’ve been a jQuery user – going on 18 months now – I’ve been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we’ve got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it’s available as an Adobe AIR app for offline viewing. Sweet!

I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I’ll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery’s API, it’s a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.

jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.

Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous’s FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).

It has been a good run, but Ajax the buzzword will dip below the radar in 2009. That’s not to say that we’ll all stop writing JavaScript and using XHR in the coming year — quite the contrary. Full 100% of web applications will incorporate Ajax technologies, we just will use the “Ajax” buzzword less and less, much as “HTML” became just another acronymic noun in the early days of the web. So that’s not really controversial.

What’s really going to happen in 2009 that will impact all of us RIA developers? The first raft of Ajax-enable webapps will be undergoing maintenance. Supportability is the real test of frameworks, architectures and designs. How easy are they to support? How painful is the life of a maintenance programmer working on a Dojo codebase versus a JQuery codebase?

We’ve been emphasizing the use of application level MVC frameworks here of late.Why? Because we feel that the best and most sustainable metaphor for RIA’s is that of the desktop component GUI, not of the souped up webapp — client/server making its triumphant return. Without this guiding principle — that we are writing applications that consume backend services rather than backend services that display interfaces — we face escalating development and maintenance costs.

I hope then to see two front end web development trends for the coming year:

1. Abstraction away from the underlying browser platform. Widgets, components, whatever you call them; the average front end web developer shouldn’t have to tangle with the DOM or low-level browser events.
2. Adoption of application level MVC frameworks like PureMVC. A standard way of wiring up complex GUI’s will save us from ourselves. See Swing for a cautionary tale of woe.

What are you predictions for the coming year?

When you’re developing a desktop or GWT application you’re going to go through a bunch of iterations, tweaking the UI, adding components, etc. Sometimes in all of that work it is very tempting to take a shortcut and update a view directly from a controller (label.setText(model.messsageString)). That way lies madness. Before long you’ve got your view code strewn across the length and breadth of your application. Change the view or some aspect of the model and you’re on a refactoring of biblical proportions.

In fact there’s never a good time to break out of MVC, but sometimes you just don’t know what sort of Observable your model should be. Will you be using a table, a tree, some custom component? In those situations I try to preserve MVC while punting the hard decision until later. To this end, I’ve written a little set of utility classes called SimpleModel. How do you use SimpleModel?

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.

The culprit? jQuery’s less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.

If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries’ core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here’s a quick stab at how to trick out jQuery:

Many times open source projects are mute — they have insufficient documentation. Good technical blogs can function as a sort of ad-hoc documentation. That’s what I’ve tried to do, most recently with my series of posts on GWT and OpenSocial. Vinay, over at Web Technology I/O, often does the same. He’s got a great post about Ray Cromwell’s GwtQuery (JQuery-like syntax in GWT) and how to make it work.

I’ve been tinkering with this tool as well and am going to do my own writeup, but thought I’d give you all the heads up. BTW, according to Vinay, the compiled GWT JavaScript for GwtQuery clocks in at 712 bytes!! So much for GWT bloat.

Note: It is assumed that you know your way around GWT and Eclipse for purposes of this tutorial.

While developing OpenSocial applications can be a bit tricky, getting set up to develop can be a real pain in the neck. For this installment of OpenSocial and GWT, I’m going to go through the basics of setting up a simple Hello World gadget with iGoogle. We’ll get into the details of signing up for other OpenSocial containers, testing, and so on, later. Right now we’re just going to do the basics.

So, what do you need to build a Google Gadget with GWT for iGoogle? You need the following:

1. The Google Web Toolkit
2. The GWT Google Gadget API
3. An account on iGoogle
4. Access to the iGoogle sandbox
5. Some public server space so you can serve up your gadget to iGoogle

Whenever we have Flash versus DHTML discussions in the office, someone usually utters the words “you probably can’t do it, unless you used Canvas and some fancy JavaScript…”

At times that can seem like a cop out, an admission of defeat in the face of the Flash arsenal of graphic effects. Somtimes, like today, it seems more like a visionary declaration of the power of Canvas. Check out Steven Wittens’ use of Canvas for projective texturing. Maybe there is a little bit more coolness left in these Ajax bones.

It’s not quite done (the game notation looks like crap in IE), but I thought I’d give a taste of my latest labor of love, a chess game viewer in GWT. This is the sort of thing that is usually implemented as a Java Applet. A few others have already built chess viewers in GWT, but as they say in Full Metal Jacket, “this one is mine.”

As I blogged a few weeks ago, I ported the Java chess library ChessPresso into GWT, which was a blast and an example of how you can leverage existing Java libraries to write browser-based apps.

In the example, I’ve pulled the eleven games of the recently completed world championship between Anand and Kramnik in a single page. The GWT app identifies all of the relevant tags, reads the PGN (Portable Game Notation) in those tags, then inserts a game viewer widget into the page.

What isn’t working yet:

• Doesn’t look so good in IE (a little CSS work)
• The notation pane isn’t hooked in so you can click on a move and jump to the position

Anyhow, have a look and let me know what you think.

Update: OK, the notation panel is hooked up to allow clicking on moves to navigate aroung the game. Still looks like crap in IE, though.

Update: for those interested in some of my very few games that make me look good.

Update: Another set of tweaks to display a collection of games, one 41 games PGN chunk and a 250 or so chunk.

The JSON utility library for GWT that I blogged about last week is now up on google code.

To recap, the idea is that you can write code like this

JSONValue root = JSONParser.parse(json);
JSONWrapper obj = new JSONWrapper(root);
String result = obj.get("map").get(1).stringValue();

when dealing with JSONValue objects.

As it’s only one class, you could just include it in your source tree as code instead of using the jar.