Our own Michael Mahemoff is at it again, creating a simple little GUID generator called Guid0:

Guid0 is a GUID library for Javascript. Okay, it doesn’t yet do official, bona fide, 128-bit, GUIDs yet, mainly for API design reasons. But this is a library you might find useful if you want to generate a unique ID in your Ajax app.

PLAIN TEXT

JAVASCRIPT:

1.  
2. // simple
3. guid = new Guid();
4. var newguid = guid.generate();
5.  
6. // options
7. guid = new Guid(
8.   {
9.         chars: Guid.constants.base85,  // or you could say "abc" if you only wanted those chars to appear
10.         epoch: “June 1, 2003″,
11.         counterSequenceLength: 2, // a counter field appended to the end
12.         randomSequenceLength: 2 // a random field appended to the end
13.   }
14. );
15.  

He is working on 128-bit support.

SproutCore drove onto the scene when MobileMe launched using it.

Since that blast, the team has been diligently working on getting a 1.0 release, and Charles Jolley has
posted on the future of SproutCore:

It’s been nearly four months since SproutCore launched to the public at WWDC and we couldn’t be happier with the results.  18,000 developers have installed SproutCore (sudo gem install sproutcore ftw), nearly 1,000 developers have joined the mailing list, and dozens of projects are underway at companies around the world.  One additional one has already gone public (OtherInbox).

During this time the developers working on SproutCore haven’t stood still either.  150 tickets closed, some major new features, and enhancements for Windows, IE7, Chrome, and others.  Many of the changes we’ve applied have come from you, the community.  In fact, over 20 people have contributed code to SproutCore now, which is outstanding for such a young project.

Now that I’m back from my trip, though, I thought we should spend a little time talking about where we are headed next.

Put simply, our next major milestone is SproutCore 1.0.  When I started planning SproutCore 1.0, here were the criteria I laid out for it:

• Make the common easy and the uncommon possible. Typical behavior for an application should be nearly automatic without limiting a developer’s ability to hack something cool.
• Support the whole application. SproutCore must support the whole application development process, including the model, view, and controller layers as well as design, testing, documentation, and deployment concerns.
• A small consistent API. Favor configuration over class-bloat.  Use consistent “guessable” design patterns.  The API should be vetted well enough that it will not need to change dramatically once released.
• Offer broad platform support. Perform well on all modern browsers.  Perform adequately on IE7 and earlier.

Charles then goes into detail on some of the bigger changes:

Faster Observers and Bindings

Property observing and bindings underpin almost everything you do in the SproutCore framework.  Because of that it is really important to make this feature small and fast.  We have currently rewritten this code to make it almost 2x faster on its own, and to use significantly less memory.  More on this in the coming days.

DOM Library Independence

Currently, SproutCore depends on Prototype for a few cross-platform functions.  This really doesn’t make much sense.  In particular we think of Prototype, jQuery, and others as “DOM manipulation libraries”; somewhat like low-level drawing APIs.  SproutCore should live above this layer, allowing you to choose whichever drawing library you like to create custom views.  Additionally, removing this dependence will allow those who do not want to use Prototype to eliminate that page weight from their apps.

New Model Layer

The current implementation for SC.Store, SC.Collection, SC.Record and the servers have not been revisited since they were written almost two years ago. When these were first deployed, they worked fairly well for the small apps that used them.  Since then we’ve seen applications loading 40,000+ records into memory in a regular basis and a move towards investigating use of the coming local storage facilities on modern browsers.  This code is going to see a wholesale rewrite as we update the API to accommodate this new, larger scale world.

There has been other SproutCore related news recently:

• Having SproutCore working with an Erlang backend
• How fast can a SproutCore app load? shows off a simple todo list application running on App Engine
• SproutCore 1.0: New Bindings and Observers
• Caching Computed Properties
• Using Computed Properties To Lazily Load Data

John Leach has created a very cool new open source project called Frizione (Italian for Clutch).

Frizione is a “JavaScript development, testing and deployment environment. It comprises a library agnostic set of tools for any type of browser based JavaScript development, which coincidentally has Gears support.”

You run Frizione as a Web server and it gives you a set of services:

Compressor Service

The compressor service takes a JavaScript file and removes comments and
unnecessary whitespace. This can be a destructive operation in that the original

JavaScript file can be overwritten, unless the -o option is specified – you have been
warned.

To invoke the service, send a POST request to /run_compressor, appending the
absolute JavaScript file path, with respect to the /Clutch root directory, as part of
the URL. Clutch will then compress the JavaScript file. Additional request parameters
can be set to modify the behaviour of the compressor, using the YUICompressor
command line options.

Fixture Service

The fixture service allows you to write text to hard disk. When sent a POST, the
service writes the POST data to the file specified in the URL, optionally modifying the
contents with parameter values specified in the POST request, using ERB.
To invoke the service, send a POST request to /run_fixture, appending the
absolute output text file path, with respect to the /Clutch root directory, as part of
the URL.

Join Service

The join (or concatenate) service uses ERB to join together a list of text files,
producing a single concatenated file. Each file can contain include commands
which contain relative URLs to other files to be included at the point of the include
command itself. This process can also be repeated within the included files (nesting).
To invoke the service, send a POST request to /run_join, specifying the absolute
text file path, with respect to the /Clutch root directory, as part of the URL. Clutch
will then create the joined (or concatenated) file. The to request parameter is
required to set the destination absolute URL of the resulting joined file.

JSLint Service

The original lint program analysed C source code for potential (and subtle)
malpractices likely to lead to run-time bugs. Modern C compilers now provide
sufficient syntactic and semantic checking that lint is now rarely required or used.

Fortunately for JavaScript programmers, Douglas Crockford has built a lint program
specifically for JavaScript, in JavaScript, called JSLint. Finding and removing
potentially poor code before unit testing is an essential process, at least for me.
Unfortunately, cutting and pasting code to the web page can itself be error prone.

Clutch alleviates this problem by creating static HTML pages that read in your
JavaScript code, which can then be analysed locally by JSLint. You only need create
the static HTML page once for each JavaScript file you wish to analyse.

To invoke the service, send a POST request to /run_jslint, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then produce a static HTML file under the /jslint folder, which
automatically loads the JavaScript file into the JSLint page. You may then wish to add
a link to this static HTML file in the /jslint/index.html page.

Test Service

The test service creates a run/view pair of static HTML files for a given JavaScript
file. The reasons for using two HTML files is explained in the ‘Unit Testing’ section
below.

It can also provide functionality similar to the join service. It can use ERB to join
together a list of JavaScript files, producing a single concatenated JavaScript file, but
only if the to parameter is specified.

To invoke the service, send a POST request to /run_test, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then create the two static HTML files.

The Unit Test Framework

The framework follows a similar pattern to the well known JUnit Java testing
framework.

Create your test methods in a plain JavaScript object, then wrap that object in a
clutch.unittest function call, as shown in the first example above. All functions
in your test object which begin with test will be executed by the unit test
framework, but the order of function execution is not guaranteed.

Before a testxxx function is executed, the unit test framework will execute a setUp
function in your object. After a testxxx function has been executed, the unit test
framework will execute a tearDown function in your object. Clutch provides a
default no-operation function for setUp and tearDown if none are defined in your
object.

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

• Caching can be done correctly, and once, by us… and developers have to do nothing
• Gzip works
• We can serve minified versions
• The files are hosted by Google which has a distributed CDN at various points around the world, so the files are “close” to the user
• The servers are fast
• By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
• A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

The second way to access the scripts is via the Google AJAX API Loader’s google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

You will notice that the version used was just “1″. This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of “1.8.2″ will select the obvious version. This is because a fully specified version was used. Specifying a version of “1.8″ would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for “1″ will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the “uncompressed” parameter like so:

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT’d ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don’t have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don’t use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

Eugene Lazutkin has written a very thorough post on dojox.lang.aspect a module that takes AOP seriously in JavaScript.

As someone who has been to a couple AOSDs (the AOP software conference) and was excited to see AOP on the scene, it is good to see someone who gets it working on the JavaScript side.

Of course, we all get the interception piece. It is very easy to just wrap a method to do something new in a dynamic language such as JavaScript. But the power (and complexity!) of AOP lies in the world of joinpoints, pointcuts and worm holes :)

For these, a dynamic language isn’t as helpful. Eugene delves into the world and takes us to the module from first principles. He then builds a timer aspect which can be used to profile an application. Along with a memoizer and other useful cross cutting concerns, you end up with good ole Fibonaci:

Memoization got results too:

On my computer with Firefox 3 the calculation of 1-order (regular) Fibonacci number of 15 (987) took ~48ms without memoization and 0-1ms after memoization. The calculation of 0-order Fibonacci number of 15 (32768) took ~1155ms without memoization and the same 0-1ms after. As you can see this technique can work wonders without much investment of time.

Just like with Java, we won’t see every developer worrying about pointcuts day to day, but instead, simple usage of existing advice will become very useful indeed.

Jeff Watkins is a fan of the Cocoa data binding model, and wanted to bring it to the Web. This lead him to create a projects three years ago, which comes out of the dark now: Coherent.

There are some fun demos, such as the Flickr Browser, and the Laptop configurator which mimics the Apple store look and feel for picking a product.

There is also some documentation so you can learn how it all works. There are tutorials on properties and bindings, how to write a widget, and details on the APIs.

Most of the magic is done via attributes in HTML itself, along with the JavaScript API. For example, you get binding:

and then bindings happen in HTML such as:

Christian Effenberger is back with some more canvasy goodness. He has released Busy.js, a library that allows you to add/remove loading indicators to html elements on your webpages (inc. overlay color & transparency). It uses unobtrusive javascript to keep your code clean. Requires no plugin/extension or any other external resource.

Usage

Features

• supports Canvas and VML (identical representation)
• Fast and easy to implement (perfect for ajax applications)
• Don’t need to spend time in an image editor creating gif animations
• Very flexible by multiple (optional) parameters for individual styles
• Get always a proper loading indicator independently of parent elements style
• Moves the DOM tree up to find the next parent block-level element
• Freezes the parent element visual (overlay) and technical (mouse events)
• Works with html elements even if (moz/webkit)-border-radius is activated
• In older browsers, the script degrades to simple quadratic shapes
• It’s dead easy to add or remove the loading indicator to/from an html element

Vladimir Lichman of IT Hit has released an Ajax library for managing WebDAV servers.

The library is compliant with WebDAV RFC 2518 and allows management of Class 1 and Class 2 complaint WebDAV servers. With IT Hit AJAX Library you can copy, move and delete items, read and set custom properties, lock items and discover locks. It is written entirely in JavaScript and supports IE, Firefox, Safari and Netscape.

Version 2.5 of the Yahoo User Interface Library (YUI) was released today. You can get all the details on the official blog post, but here’s the “change log”:

• The new Layout Manager allows you to create multi-pane user interfaces that are collapsible and resizable.
• The Flash-enhanced File Uploader control might be known to you from Flickr and and allows you to easily batch-upload files and images with progress bars.
• The JavaScript Profiler now has a graphical front-end to make the information more easily understandable
• The YUI Data Table performs faster and got new features, including horizontal and vertical scrolling, a paginator class, drag and drop columns and an API to access, add and remove columns.
• The Image Cropper control allows you to pick a part of an image to be cropped server-side
• The Cookie Controller provides a wrapper for all things to do with cookies
• The Slider Control got updated to support multiple handles to define a range rather than just a state.

In addition to that, some of the components left beta status. These are the Get Utility to retrieve scripts and style sheets on the fly, the ColorPicker Control, the JSON Utility to validate JSON, the ImageLoader Utility to load images on-demand to increase page performance and the YUI Test Utility.

The really detailed report on all the changes is available on the YUI list/forum.

If you want to have a quick glimpse of what the Layout Control allows you to create, check out the demo application interface simulating simulating Yahoo Mail.

John Resig has created a little script to give you pretty dates that Web 2.0 know and love (thanks Rails):

The library is short and sweet: