Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

<a href="blah..." onclick="return DoAction();">Link</a>

...

function DoAction() { /*Do Something */ return false; };

However, there’s a better way, using the event.preventDefault() method. I had the need to use this recently, when I was fixing a trivial issue with the Filament Group jQuery UI buttons – my ‘a href’ styled buttons were still clickable when they were disabled. An easy solution to this problem is to capture the click and prevent the default action. I hooked this action to all disabled buttons, as such.

$(".ui-state-disabled").click(function(event) { event.preventDefault(); });

This code isn’t that robust – if you were to add or remove the ui-state-disabled class after page load (which I didn’t have to), you’d want to make sure to handle it appropriately. Either way, preventDefault() is definitely an elegant solution to disabling a click action.

Here’s a GeoLocator example I put together that showcases two popular GeoLocation techniques – IP lookup and using the GeoLocation API – in order to both demonstrate the techniques as well as to show the issues with each.

In HTML, there are a few ways of determining the location of a user. Traditionally, this has always been accomplished by IP lookup – a lookup is performed with your IP against a database of known IP locations. This technique leaves a lot to be desired, but it’s been all that’s been available for a very long time.

In HTML5, however, there’s a new Geolocation API. The gist of this feature is that instead of relying on IP address lookup, the browser will instead interrogate the device for this information. This allows devices that have native geolocation hardware (GPS receivers and Wifi antennas, for example) to be able to pass their known location to the browser. Many web-enabled devices of today already provide support for this feature, including the iPhone, the Palm Pre, Android phones, and some netbooks.

The problem with all these methods, however, is that none of them just work on all devices. IP lookup works best in the workplace, but it doesn’t work as well for home users and doesn’t work at all for mobile users, as it pretty much requires a stationary device (amongst other things). The Geolocation API is not supported in all browsers yet (with the major notable holdout being all versions of Internet Explorer), and it tends not to work well on devices that don’t have built-in GPS capabilities (which the bulk of desktop and laptop devices still aren’t equipped with).

Worse yet, when location is returned via any technique, it is often inaccurate. In my case, IP lookup and Geolocation lookup provide locations that are over 10 miles away from each other! That’s not a discrepancy that can be resolved in many cases.

In the longer term, the Geolocation API is almost certainly the way to go. When it is fully supported, it is the most accurate method available. Today, though, the landscape is still fractured and implementing accurate geolocation is not trivial on the web.

I’ve created my first jQuery plugin this week – it’s an image overlay plugin (the static pic above doesn’t do the plugin justice, so click through to see it in action).

Creating a jQuery plugin isn’t that big a stretch for a competent JavaScript developer. There are quite a few tutorials out there where you can grab a template and start working very quickly. In addition to writing my plugin, I also made sure that it supported the metadata plugin, so that you can dynamically change properties on individual galleries and images, which should go a long way towards usefulness.

If you end up using this plugin, drop a line in the comments with a link so we can check out your work. Hope you enjoy!

Here’s a cool particle demonstration of the HTML5 <canvas> tag. It’s a tremendously small amount of JavaScript code that is responsible for pushing some radial gradient particles around a canvas. You can check out the source code to see how things are done – it uses jQuery a bit and the demo itself uses a free color picker control.

The demo works best in Firefox. Chrome has some ugly rendering artifacts when the gradients cross over one another and Safari can’t push a lot of particles on the screen without dying, but Firefox can render several hundred particles with ease (Internet Explorer doesn’t support <canvas> at all). If the computation for this demo were to be done on a GPU rather than a CPU, you’d probably be able to pump out thousands of particles with no issues.

Jaxer is a somewhat new technology that I’ve recently started to delve into. Jaxer is billed as the first AJAX server – basically, it’s a combination of a ‘web server’ and a set of APIs that can be used to develop web applications that transparently utilize asynchronous XMLHTTPRequests instead of postbacks as the standard way of communication between client and server. Jaxer development can be done in the Aptana IDE or via an Eclipse plugin.

Jaxer is somewhat unique in that the language used for both client and server is JavaScript. The server itself is basically the internals of the Mozilla platform (the DOM engine, the parser, the Javascript engine) along with a bunch of glue and a Jaxer API that facilitates, amongst other things, database and file access on the server side. The server is not standalone – it must be run as an Apache plugin (and IIS support seems to be planned for some future time).

What are some of the benefits of using Jaxer? One of the most obvious is the embracing of AJAX. As long as you understand the Client-Server paradigm, making AJAX requests is trivial. There is no extra markup needed – if you call a server-side method from the client side, the request is XMLHTTPRequest wrapped and sent to the server.

Another benefit to Jaxer is that there’s no new language to learn. Since Jaxer is built on JavaScript, it’s easy to add whatever JavaScript framework you’d like into the mix too, such as jQuery and YUI. These libraries are even available on both the client AND the server, rather than on the client alone.

Jaxer also comes with support for the Aptana Cloud built into the Aptana IDE and the Eclipse plugin. Once you have a Jaxer application working, you can do very easy deployment to the cloud service and be running in minutes with no additional configuration needed. You can also easily connect to the cloud to view your database and files through Aptana.

So, Jaxer sounds pretty cool. What are some of the drawbacks of it? One of the biggest currently is there’s no support for an Object-Relational Model (ORM). Many market leading web languages have ORM built in that make data manipulation easy. All database access must be made with straight SQL, which feels a little dated now. On the plus side, Jaxer comes configured with SQLLite out of the box, so no database setup is needed to run locally.

Another huge drawback is that there are not many places to host Jaxer on the web. Neither Dreamhost nor Godaddy have support for it (and, it’s been out for a year and a half!), so you’re pretty much relegated to a virtual private server or the Aptana Cloud for affordable hosting. Both options can be had for as little as $20 a month, but that’s a lot of money to just tinker around with some ideas.

Another drawback to Jaxer is that there is a hefty cost for a commercial license for the IDE (though a non-commercial license is free). I understand that the people behind Jaxer are a business, but it hurts particularly badly when your platform target is Linux-Apache. Both Ruby and PHP have free development tools available, so getting a company to fork over $500 a seat is not trivial to do.

There’s also no support for master and child pages in Jaxer. Jaxer was built as a tool to create web applications rather than web sites. You can’t easily separate your HTML files into a container and content frame, so building multi-page websites is not something that I would recommend in Jaxer.

Make no mistake – Jaxer is a compelling product. It is simple, easy to learn, intuitive, built on existing technologies, and it can make some wicked applications. It has support from some major industry players, including John Resig of jQuery fame. It has a long road ahead if it’s going to break into the big leagues, but I certainly would recommend giving it a spin. If nothing else, it will open your eyes a little on how to write world-class AJAX web applications.

The great part is that TinyMCE is specifically designed as an XHTML markup editor, so the output of it can go straight into any web container without further down-the-line manipulation. Even better was a feature I was not at all expecting – you can style the text editor with a .css file and a css class definition too! This means that if you use your site’s stylesheet and it’s written well, you can get the TinyMCE editor window to effectively replicate what your site post will look like. Now, that’s a powerful feature!

Here’s an example of what I mean. This is a sample post from my other site, blaqdesign.com, in the content editor system that I’m writing for it. The great part was that these posts weren’t originally created in TinyMCE, but since they’re valid XHTML fragments, I was able to load them into TinyMCE with no hassles whatsoever. If you go to the site, you’ll see in this very post in the site news, and formatted exactly the same way. The background is the same, the text formatting and colors are perfect, and the XHTML markup is preserved. Now, I don’t have to worry that other people will make a mess of the site formatting when they’re creating content.

If you’re interested, here’s my TinyMCE configuration I used:

<script>
tinyMCE.init({

mode : “textareas”,
theme : “advanced”,
theme_advanced_buttons1 :“bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,” + “|,bulletlist,numlist,|,undo,redo,|,formatselect,|,cut,copy,paste,pastetext,pasteword,|,” + “outdent,indent,|,link,unlink,image,cleanup,code,charmap”,
theme_advanced_buttons2 : “”,
theme_advanced_buttons3 : “”,
theme_advanced_toolbar_location : “top”,
theme_advanced_toolbar_align : “left”,
theme_advanced_statusbar_location : “bottom”,
theme_advanced_resizing : true,
theme_advanced_resize_horizontal : false,
content_css : “/Styles/blaqStyleSheet.css”,
body_class : “contentBody”

})</script>