AJAX & RIA Journal Special: Results of OpenAjax Alliance's Browser Feature Wish List

What does the Ajax community want from future browsers? How are these different requests prioritized? Web developers have done amazing things with Ajax for both Web 1.0 and Web 2.0 applications, but what barriers need to be removed to enable the next generation of browser-based innovations? The future of Ajax runtime environments matters more than ever today.

In late 2007, OpenAjax Alliance formed the Runtime Task Force (http://www.openajax.org/member/wiki/Runtime) to address this community concern. The goal is to collect, articulate, and prioritize key issues from the Ajax community, and communicate them to browser vendors. This will help educate the community in large, help browser vendors better plan for their product roadmap, and help developers better use Ajax.

Article author Coach Wei speaking at a previous AJAXWorld RIA Conference

There are other great rich Web UI technology initiatives such as W3C’s HTML5, CSS3 and SVG. The OpenAjax browser wish list is not intended to compete with these initiatives, but instead complements them by capturing and communicating the views of the web development community (the folks who are “users” of Ajax techniques).

1. The Process

The OpenAjax Runtime initiative used a two phased process. A special wiki site http://www.openajax.org/runtime/wiki/Main_Page was set up to facilitate communication and collaboration.

In Phase I, OpenAjax Alliance collected an initial list of feature requests. This is largely done by researching blogs, meetings with OpenAjax members and Ajax experts, and interviewing leading Ajax toolkits.

The initial wish list was announced in April 2008 for community review and feedback. A group of industry experts were being actively approached for feedback (see Phase I Voting wiki page).

Phase II started in May. The Alliance re-organized the feature lists based on Phase I results. Phase II wish list was put into voting in June. Voting was open to the general community. For each feature request, a voter can vote from 0 to 10 to indicate how strongly the voter feels the need for this request (10 being the most important).

The voting ended on July 13^th 2008.

2. Feature List Summary

A total of 55 features were written up by various people in community. These writeups typically cover areas such as what the feature is, background, why the feature is important, possible solutions/recommended approaches for this feature, references, etc.

As a result of community feedback, some features are classified into “InActive”. For Phase II voting, there is a list of 37 active features. The current feature request list is:

Security features

Client-server communications features

HTML5/W3C features

CSS features

Rendering/interaction/event handling features

Performance features

JavaScript features

Other features

3. Community Voting Results

By July 13, when the voting closed, this initiative has turned out to be a bigger success than expected. Given the amount of effort required to read and understand the vast web technology landscape, and the relatively limited time and resources available to the OpenAjax Alliance Runtime participants, we were hoping for 50 or so people to vote, which would be meaningful to establish a rough idea of what's most important to the community.

Voting results are available at:

Here are some quick statistics:

222 participants;
143 people voted;
55 feature request being written up;
Various Industry leaders contributed;
A discussion thread spawns on Slashdot with 628 comments (http://tech.slashdot.org/article.pl?sid=08/06/30/1845201).

See next page for the Top Requested Features

4. The Top Requested Features

Among all the feature requests, 2D Drawing/Vector Graphics is clearly the most desired feature by the community. It received most votes (110 people voted for it), and highest total score (842, over 10% higher than the 2^nd feature request). The 2^nd top feature request is enhanced security for cross-site scripts. The third one is HTML DOM performance.

The following table shows the top 10 features:

Feature	Total (#Votes x Avg Vote)	# Votes	Avg Vote (0-10)
2D Drawing/Vector Graphics	842	110	7.65
Better Security for Cross-site Scripts	759	102	7.44
Better APIs about positioning and styling	748	99	7.56
HTML DOM Operation Performance In General	742	92	8.07
Better Support for Rich Text Editing	693	102	6.79
The Two HTTP Connection Limit Issue	690	98	7.04
Better UI Layout Support	689	96	7.18
Native JSON Parsing	688	107	6.43
Persistent Connections Issue	649	95	6.83
Video and Audio	639	99	6.46

Here are some general themes that emerge from the runtime initiative:

Graphics – The top vote getter was 2D Drawing/Vector Graphics. Ajax developers today are achieving astoundingly rich graphics effects through clever techniques leveraging JavaScript, CSS, images, and whatever vector graphics features they can find (usually, SVG, VML and Canvas), but browser differences are a major pain point among Ajax developers. Mozilla, WebKit and Opera support both Canvas and SVG with good interoperability (although Mozilla does not yet support SVG animations). IE is the holdout. The call-to-action is for all browsers, particularly IE, to support both of the industry standards for 2D vector graphics, SVG (the DOM-based standard) and Canvas (the procedural-based standard).
Security – Web security is an important topic for leading Ajax developers. The second top vote getter was Better Security for Cross-Site Scripts (XSS), but other security requests also receiving high votes, such as Strong Cross-Site Request Forgery Protection (which it turns out was the 11^th top voter-getter). The perception of the moderators is that it’s not just XSS, but that the community cares about all aspects of ensuring that the Web is secure, and in fact more secure than it is today. Recently, Mozilla has authored a proposal that might help make the Web more secure: http://people.mozilla.com/~bsterne/site-security-policy/. Note that Native JSON Parsing can be considered a security feature because without it Web developers are more inclined to use JavaScript eval() to process JSON data, which might allow for XSS attacks.
Better low-level CSS and DOM support for layout – Two of the top vote-getters were Better APIs for positioning and styling and Better UI Layout Support. These requests come from the widget developers within Ajax toolkit projects who design Ajax-based UI controls by taking advantage of what the browser gives them, such as DOM, CSS, images, and table layout. They often run into walls, and their jobs could be much easier (and performance much faster) if the browser included a small number of additional (relatively small) features, such as stretchable layout (e.g., flexbox in XUL) and the ability to determine the location and size of objects (and containers) within the page.
Performance – The top vote-getter in the performance area was HTML DOM Performance in General. In discussions over the past year with leading Ajax developers, the moderators believe that the Ajax community wants performance improvements in all aspects of the browser runtime, including DOM, JavaScript, and rendering, but DOM performance was singled out by the community because Ajax toolkit developers have found that DOM access is the top performance barrier today. The key high-level message is keep making the browsers faster, but even blazingly fast JavaScript isn’t going to help if making DOM calls is too slow.
Rich text editing – Various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser. The takeaway is that the Ajax community wants Better Support for Rich Text Editing , and hopefully one of the browser teams will push the envelope in this direction and send standards proposals so that the other browsers can also provide this functionality.
Comet (server push) – Two of the top vote-getters were The Two HTTP Connection Limit Issue and Persistent Connections Issue. The underlying requirement is that many Ajax applications, such as dashboards, require an efficient and robust mechanism for having the server send data to the client on an event-driven basis. Today, server push in Ajax is often accomplished using “Comet” techniques such as long-lived HTTP connections, but the Ajax community would prefer if server push was a native browser feature.
Video and Audio – Video and Audio also receiving strong support, coming in as the 10^th-most requested feature.

5. New Features (too late for voting)

Participants identified the following 6 new features, which were added to the wiki too late for the voting process, which means that we were not able to poll the community to determine relative importance versus other features:

6. Next Steps

The next step is to communicate with browser vendors. We have had calls with some of the browser vendors such as Microsoft IE team during Phase I. OpenAjax Alliance will try to get in touch (or continue) the dialog with browser vendors to convey what the community is looking for.

7. Conclusion

Ajax is becoming at core for developing web applications. The stake associated with Ajax runtime environments is higher than ever.

The open community process works. Despite various challenges, the community demonstrated strong interest for a better ecosystem for Ajax going forward.

The list of feature requests makes a lot of sense from the web development community point of view. They range from security, performance, Comet, CSS, etc. Some of them do overlap with features that are being specified by other initiatives such as HTML 5 and SVG. They will empower web developers to deliver much better applications over the web, and significantly enhance the power of the web.

Although we have identified the top 10 feature requests, the browser teams should study the entire list because all features might represent critical requirements or are just great ideas for advancing the Web. It is possible that some of the features that received fewer votes are critical to a particular but important niche or that only a subset of participants are close enough to the bleeding edge to see an impending but critical requirement.

It is worth pointing out that “vector graphics” is voted as the top request. It is time for all browser vendors to support standard vector graphics. Vector graphics support is highly scattered today. Open standards such as SVG and Canvas are supported by some browsers but not the others. The community is clearly demanding this feature, putting it even above security and performance.

8. Acknowledgements

The following is a partial list of people whose contributions made significant difference for this initiative.

Alex Russell (Dojo Foundation), Jack Slocum (Ext JS), Joe Walker (DWR), Douglas Crockford (Yahoo), Dylan Schiemann (Dojo and Sitepen), Bertrand Le Roy (Microsoft), Kris Zyp (Sitepen), Andrew Dupont (Prototype), Sam Lie (jQuery), Yehuda Katz (jQuery), Krishna Sankar (Cisco), Brad Neuberg(Google), Greg Wilkins (Webtide).

OpenAjax Runtime Task Force members are: Coach Wei (Chair, Nexaweb), Bertrand Le Roy (Microsoft), Jon Ferraiolo (IBM), Adam Peller (IBM), Haik Sahakian (Fidelity), Ted Goddard (IceSoft), Simone Fabiano (LightStreamer), and Krishna Sankar (Cisco).

Special thanks to Jon Ferraiolo (IBM) for coordinating and implementing the site infrastructure that made this initiative possible.

AJAX & RIA Journal Special: Results of OpenAjax Alliance's Browser Feature Wish List

© 2008 SYS-CON Media