Prototype JavaScript framework - blog

Prototype 1.6.1 RC3: Chrome support and PDoc

2009-06-16T22:21:00Z

Today we’re announcing Release Candidate 3 of Prototype 1.6.1. Among the highlights of this release are official Chrome support, improved IE8 compatibility, faster generation of API documentation with PDoc, and lots of bug fixes.

Chrome support

Since Google Chrome is a close sibling of Safari, Prototype has had excellent Chrome compatibility ever since the browser was first released. Now we’re making it official: Prototype supports Chrome 1.0 and greater.

If you have Chrome installed on your system (Windows only for now, even though early alphas exist for Mac), invoking rake test will run the unit tests in all locally-installed browsers, including Chrome. To run the unit tests in Chrome alone, try rake test BROWSERS=chrome.

Generate your own docs with PDoc

It’s been a long, strange trip for PDoc, the inline-doc tool that will soon be for Prototype and script.aculo.us what RDoc is for Rails. It started as Tobie’s brainchild over a year ago, but key contributions from James Coglan and Samuel Lebeau have helped to carry it across the finish line.

PDoc was a part of RC2, but has since been updated to make doc generation much, much faster. On my machine, a process that used to take 20 minutes now takes only 60 seconds. Furthermore, we’ve solved a couple of minor issues that made it hard to build the docs on Windows.

Ever since Prototype 1.5, we’ve kept our documentation in Mephisto, the same engine that powers the rest of the site (and this blog). It’s served us well, but it meant that updating the docs became a chore that could only be started once we’d released a particular version. PDoc will make it far easier to maintain our documentation — and far easier to keep archival copies of the docs for older versions of Prototype.

Upon final release of 1.6.1, we’ll put the generated docs on this site, just like Rails hosts its most recent stable documentation. Until then, you can generate your own local docs by checking out the full source and running rake doc from the command line.

Other improvements

There have also been a number of bugs fixed since RC2 — including a heinous bug relating to Event#observe — and a number of key optimizations. We’ve further improved IE8 compatibility, solving some edge-case issues that popped up since RC2. Credit goes to Juriy (kangax), our newest team member, for working tirelessly these last few months to make 1.6.1 faster and less reliant on browser sniffs.

Download, report bugs, and get help

Download Prototype 1.6.1 RC3
Submit bug reports to Lighthouse
Get Prototype help on the mailing list or #prototype IRC channel
Interact with the Core Team on the protoype-core mailing list

Thanks to the many contributors who made this release possible!

Prototype 1.6.1 RC2: IE8 compatibility, Element storage, and bug fixes

2009-03-27T23:33:00Z

Today we tagged the first public release candidate of Prototype 1.6.1. (What happened to RC1? Long story.) While there are more minor fixes we’d like to get into this release, we decided an interim release was necessary because of the final release of Internet Explorer 8 last week.

This is the first public release of Prototype that is fully compatible — and fully optimized for — Internet Explorer 8’s “super-standards” mode. In particular, Prototype now takes advantage of IE8’s support of the Selectors API and its ability to extend the prototypes of DOM elements.

What’s new?

Full compatibility with Internet Explorer 8. Juriy has spearheaded the effort to replace most of our IE “sniffs” into outright capability checks — making it far easier to support IE8 in both “super-standards” mode and compatibility mode.
Element storage, a feature announced previously. Safely associate complex metadata with individual elements.
mouseenter and mouseleave events — simulating the IE-proprietary events that tend to be far more useful than mouseover and mouseout.
An Element#clone method for cloning DOM nodes in a way that lets you perform “cleanup” on the new copies.

What’s been improved?

Better housekeeping on event handlers in order to prevent memory leaks.
Better performance in Function#bind, Element#down, and a number of other often-used methods.
A number of bug fixes.

Consult the CHANGELOG for more details.

In addition to the code itself, the 1.6.1 release features Prototype’s embrace of two other excellent projects we’ve been working on: Sprockets (JavaScript concatenation) and PDoc (inline documentation). Sprockets is now used to “build” Prototype into a single file for distribution. PDoc will be the way we document the framework from now on. The official API docs aren’t quite ready yet, but they’ll be ready for the final release of 1.6.1.

Download, Report Bugs, and Get Help

Download Prototype 1.6.1_rc2
Submit bug reports to Lighthouse
Get Prototype help on the rails-spinoffs mailing list or #prototype IRC channel
Interact with the Core Team on the prototype-core mailing list

Thanks to the many contributors who made this release possible!

Sprockets: Beautiful and angular

2009-02-20T01:59:00Z

Over at SvN, Sam announced the 1.0 release of Sprockets, the new dependency management and concatenation tool that makes it easy to modularize your JavaScript. Sprockets is Prototype’s new build system, but it’s also been extracted into a Ruby library so you can use it anywhere you write JavaScript.

There are many great ways to use Sprockets in your own projects. You can use it the way Prototype does — split up your JavaScript into small, maintainable files, then create “meta-files” that include the smaller files in a logical order. Prototype had previously been doing this with plain ERB; now we integrate Sprockets as a Git submodule and use it to build our distributable file.

Sprockets can also be used to write JavaScript “plugins”: bundles of files that can easily be integrated into existing code. With Sprockets, you can formally declare that foo.js depends on thud.js; when your files are concatenated into one output file, thud.js will be included first.

In addition, Sprockets lets JavaScript files provide other assets — HTML, CSS, images, and the like. At build time, those assets will be copied into the document root of your server (in a way that preserves the sub-structure of directories within). This allows the plugin to refer to those assets via absolute URLs, instead of having to ask you where they’re located.

A few facts are worth special mention.

Sprockets does not require Prototype. Sprockets directives can be inserted into any arbitrary JavaScript file. You can use Sprockets in your build system no matter which JavaScript framework you prefer.
Sprockets does not require Rails. Sam has also written an excellent sprockets-rails plugin, one which deftly applies the conventions of Rails plugins to JavaScript. But he has also written a generic CGI wrapper around Sprockets that is framework-agnostic. Or, instead, you can integrate Sprockets into your build cycle without bothering your server stack with the details. If you use Rake, you can do this with Ruby, as Prototype does; otherwise you can use the sprocketize binary from the command line.
Sprockets-enabled JavaScript files can work just fine without Sprockets. If your plugin has its own “build stage,” then the distributable JavaScript will include no Sprockets directives. On the other hand, if your plugin is small enough not to require this overhead, your distributable can be a short JS file that declares its external dependencies at the top. Because require directives are an extension of comment syntax, they won’t confuse a JS interpreter.

In short, we’re excited about what Sprockets means for the Prototype ecosystem. If you maintain a Prototype add-on library, the prototype-core mailing list would love to help you make it Sprockets-aware.

Now is the time on Sprockets when we dance.

Pimp My Code #1: Element.Storage

2009-02-16T08:41:00Z

Man, it's quiet around here. Interested in doing some pimpin'?

WAIT! COME BACK.

Code pimping. You know? The thing I'd discussed before? Forgive my earlier informality. I see now how my words could have been confusing.

The very first edition of Pimp My Code is special because the code we’ll be looking at will be included in Prototype 1.6.1. (It's a bit like if we were to Pimp [someone's] Ride™, then decide to keep the car for ourselves.) So this is more than just an academic exercise for us — the “pimped” result is now part of the Prototype source code.

The Original

The code in question, from Sébastien Grosjean (a.k.a. ZenCocoon), implements element “storage” — attaching of arbitrary data to DOM nodes in a safe and leak-free manner. Other frameworks have had this for a while; jQuery’s $.fn.data, for instance, is used heavily by jQuery plugin authors to great effect. But Seb’s is based on the similar Mootools API, which I’ve admired since it debuted in Mootools 1.2.

Here’s Seb’s code. It’s a long code block, since he’s been thoughtful enough to comment the hell out of it:

The idea is this: instead of storing arbitrary objects as properties on DOM nodes, create one custom property on the DOM node: an index to a global hashtable. The value of that key in the table will itself be a collection of custom key/value pairs. On top of avoiding nasty IE memory leaks (circular references between DOM objects and JS objects), this has the benefit of encapsulating all of an element’s custom metadata into one place.

Let’s make a first pass at this, line-by-line.

The Critique

Object.extend(Prototype, {UID: 1});

Already we’ve gotten to something I’d change. Seb is using the Prototype namespace correctly here, in that he’s storing something that’s of concern only to the framework and should feel “private.” But my own preference is to move this property into the Element.Storage namespace. I am fickle and my mind is hard to read.

Element.Storage = {
  get: function(uid) {
    return (this[uid] || (this[uid] = {}));
  },

  init: function(item) {
    return (item.uid || (item.uid = Prototype.UID++));
  }
}

OK, another change jumps out at me. The Element.Storage.init method gets called in both Element#store and Element#retrieve; it handles the case where an element doesn’t have any existing metadata. It creates our custom property on the node and increments the counter.

In other words, store and retrieve are the only two places where this method is needed, so I balk at making it public. My first instinct was to make it a private method inside a closure:

(function() {
  function _init(item) {
    return (item.uid || (item.uid = Prototype.UID++));
  }

  // ... rest of storage code
})();

I started down this path but quickly stopped. Instead, we’re going to refactor this part so that the init case is handled without the need for a separate method. Let’s move on for now.

Element.Methods.retrieve = function(element, property, dflt) {
  if (!(element = $(element))) return;
  if (element.uid == undefined) Element.Storage.init(element);
  var storage = Element.Storage.get(element.uid);
  var prop = storage[property];
  if (dflt != undefined && prop == undefined)
    prop = storage[property] = dflt;
  return prop;
};

A few things to mention here.

Variable naming is important. The ideal name for the third parameter of this function would be default, but that’s off-limits; default is a reserved word in JavaScript. Seb’s opted for dflt here, which is clear enough. I’d change it to defaultValue because I like vowels.

As an aside: my first instinct was to remove the defaultValue thing altogether, because I was surprised by the way it behaved. I didn’t find it very intuitive to give Element#retrieve the capability to store properties as well. So I took it out.

I changed my mind several minutes later, when I wrote some code that leveraged element metadata. I had assumed I wouldn’t need the “store a default value” feature often enough to warrant the surprising behavior, but I was spectacularly wrong. I put it back in. Consider that a lesson on how your API design needs to be grounded in use cases.
The idiom in the first line is used throughout Prototype and script.aculo.us (and, in fact, should be used more consistently). It runs the argument through $, but also checks the return value to ensure we got back a DOM node and not null (as would happen if you passed a non-existent ID). An empty return is equivalent to return undefined, which (IMO) is an acceptable failure case. Bonus points, Seb!
The custom property Seb’s been using is called uid. I’m going to change this to something that’s both (a) clearly private; (b) less likely to cause a naming collision. In keeping with existing Prototype convention, we’re going to call it _prototypeUID.
Here’s a nitpick: if (element.uid == undefined). The comparison operator (==) isn’t very precise, so if you’re testing for undefined, you should use the identity operator (===). You could also use Prototype’s Object.isUndefined. In fact, I will.

I have a prejudice against the == operator. Most of the time the semantics of === are closer to what you mean. But this has special significance with undefined, which one encounters often in JavaScript. As an example: when you’re trying to figure out if an optional parameter was passed into a function, you’re looking for undefined. Any other value, no matter how “falsy” it is, means the parameter was given; undefined means it was not.

(Oh, by the way: I am aware of the code screenshot on our homepage that violates the advice I just gave.)
There are other checks against undefined in this function. For consistency I’m going to change these to use Object.isUndefined as well. Also, the check for dflt != undefined is unnecessary: if that compound conditional passes, it means retrieve is going to return undefined anyway, so it doesn’t matter which of the two undefined values we return.

Man, I’m a bastard, aren’t I? Luckily, Element#store is similar enough that there’s no new feedback to be given here, so I’m done kvetching.

Before we rewrite this code to reflect the changes I’ve suggested, we’re going to make a couple design decisions.

Feature Design

While I was deciding how to replace Element.Storage.init, I had an idea: rather than use ordinary Objects to store the data, we should be using Prototype’s Hash. In other words, we’ll create a global table of Hash objects, each one representing the custom key-value pairs for a specific element.

This isn’t just a plumbing change; it’s quite useful to be able to deal with the custom properties in a group rather than just one-by-one. And since Hash mixes in Enumerable, interesting use cases emerge: e.g., looping through all properties and acting on those that begin with a certain “namespace.”

So let’s envision a new method: Element#getStorage. Given an element, it will return the Hash object associated with that element. If there isn’t one, it can “initialize” the storage on that element, thus making Element.Storage.init unnecessary.

This new method also establishes some elegant parallels: the store and retrieve methods are really just aliases for set and get on the hash itself. Actually, retrieve will be a bit more complicated because of the “default value” feature, but we’ll be able to condense store down to two lines.

The Rewrite

Enough blathering. Here’s the rewrite:

Element.Storage = {
  UID: 1
};

As promised, I’ve moved the UID counter. The Element.Storage object also acts as our global hashtable, but all its keys will be numeric, so the UID property won’t get in anyone’s way.

Element#getStorage assumes the duties of Element.Storage.get and Element.Storage.init, thereby making them obsolete. We’ve removed them.

Element.addMethods({
  getStorage: function(element) {
    if (!(element = $(element))) return;

    if (Object.isUndefined(element._prototypeUID))
      element._prototypeUID = Element.Storage.UID++;

    var uid = element._prototypeUID;

    if (!Element.Storage[uid])
      Element.Storage[uid] = $H();

    return Element.Storage[uid];
  },

The new getStorage method checks for the presence of _prototypeUID. If it’s not there, it gets defined on the node.

It then looks for the corresponding Hash object in Element.Storage, creating an empty Hash if there’s nothing there.

As I said before, Element#store is much simpler now:

  store: function(element, key, value) {
    if (!(element = $(element))) return;
    element.getStorage().set(key, value);
    return element;
  },

I thought about returning the stored value, to make it behave exactly like Hash#set, but some feedback from others suggested it was better to return the element itself for chaining purposes (as we do with many methods on Element).

And Element#retrieve is nearly as simple:

  retrieve: function(element, key, defaultValue) {
    if (!(element = $(element))) return;

    var hash = element.getStorage(), value = hash.get(key);

    if (Object.isUndefined(value)) {
      hash.set(key, defaultValue);
      value = defaultValue;
    }

    return value;
  }
});

And we’re done.

Further refinements

In fact, we’re not done. This is roughly what the code looked like when I first checked in this feature, but some further improvements have been made.

Since we’d been using a system similar to this to associate event handlers with nodes, we had to rewrite that code to use the new storage API. In doing so, we found that we needed to include window in our storage system, since it has events of its own. Rather than define a _prototypeUID property on the global object, we give window a UID of 0 and check for it specifically in Element#getStorage.

Also, based on an excellent suggestion, we changed Element#store so that it could accept an object full of key/value pairs, much like Hash#update.

In Summation

I was happy to come across Sébastien's submission. It was the perfect length for a drive-by refactoring; it made sense as a standalone piece of code, without need for an accompanying screenshot or block of HTML; and it implemented a feature we'd already had on the 1.6.1 roadmap.

You can get the bleeding-edge Prototype if you want to try out the code we wrote. Or you can grab this gist if you want to drop the new functionality in alongside 1.6.0.3.

We're further grateful to Mootools for the API we're stealing. And to Wil Shipley for the recurring blog article series we're stealing.

Prototype Linkedin Group

2008-10-17T07:32:00Z

When we first launched the Linkedin Prototype Group, we weren’t necessarily expecting it to be such a success–it’s over 800 members strong and counting.

Also, at the time, there wasn’t much you could do after having joined the group. This has changed with the recent introduction of discussions.

One of the first posts spurred some thoughts about the usefulness and goals of this Linkedin group especially given the high quality of our new mailing list. (And let me take the opportunity to sincerely thank T.J. Crowder for all the effort he’s put into it.)

My initial reaction, based on an early August thread was to suggest keeping the development-orientated discussions in the mailing list, while expecting more career-orientated ones to take place in the Linkedin group.

Of course, there’s no way we can nor should be controlling this, and in the end, you will be deciding what will happen where. So I suppose the only real raison d’être of this post is to advise you of this new feature and open up the debate.

Thoughts ?

Want your code "pimped"?

2008-10-07T21:23:00Z

We decided it’s finally time to implement an idea we had long ago.

I’m an avid reader of the blog of Wil Shipley, a man in the business of writing great apps for OS X. His running code improvment series, Pimp My Code, takes submissions from readers who think their code needs refactoring. Then Shipley refactors them, explaining the whys and hows along the way. The submissions are small (never more than 75-100 lines), but in rewriting them Shipley always happens upon specific, useful programming tips. I don’t know the first thing about Objective-C, but I find the series fascinating and instructive.

So we’re going to do something similar on this blog. Do you have a piece of JavaScript you want refactored? Does it use Prototype? Do this:

Sign up for a GitHub account if you don’t have one. It’s free and quick.
Go to Gist, GitHub’s pastebin app, and paste the code you want us to refactor. Mark it as “private” if you like.
Message me on GitHub with the URL to your code snippet. If necessary, explain a bit about what the code does (or should do), but don’t write an epistle or anything.

I’ll share the submissions with the rest of the team and we’ll pick a few that we like. Then we’ll dedicate a post to each one, refactoring out loud along the way. We won’t be mean or snarky; this is not a DailyWTF-style exercise.

To pre-empt the obvious rebuttal: we do not consider this to be an act of charity, or code manna from computer heaven, or a gift from the light-bearers to the huddled masses. Whether we actually “improve” your code is not for us to say. It will, however, illustrate our coding style.

If that sounds useful to you, then step up! Give us code and ask that it be pimped!

Growing the community

2008-10-07T17:39:00Z

Now that 1.6.0.3 is out, let’s talk about the Prototype community.

A lot of people have been commenting on how quiet it’s been around here over the last few months. There are several reasons:

We were quite busy with behind-the-scenes stuff. Moving to GitHub and Lighthouse was quite the task. As part of that migration we went through all the bugs on the old Rails Trac and were therefore left with a large backlog of bugs that we’d waited too long to address.
We were quite busy with our day jobs. Only a couple of us are freelancers; the rest work full-time for software companies. And usually there are several people working on Prototype at any one time, but over the summer it’s rarely been more than one or two.
In an effort to “catch up” with the accumulated tickets, we tried to stuff too much into a single bugfix release. We need to keep releases small and focused; trying to change too much at once tends to disorient us and our users. Once we realized we needed to scale back this release, it took a while to figure out which changes needed to stay and which needed to be reverted.

These aren’t excuses; they’re just explanations. As a team, we agree that we’ve got to prevent such a long release gap from happening again, and to keep an eye out for warning signs like the ones listed above.

This means, among other things, that we’re planning to move away from a “when it’s ready” release schedule. Instead, we’ll move toward one in which there are several releases per year; whatever is ready in time for a given release will go in, and whatever is not will have to wait. That applies to bug fixes and features alike. Eight months between releases just won’t work.

What you can do

Community outreach was one of the major goals of Prototype Developer Day. Many people are frustrated with the state of the Prototype community and would like to see some changes made. We’re in complete agreement.

Ideally, as an open-source community grows, those who want to help out gravitate toward specific roles. Those who can grok the source code write patches; those who are good at diagnosing problems file bug reports; those who can write clearly contribute documentation; and so on. We’d love to grow that “halo” around Prototype Core so that things can get done more quickly.

To be more specific, we would love help in any of these areas:

Give support on the Prototype & scrip.aculous mailing list.
File bugs in Lighthouse when you encounter errors or surprising behavior in Prototype.
Write test cases or patches for existing bugs in Lighthouse.
Discuss the direction of the library and its future on the Prototype Core mailing list.
Propose new features and implement them.
Write documentation wherever you feel we need more; submit it to Lighthouse as an enhancement.
Suggest blog posts. (Or even write them!) Post to the Prototype Core list if you’re interested in doing this.

There are, of course, many other things one can do to help us out. But if you’re looking for a way to contribute and don’t have something specific in mind, we’d suggest doing one of these seven things.

What we can do

We know we need more help, but we also know we need to be better community curators. So here are some things we pledge to do better:

We’ll beef up the Prototype web site so that it’s easier to get started with the framework, easier to find great resources like Scripteka and Prototype UI, and easier to find answers to common questions.
We’ll give special attention to documentation tickets on Lighthouse so that our API docs don’t stay stale and thin.
We’ll release on a more consistent schedule, as explained above.
We’ll resume work on PDoc (inline documentation) and Sprockets (JS dependency management), spin-off projects that make Prototype more of a “platform.” They’ll be a boon to the Prototype ecosystem when they’re completed.

Finally: if you consider yourself to be good at planning and organizing an open-source project, then we’d love your input on how to grow our community. Our highest priority, however, is not to launch a new initiative or process; it’s to get more people doing the seven things listed above.

Prototype 1.6.0.3: A long-awaited bugfix release

2008-09-30T17:48:00Z

Yesterday we released Prototype 1.6.0.3, the result of some much-needed bug fixes, and a stopgap release on the road to 1.6.1.

It’s a backwards-compatible, drop-in replacement recommended for all users of Prototype 1.6. We’ve fixed 30 bugs and made 25 other improvements to our already-rock-solid library.

Developers who follow along in Git might’ve noticed that the repository has seen a lot of disruptive activity in the last few days as we reassessed many of the commits that had gone into the library since April. Rather than try to fit too many fixes into one release, we decided to scale back and release 1.6.0.3 with the set of improvements we were in complete agreement on.

Because of the way we handled this overhaul, those who try to update their Git working copies to the latest trunk will encounter conflicts, even if they hadn’t made local changes.

Here’s how we recommend bringing your working copy up to date:

First, if you’ve made any local changes, please create a new branch so that those changes aren’t lost.
On your local master branch, run:
```
git fetch origin master
git reset --hard 34ee207
```
The first line fetches the new commits without trying to apply them to your local copy. The second line resets your master branch to be in sync with the latest revision.
From there, you can cherry-pick from your branch any local commits you made (though you may have to do some manual merging).

Download, report bugs, and get help

Download Prototype 1.6.0.3
Submit bug reports to Lighthouse
Get Prototype help on the Prototype & script.aculo.us mailing list or #prototype IRC channel
Interact with the Core Team on the prototype-core mailing list

As always, thanks to the core team and the many users who contributed bug reports and well-tested patches for this release.

Practical Prototype and script.aculo.us

2008-08-11T13:48:00Z

We’re very happy to announce a new addition to the Prototype bookshelf: core committer Andrew Dupont’s Practical Prototype and script.aculo.us published by Apress.

Obviously, Practical Prototype and script.aculo.us covers all you need to know about the latest versions of Prototype and script.aculo.us. But it goes well beyond that. Andrew does an awesome job at setting the context and giving appropriate background information, so much so that you’ll end up knowing not only the how but also the why. In the ruthless world of client-side development, that’s a serious asset!

Practical Prototype and script.aculo.us is a pleasure to read – the style is both straightforward and witty – and should appeal to beginners and seasoned developers alike.

If you want to try before you buy, you can always download a sample chapter or the table of contents from the Apress website. Or you can grab a hard copy and/or a pdf from the Apress website or from Amazon.

As always, happy Prototyping!

First Prototype Developer Day: Monday September 29, 2008!

2008-07-25T16:29:00Z

Prototype Core is happy to announce the first Prototype Developer Day! The Prototype Developer Day is going to be a recurring event bringing together Prototype Core members and users from the Prototype community to share experiences, offer insight into what’s coming up, and discuss topics like contribution, support, and the Prototype ecosystem. If you’re big on Prototype, you cannot miss this!

This fall, the Prototype Developer Day is being held in conjunction with The Ajax Experience, held in Boston from Monday, September 29 to Wednesday, October 1 2008. The Prototype Developer Day itself will happen on Monday.

Admission to the Developer Day is free. If you’re interested in attending the full three days of The Ajax Experience, you can save $100 with the code Prototype. Register before August 22nd and save an additional $100.

The provisional agenda for this Prototype Developer Day is as follows (more details coming up on the full agenda):

Start time	End time	Session	Speaker
8:00am	8:30am	Intro/Welcome	Prototype Core
8:30am	9:30am	Contributing docs	Christophe Porteneuve
9:30am	9:45am	Break
9:45am	9:50am	Greeting	Framework Summit Sponsor
9:50am	10:30am	Contributing code	Andrew Dupont
10:30am	11:15am	The Prototype ecosystem	TBD
11:15am	11:30am	Break
11:30am	1:00pm	Extended Q&A	Prototype Core

You will get a chance to hook up with members of Prototype Core and “close core”, and we all look forward to meeting you guys. Here’s the current rundown:

Sam Stephenson (to be confirmed)
Andrew Dupont (confirmed)
Juriy “kangax” Zaytsev (confirmed)
Mislav Marohnić (to be confirmed)
Tobie Langel (to be confirmed)
Christophe Porteneuve (confirmed)

For more information on coming with a group, contact Tracey West. You can view the agenda for The Ajax Experience, and then proceed to one or both of the following:

Want to register for PDD? You must use our special quick form. Registering for TAE doesn’t automatically sign you up for PDD, and the number of seats is pretty limited. (But, hey, there’s a free lunch!)
Register for The Ajax Experience.

Announcing new Prototype support mailing list

2008-07-14T15:51:00Z

Subscribers to the Rails Spinoffs mailing list should switch to our new, better-named list: Prototype & script.aculo.us.

While these two venerable libraries are, in truth, spinoffs of the Rails project, we’ve come to realize it’s far more user-friendly to have the libraries’ names in the name of the mailing list. This should help guide users to the right spot and reduce the amount of support traffic on the Prototype Core mailing list — which is for discussion of Prototype’s development process, not support.

Because list spam is a sad reality, your first post to the list will be held for moderation. Once it’s approved, though, you’ll be able to post with impunity.

An Interview with Ryan Johnson

2008-06-11T21:58:00Z

Today’s interviewee is Ryan Johnson of Control Suite fame.

Ryan just launched PersonalGrid, a new file sharing and publishing web application, along with a complete overhaul of Control Suite, now renamed LivePipe UI.

Hi, Ryan. Could you please introduce yourself.

Ryan Johnson: I’ve been writing web pages since 1993, but I’ve only felt comfortable calling myself a programmer for the last 5 years. I drank the Prototype kool-aid about 2 and a half years ago, and I’d say today nearly 75% of all the code I write is JavaScript. I enjoy writing Ruby just as much, but fewer and fewer people are asking me to do any work in Ruby at all.

The language itself hasn’t evolved all that much, but watching our collective knowledge and understanding of it grow has been a surprise and delight.

You just released a new web application: PersonalGrid. Can you tell us about it?

RJ: PersonalGrid is a file-sharing and publishing application that I’ve written. You can use it to upload files and publish single files or whole folders with one click. It’s also easy to share with friends or whole groups of users.

We have a dev team of one (me), and this is our first beta release, so hopefully any bugs you encounter won’t be too catastrophic.

How are you using Prototype in PersonalGrid? And script.aculo.us?

RJ: On the Rails side, 95% of the actions use a REST interface and spit back JSON, so the app is very client-heavy. Almost all of the HTML is generated with the Prototype Template class, with a little usage of the new Element syntax thrown in where appropriate. I used the Draggables and Droppables from script.aculo.us, but little else. I also ended up making many modifications (which I will release on GitHub sometime soon) to both of those classes to support some extra functionality.

Both Object.Event and LivePipe UI are discussed below, but those libraries are integral to the application. So our JavaScript stack looks like Prototype → LivePipe UI → PersonalGrid Application. The actual PersonalGrid JavaScript code is a number of classes that represent the major UI components (File, Folder, Friend, Group, etc), and a number of controller classes that initiate Ajax requests and process the JSON responses.

In the process of building the application layer I kept seeing inklings of a JavaScript MVC framework, but I just don’t see where the reusability would come from. Prototype is ever more awesome, and I’m releasing components that others will hopefully find useful.

What were the biggest challenges you faced when building it?

RJ: Internet Explorer. The only debate about the IE debacle that should be going on is whether the product is a result of incompetence or was designed deliberately to sabotage the development of complex web applications. They got XHR and the mouseenter/mouseleave events right, but that is about it.

Any technical advice, tips, or tricks you’d like to share?

RJ: Start using a broadcast/subscription based event model for everything in your app, not just Element objects! Of course I am going to plug my own solution Object.Event — but whether or not you use that, having a system where you can trigger your own events that do not relate to the DOM is critical for the maintainability of your code base. The new custom events in Prototype 1.6 are great (and I used a few in PersonalGrid), but it’s still geared towards the DOM.

For example, we have a trash can feature in PersonalGrid. Each user’s root directory has a .Trash folder, which mostly acts like any other folder, but we need to specialize its behavior. The two biggest differences are that we want to take the .Trash folder out of the normal directory listing, and give it a special place in the UI. We also want .Trash to behave differently when you are in it. We have a Location class that is responsible for changing folders, rending the directory listing, etc. Instead of putting these specializations for the Trash inside the Location class, we have the Location class fire an onChangeLocation event, which the Trash class observes.

It’s not only a conceptually elegant way to solve the problem, but you get the added benefit of having all of the code that relates to the Trash in one place. As I was developing the app, we ended up wanting all of these little specializations for friendship folders, group folders, etc, so the broadcast/subscription model has really ended up paying huge dividends as the project progresses.

You’re using a Java applet for file upload. Why did you choose to use that technology? What are the advantages over using flash?

RJ: There are some problems with the delay in loading the JVM, and the whole certificate/trust issues that all applets have, so I don’t want to sound too triumphant about the choice just yet. The main reason I choose Java instead of Flash is that you can drag and drop files onto the applet, which Flash does not support. Leopard supports dragging files directly onto file inputs, but users do not universally expect that behavior yet.

One of the areas I’d like to explore more is deep interaction between Java/Flash and JavaScript. The Java applet is one of the few parts of PersonalGrid that I didn’t write, but I worked closely with our Java coder to create a large series of JavaScript callbacks inside the applet so I could build a UI with Prototype.

There are a lot of fairly hairy undocumented bugs with LiveConnect (the Java/JS bridge), but until we get richer native functionality this is the only way to get around some of the security constrains browsers place on accessing the local machine.

You’re well known within the Prototype community for Control Suite. Can you tell us a bit more about it? Are you using any of it in PersonalGrid?

RJ: Well I’d like to apologize to the users of Control Suite for neglecting it for the past 8 months! PersonalGrid and some other obligations really destroyed my schedule. Control Suite has just received a major update, and is now called LivePipe UI and is compatible with Prototype 1.6. Most of the complex UI elements you see in PersonalGrid (windows, context menus, selection, etc) are available in the new LivePipe UI release.

LivePipe UI tries to provide a set of reusable core UI components that has a similar API design philosophy to Prototype. So far only components I have needed are part of the kit, but I am hoping that it grows with time. Now that it is on GitHub I’m hoping that it will be easier for users to contribute. The biggest news to existing users is that the Control.Modal class has been completely rewritten, and it is now a subclass of Control.Window. There are also proper Lightbox and Tooltip classes. The new class system in Prototype 1.6 made that far more elegant than it would have been before.

PersonalGrid has a distinct Mac feel. What made you aim for a desktop-like application?

RJ: Since an application of this nature is all about finding and organizing files and folders, why not recreate an interface people are already completely familiar with? We have a ways to go to catch up feature wise to Box.net, but when I first used their service I noticed they used some desktop metaphors (like drag and drop), but overall the application still felt too much like a website. Plenty of web services should feel like websites, but I don’t think file management apps should (except for Drop.io, which is wonderfully simple).

With regards to the Mac feel… besides borrowing some of the icons (still wondering if we will hear from Apple legal), there are a lot of very particular things that I like about the Finder. One of the hidden features of the PersonalGrid UI is that if you pick up an item and hover over any folder, breadcrumb, group or friendship, you will navigate to that location, and you will still be able to drop the item in any sub folder at the new location. The Finder does this, but I rarely use it because you can have multiple Finder windows open, or use the column view. In a two paned interface it’s the only way to elegantly get an item from A to C without moving it to B first.

Rich web development is still in its infancy, but Apple (and others) have had many complex UI problems elegantly solved for years on the desktop, so when I would run into a brick wall like the A-to-C problem, I would see how it was solved in the Finder, or even read the documentation in the Human Interface Guidelines.

It was also an amazingly fun challenge to deconstruct and recreate something as basic as the selection for the new Control.Selection library, which is also one of the core components of the PersonalGrid UI. When building something that complex yet fundamental one realizes all of the tweaks that coders and designers before you have thought obsessively about.

An Interview with Piotr Dachtera

2008-05-28T23:21:00Z

Piotr Dachtera is the lead developer behind the recently-launched Live Chess, a Prototype-based, Comet-powered live chess game.

We talked to him about the client-side challenges he faced along the way.

Hi, Piotr. Could you please introduce yourself?

Piotr Dachtera: Sure. I’m currently the lead developer of the JavaScript/Ajax/Comet part of chess.com.

I’ve been dedicated to Web + chess applications since 1999. I’ve also been working on business software since 2000 (mainly Java). My interest in the game of chess was always pushing me forward and finally I think I can say I’m working on the number one web chess project.

You’ve built Live Chess using Prototype and script.aculo.us. Can you tell us more about the application?

PD: Chess community website users need to share things using a specific “language” which needs something more than plain text. They need to share game positions, whole chess games with analysis, and chess puzzles. Also, they want to play against each other.

As we were starting to work on it all, I already had some experience with Prototype and script.aculo.us, and it was the natural choice.

We started with the interactive boards with draggable pieces, chess game parsers and things like that. Naturally, I had in mind that we were going to build something much more complex (the scalable real-time play server), so enclosing everything in reusable classes was the only solution. As it was always tempting to see what’s inside Prototype, I was investigating its source all the time and I was trying to build my classes using the same style.

Live Chess uses Comet to keep the chessboard synchronized. What made you choose that technology over ordinary Ajax?

PD: The most important word in “Live Chess” is “live.” We need things to happen instantly. We can’t use polling to check every 10 seconds if anything changed.

If people want to play a game of chess in 2 minutes, they need some kind of instant communication.

Can you give us more details on the Comet implementation?

PD: Working on my own proof-of-concept chess server in 2005, I “(re)invented” the Comet idea to allow this kind of communication… only to find out that people were using the same idea in simple chat apps.

The next step (which came with the new server built for the chess.com community and needed real scalability) was to use the idea of thread-less server solutions implemented in Jetty server and ActiveMQ to push messages between client and server.

Finally, we switched to Cometd/Bayeux with our own solution for guaranteed messaging and message ordering.

In all of these solutions, there was always Java on the server-side.

What are you using Prototype for?

PD: I started with script.aculo.us effects investigation which guided me directly to Prototype.

Currently, I’m not really a JavaScript developer. I’m a Prototype developer using the library everywhere.

On top of Prototype and Dojo, I saw you were also using ExtJS in Live Chess. Was the integration of these three libraries seamless or were there issues?

PD: We are using ExtJS with the Prototype adapter so there was nothing really hard to do here.

Dojo things are completely separated from the rest of the system, but we had to use the library for Cometd communication. As a Prototype fan, I would be really happy to have a Cometd implementation built on top of Prototype, but currently I had to use Dojo in this area (which is sandboxed in a separate communication frame).

What were the biggest challenges you faced with this application?

PD: We still have lots of big challenges! But if I had to choose one, I would say: performance. Everybody wants to use Live Chess (and any other similar application) as if it was a desktop application. As the system becomes heavier and more complex, we still have to work hard to keep it smooth.

Prototype hosted on Google's servers

2008-05-27T19:06:00Z

Good news! Google now offers a cached, compressed copy of Prototype on its high-speed content distribution network via the AJAX Libraries API.

You can either link to the source code directly:

  <script type="text/javascript" 
    src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>

Or you can use Google’s API:

  <script type="text/javascript" src="http://www.google.com/jsapi"></script>
  <script type="text/javascript">google.load("prototype", "1.6.0.2");</script>

More information is available from Google’s documentation.

When a specific version of Prototype is delivered to your browser, it will be cached for one year and served with the proper compression headers. That means that most users of sites which link to Google’s copy of Prototype will incur a ~30 KB download only once.

We typically encourage developers building applications with Prototype to concatenate all their JavaScript into a single file, and serve that file with the proper content expiration and compression settings. In cases where this is unfeasible, Google’s hosted version is an excellent alternative.

Special thanks to Dion Almaer and the team at Google for making this possible.

An Interview with Amy Hoy

2008-05-21T06:01:00Z

Hot on the heels of last week’s interview with Sergio Pereira, we were lucky enough to catch up with Amy Hoy. Amy defines herself as a informally educated designer-turned-interface-developer who also programs (and writes, and speaks, and takes pretty pictures). She’s also the co-creator of Twistori.

Amy, you’ve been involved in both the Prototype/script.aculo.us and Ruby on Rails communities since their inception. What was your background? What brought you there?

Amy Hoy: I admit it — I was a professional PHP developer. I started out doing freelance design as a teenager but got tired of relying on other people to do the implementation (and quickly realized the lack of respect towards design in general). I’d dabbled in programming since a kid, but PHP was the first language I’d learned fully. I think it was a good start because it required so little to begin and see immediate results.

I had found out about Basecamp from a designer’s community I was part of, waaay back when it was in beta testing. It really stood out in my mind. Later, somebody else posted about this thing they used to build Basecamp, so of course I was intrigued.

I went to the old Ruby on Rails site (back around version 0.7), saw the code samples and fell head over heels. The sparse code really appealed to my designer’s nature and I was sure it would be a big hit with other people too. I’d been doing PHP long enough by that time that I was feeling the pain, and Ruby looked like an amazing solution to that pain.

Somebody felt my pain! And it was awesome. I feel like this could be a meaty episode of Dr. Phil.

Script.aculo.us I learned about through Rails, and naturally it appealed to me because of all the visual possibilities.

Although you’re not teaching JavaScript per se, you’ve always been inclined in facilitating the learning process, whether it be through your blog, presentations or cheat-sheets. What’s with that?

AH: I like to teach in general. I’d say the percentage of “educational” content on my blog hovers around the 80-85% mark. I’ve had a number of teachers who changed my life, but none of them were what you’d traditionally call teachers — they were authors, mentors, speakers, and so on. I really enjoy being able to do that for other people, and I definitely get off on the intellectual challenge of figuring out the best methods to get my readers/attendees to that “aha!” moment.

And Javascript, well. JavaScript is a really painful subject to learn from scratch.

Most of the online articles and books either focus on a poor choice of topics (or simply embody bad practices), or leave you hanging by not explaining the whole language, the DOM, events, etc. Or they’re purely references and leave it to you to piece together the whole picture. Or the window they give you into the subject is so narrow as to be useless.

Me, I got dropped suddenly into the JavaScript world in order to build something I’d designed at a former employer. I started knowing almost nothing (and all of it bad). This was back before Prototype had any documentation. I learned a lot reading the tests but it was slow going.

While the whole experience was ultimately exhilarating, the lack of good learning sources meant it was also hair-tearingly frustrating. So I set out to make some.

I can say from experience that it takes a lot of hard work and analysis to create a truly great tech education resource. And traditional book publishers don’t pay well for the effort, either. It’s not at all surprising that there’s no One True Source.

But… my script.aculo.us cheat sheet has been downloaded over 500,000 times. Clearly I’m not the only one who sees a problem.

In the same vein, you’ve teamed-up with Thomas Fuchs (creator of script.aculo.us and Prototype Core committer) to write an ebook on JavaScript “basics”.

AH: Yeah. I wouldn’t call it “basics,” but we are writing about JavaScript: The Language not just JavaScript: Here’s How You Use This Framework. Real, pure JS language skills are very hard to come by these days and that is one of the areas where existing books, etc., really fall down. A lot of people find themselves hamstrung because they’ve started using some framework or toolkit, and when they need to work around it, they realize they don’t know enough JavaScript to do so. (Sound familiar, Ruby/Rails people?)

We’re working on the mini-book now. It should be out sometime in August, and weigh in at around 50-70 pages. It’s well-designed with every page laid out by hand… we want it to be something you really enjoy reading, not just another tech book.

If people do like it, we’ll continue the series: the DOM, effects, compatibility, the works.

There’s a real hunger for this kind of content, I think. My JavaScript Boot Camp tutorial (3 hours) at OSCON a couple summers ago was completely packed. The premise was basically “you’re using the frameworks and the libraries, don’t you think you should understand the language?”. Only Dave Thomas’ Ruby tutorial had more people. I was definitely not “a name” at that point and I was just a little bit surprised.

And last year, I did a shorter talk on Object#prototype and Prototype, and that was very well-attended too.

So the need was there two years ago and I’m convinced that it’s still here.

You recently mentioned finding API docs “almost universally frustrating”, and looking into new, somewhat self-reflexive solutions for documentation. Can you elaborate?

AH: Without turning this into a whinefest? Certainly!

Having great API docs is one of the best ways that people can promote the usage of their open source projects. I, for one, use the prototypejs.org site constantly when working in JavaScript.

But API docs are best for people who are in a final-ish stage of the learning cycle. They’re most useful when you already know what you’re looking for. They’re not for getting started, even if they have a couple pages about getting started. And they lack immediacy. They are, by nature, reference documents.

So, given those arguments… how could we make something better? I’d been thinking about this a lot and one night over a couple of beers in Vienna, Thomas and I came up with explain().

It’s still under development, but the basic idea is that you’ll be able to call the explain() function on any Script.aculo.us effect and it will pop up a floating DIV right there with information on how to use the method, its options, etc., even examples. This way you can get your information fix immediately while programming, without having to lose your focus navigating the API docs or the wiki. And, as far as I know, it’s something that hasn’t been done before.

This of course will be an add-on for development, not something that would be deployed in the standard package.

You also seem to practice thinking outside the box in your own work. Twistori, which you’ve just released in collaboration with Thomas Fuchs, is a great example of that. Other than being immediately distinguishable by its stunning looks, it’s not your average mash-up.

AH: Thanks.

We’ve both been doing a lot of intranet and corporate software and the morning I decided I had to ship something, I think we were both about to pop with creative frustration.

Twistori is different from most mashups because it takes the Twitter data and extracts meaning from it. Not technical meaning, not data, but human, emotional meaning that we can connect to. When you’re reading this stream of hopes, loves, hates, thoughts, etc., it’s kind of hypnotizing because it’s a bit like voyeurism, and a bit like PostSecret, and a lot like the normal, everyday cacophony of life.

Every choice in the design is intentional—the flow, the colors, the way the messages are formatted, the anonymity, and the lack of ability to “scroll back” when a message has gone by. This all contributes to the effect of what one person called “the river of humanity.”

Since I woke up one morning with the intense desire to build it that day, it is necessarily very sparse. I made it a challenge to have no graphics. I did the design, he breathed life into it; it was a perfect collaboration. Thomas and I put maybe a total of 8 hours into it before we launched it — with a single tweet each. Then it exploded!

I knew people would love it, but I wasn’t expecting it to explode the way it has with just two tweets. I expected to have to do a little more work promoting it than that! And we were planning to do revisions before the “big debut,” too. But that’s how it goes.

I think the biggest lesson there is that humans don’t really change with technology. We still seek connections, and we are still voyeuristic and interested in other people, and if you can make design decisions with that in mind, people will be affected by your work.

Anything else you’d like to add?

AH: I like to dabble. A lot. In everything! I like to figure out where the pain’s coming from and try to fix it, and surprisingly, it tends to work out.

Also: JavaScript is really going places. Even though the Ajax buzz has worn off and the business magazine writers are now bored, JavaScript web dev is far from static. It’s still very much the wild west, even if it doesn’t seem like it to those of us who’ve been in this thing for the past few years (or longer).

Lots of really unbelievable things are coming out now (like John Resig’s processing.js and script.aculo.us 2.0) and it’s not likely to stop any time soon. Things are going to get even better. I’m really excited to be a part of it.