Adding AJAX features to browsers is pointless -- everyone will *still* need to support the old browsers, so why bother using any new features? Of course nobody bothered to vote on such a stupid question!

2.0) A vi mode for Web 2.0 <textarea> elements.

2.01) The browser to host the OS not the other, old, way around.

2.03) Ironclad web browser security.

Get AJAX out of the hands of marketers, and call it HTTPRequest again. It has become befouled.

Mine's the one with "Real Programmers do it Asynchronously" on the back...

Gosh!

How about Vim?

Ah yes, off to Paris...

Agree with the first comment. It's all well and good to get excited talking about potential new browser features for web devs to use, or the JS execution speed in Firefox 3 or the local SQLite in Safari, but the grim reality is that genuine commercial web apps will have to deal with IE6 and IE7 for years to come. Anyone who has tried to develop serious AJAX-ified apps for these browsers will know the "joy" involved when you reach a certain level of JS and AJAX complexity. By the time any features going into upcoming browsers can be depended upon, in literally years and years, I'm thinking we will have moved on to something else. Web 3.0 maybe...

They didn't ask me and i develop with AJAX day in, day out.

I didn't even know there was an AJAX alliance.

Besides what is the point in a wishlist? So we can be disappointed by how Microsoft implement half a standard then make a proprietary work around.

My wish, for existing browsers to support existing standards (in AJAX).

Until IE6 is gone from the corporate desktop, AJAX is limited and kept in the realm of nice visual candy and nothing more, and anyone who disagrees, please try and populate large areas of data in IE 6 and watch how it comes to a grinding halt. Then watch it fly in Firefox and IE7.

IE7 as an security-upgrade?, not for a large corporation who doesn't want to recode a load of activeX on its internal network.

What's wrong with these people? No-one has expressed an opinion - sure it could be that IE6 makes it all a bit irrelevant, but people really like expressing opinions. Look at Reg comments for a start.... Its just too bloody painful! Sure, we all could work our way through their system - we're note idiots, but can we be bothered? No.

As a web developer/product manager I spend probably 90% of my time on usability and streamlining user interaction - making it simple for people to do what they want to do. If you don't, then people bugger off and ignore your site. Sure, it is hard and painful, but the idea that you can get people to use a non-essential web app these days without doing this stuff is just ridiculous.

The openajax crowd clearly demonstrate they don't know the first thing about real world ajax. The result is that everyone ignores them. Sounds reasonable to me.

PH? No idea why really - OpenAjax maybe?

Hmm, let me see: Selective support for CSS 2, which has been around for 10 years with 2.1 still only a candidate recommendation.

Heaven help us, wikis took a good few years to be properly noticed.

So, what on earth made them think that a project announced to the world ON APRIL FOOLS DAY FFS!!! would generate anything even vaguely useful in a couple of months?

We seriously need a Way of the Badger icon. If this isn't a classic example of Sett Theory I don't know what is.

... NoScript!

I am actively involved in the OpenAjax Alliance and am one of the moderators for the OpenAjax Alliance wishlist.

Phil Manchester sent me email asking about why participation levels have been low on short notice. My response did not arrive to him until after his post went out.

Regarding the participation levels for the browser wishlist, actually I have been pleasantly surprised. I guess it is a matter of expectations and a matter of quality vs quantity of the participants.

When we launched the initiative, we had no grand illusions. We considered it an experiment and were unsure about the level of industry and participation we would receive in the industry. We recognized that everyone is busy and there are other forums (fora?) for making requests for future browsers. Nevertheless, we felt we had little to lose by trying, so we decided to go for it in a lightweight manner (i.e., collaborate on a wiki), where the costs to administrators and the users would be small. The pleasant surprises were: most of the major Ajax toolkits contributed to the effort, either directly (i.e., getting a login and editing the wiki) or indirectly (e.g., via phone interviews); the contributors have produced (so far) write-ups on 37 separate feature requests, which represents good technology breadth; and some (definitely not all) of the feature requests contained good depth of discussion from industry experts.

Also, other than the posts around April 13 asking for industry participation (which did indeed result in some successful recruitment), we haven't engaged in much active marketing. As I said earlier, we felt that we had good coverage among the Ajax toolkit world with the participants that we had.

We will soon (this week?) send out a second call-to-action to the industry around the browser wishlist, would might produce more participants, which is fine, but OK if we only get contributions from the people we have now. We didn't intend that the browser wishlist be a huge industry event. We just hoped that with a little effort on a wiki by some industry leaders, we could produce something that would help inform the browser vendors about what features are most important to the Ajax community for their future releases. I think we have already achieved more than we expected.

If you are an Ajax toolkit developer or an Ajax developer and you have opinions about what which new features are most important in the next generation of browsers (IE9, FF4, Safari4, Opera10), instead of taking potshots, how about participating in the effort: http://www.openajax.org/runtime/wiki.

AJAX was derived from an MS ActiveX object, and it is quite minor in the grand scheme of things. It is just about the ability to talk to a server without a page refresh. Which has been possible through various mechanisms before that ActiveX object was released.

The DOM (Document Object Model) is far more interesting, that allows you to turn a web page into an application.

AJAX was also a made up name, but not by a core developer of the technology, so in some ways there is a bit of stigma to the name once you look behind the curtain.

Really this is about JavaScript, and if you want a wish list for JavaScript it would be:

Speech, Sound, Video.

The ability to call the server is fine, but what most want is the ability to quickly add and script media onto a page. Being able to reach into a stream or buffered information would be useful.

A more esoteric feature, is to bring back the ability of JavaScript to read other JavaScript code, that is useful on a number of levels.

And JavaScript is about controlling what the browser offers, so extend the browser and JavaScript, via the API, gets more features it can use.

Standards compliance is the #1 'feature' request.

I agree DOM is sexier than AJAX, but AJAX is a superset of DOM, so AJAX gets all the attention.

Yes, Speech, sound, video (ability to embed mp3/mp4 or whatever, and seek to a particular moment in that mp3/mp4 regardless of plugin). Support for some kind of labeled cuepoints, would be lovely.

Hey, there's something called SMIL. It's an open standard for multimedia markup, and it's really easy to learn and quite flexible. And there's something called XHTML+SMIL which would allow you to mark up slideshows with music (or whatever) directly into your web pages without any scripting at all. Another open standard. How about actually making use of the specifications that have already been agreed upon years ago?

And what about a 'basic' drawing API? Line, Fill, and such. I could MOVE and DRAW on a VIC-20 (and even CIRCLE on a ZX-Spectrum) in 1982, but the Beta browsers of 2008 seem uninterested in such 'primitive' activities.

Oh yeah, javascript needs a more formal OOP implementation, with classes and type security, instead of all this loose-living prototype stuff which almost nobody uses.

Well, you could build it on:

http://www.davidbetz.net/graphics/

(drawing pixels in javascript) Not that _I'd_ want to deal many pages like that.

As others have said, the best approach to Java(_we_control_the_vertical)script is noscript.

I would like to see standard API for a Javascript based mediator that runs in the browser. This would be used so that widgets from the various vendors and OSS developers could collaborate in a predictable way.

For example, a standardized mediator could dispatch a node click event from my ExtJS tree component and dispatch it to refresh my ComponentArt grid. Today, I must write this glue code myself.

What's the point anyhow? Once Silverlight gets fully baked, who wants to develop with Ajax any how? Frankly, it's a big pain in the pooper, when compared to Flex and Silverlight.

... why would a browser need to support AJAX? Isn't that something you use to clean kitchen surfaces?

Didn't know home automation has come that far.

I think we can all agree that security is a significant concern for asynchronous web development, as it is with all forms of development. I also think it's somewhat naive to believe that AJAX (or HTTPRequest, whatever your flavour of verbage) is going to go away or somehow be "replaced" by proprietary technologies like Silverlight or Flex. (I'm always wary of packages that attempt to be all-in-one solutions, especially for a technology that's immature and under active developmental scrutiny.) I would like to see developers go back to the core of what it is that makes AJAX so useful, and then re-invent it under today's vision. ...then make it backwards compatible with IE6. Just kidding.

To me, AJAX development still seems hackish and awkward. Far from the elegant code we can produce to support a desktop application. Even with support from the great JavaScript libraries made freely available by selfless web idealists, we fall short of the seamless integration and robust development practices I know we are capable of. Maybe we don't even need to re-invent AJAX - just re-invent our approach to it. We shouldn't have to spend our time figuring out where our client-side application is going to link back to our data access layer, or how the heck we're going to make it work in Internet Explorer. All those little things should be inferred from our interface design. How they are inferred is of little concern to me in the long run, so long as the end result is cross-browser compatible, and continues to support major browser versions. What I wish for is a framework that allows us to develop single-page rich Internet applications using a familiar, robust language for the back-end, such as C#, where we aren't concerned with server/client communication, but can focus entirely on the business model. Throw in a serving of generated code with a sprinkling of sugar, the ability to re-use client-side JavaScript components, good extensibility, and a slick set of graphics, and I'd be hooked.