The latest version of the Prototype JavaScript Framework, Version 1.7.1, may appear to be a decimal-point update but it features an overhaul of the DOM library and better compatibility with ECMAScript 5.

When Prototype 1.7 was released in November 2010 its lead developer outlined plans for a bug fix release, 1.7.0.1, that would rewrite the DOM code to be easier to read and faster, and a minor release, 1.7.1, that would address ECMAScript 5 compatibility.

Now, some 20 months later, Version 1.7.1 bundles both of these promised releases together.

On the Prototype blog Andrew Dupont explains that its dom.js section has been completely rewritten for various reasons:

1. We wanted to use the code conventions that the rest of Prototype used. This means creating named functions inside a private closure, then attaching those named functions to public objects to expose an interface. It makes for more concise code and helps you debug.

2. We took the opportunity to change the way we register events, which reduces susceptibility to memory leaks in older versions of Internet Explorer. Not only does this improve performance in IE on page unload, it also improves performance on a number of DOM-related methods, including update and remove.

3. Consolidate repetitive code tasks into new convenience methods, removed redundancies and fixed a few bugs for layout-related edge cases.

For compatibility with the ES5 specification, certain array methods have been rewritten so that that Prototype acts as a polyfill for ES5 array methods, adding them to any browser that doesn't support them natively.

In looking forward, Andrew Dupont notes that as he is currently the only developer working on the project on a regular basis progress is bound to be slow. He states:

If you’re concerned about Prototype’s future, I can only tell you that I have no plans to abandon its development. But, at the same time, I can’t commit to any milestones or consistent release schedule, because I’m doing this in my free time.

He goes on:

In the short term, if you have specific things you want to fix and you feel like they aren’t getting done quickly enough, a GitHub pull request would be the best way to get it in front of my eyes.

In the long term, if this process reveals some consistent and helpful contributors, I’d certainly be interested in adding those people to the core team.