Wednesday, May 10th, 2006
The Ajax Experience has begun! Ben and Dion just gave their opening keynote, and we’ve now got the following panel taking questions from the floor:
- Stuart Halloway
- Glenn Vanderburg
- Brent Ashley
- Alex Russell
- Greg Murray
- Brett McLaughlin
- David Geary
- Joe Walker
Here are some notes from the panel …
Accessibility – Doesn’t seem too easy with Ajax
Joe: Lots of issues. Some can be ignored in some circumstances.
Audience capabilities – What browsers are people using?
Alex: Dojo falls back to standard HTML if no JS present, that’s what we view as the way forward.
Glen: Most frameworks do a good job at backward-compatibility. e.g. Rails as well as Dojo.
Brett: It’s about, “What do you care about?”
Greg: At Sun, have to worry about selling to the gov’t. “508 compliance” – can’t ignore accessibility.
Is the browser ready to be used for productivity suites, all day long?
Joe: Worked on such an app. There’s always issues with browsers. Helps that you can sometimes pick your browser.
Stuart: IE sticks out in some ways, but these issues are always going to be there with or without Ajax.
Glen: Early apps were toys, but still some work to be done, and memory model is a big part of that. Installed base of IE will take a long time to outgrow these issues.
Brent: Not just memory model. More evolution needs to be had with XMLHttp. Alex Bosworth wrote the other day above this, e.g. have to build in sequencing. readystate=3 doesn’t fire properly.
Stuart: This illustrates importance of using libraries. A lot of books emphasise building by hand to avoid being tied to a particular library.
Brett: However, still need to have that info, e.g. if you don’t know what readystate=3 means, you’ll eventually run into a problem.
Ben: Need better tools to measure memory etc.
Previously 90% of programming on server, 10% on client. Where is it today and where will it be in a year?
Dion: Sometimes blends, can’t always say “this is on the server”, “this is on the client”.
Alex: Browsers can now do state in the browser, so we should let them. Pendulum swinging slowly back to client.
Glen: We’ve seen an explosion of power on both sides – server and browser. Standard patterns of usage have evolved quickly and there are frameworks to take care of this.
Joe: Discovered that it makes the …
Alex: The fundamental problems with browser security and web security haven’t changed in the past 5 years. Cross-site scripting still the issue etc. Ajax itself doesn’t change things, cross-domain might, but there’s not much news here.
Brett: Ajax exposes holes more readily. Can’t think of a problem that’s truly Ajax-specific, the short version is still Don’t Trust the Client.
Brent: Douglas Crockford’s JSONRequest proposal – no exchange of cookies, thus reducing cross-domain risk. Also Flex has crossdomain.xml file that a site can have in its root, that says “it’s okay for these sites can access me via Flex XML sockets”. Let’s start collaborating to free us of constraints like this, like the JSONRequest proposal.
Dion: See SQL Engine posted to Ajaxian (the dailyajaxian post).
Various: Vi, Vim, Emacs …
Dion:â€ Designers would be using similar kinds of notation as before.
Glen: We’re starting to see some encouraging things, but there’s no one tool that does everything. Mac: Safari Buddy. Firefox: Firebug, etc. These do 30-40% and are overlapping, but altogether leave another 30% that nothing is covering. Expect we’ll see a lot happen in the next couple of years.
Dion: If only there was a site that talked about the new stuff as it happened ;-)
There’s a lot of cool stuff moving forward, but what will we do about IE?
Joe: To an extent, Ajax is a hack, so we shouldn’t get too purist about it.
Alex: IE7 is a significant disappointment. We should be making a noise about it.
Ben: Good news is MS does appear to be listening. The huge installed base will be a big problem.
I don’t like how many Ajax apps use innerHTML. Not because of standards compliance, but because you don’t know exactly what’s going to happen. But we do use it because there’s often no other way to go. How do you use it, what would you like to see?
Brent: DOM Load and Save spec is a good W3C standard that offers a good solution, but possibly only Opera has implemented it.
Alex: I hope we have consistency with these other things too, XMLHttp, etc.
Which framework’s going to win?
Alex: Peaceful coexistence is probably the right solution.
Stuart:â€ Remarkably easy to combine them together.
Brett: It’s a classic open-source situation, probably don’t want a winner, because do better with them competing.
Comment about W3C Standards emerging
Brett: Good if standards are there to help, not if they’re telling you what you should do.
When I talk to managers about client-side scripting/Ajax, always get the same objections: accessibility and search engine optimisation.
Joe: Must be careful about getting a black mark from Google. In many cases though, rich Ajax apps are often not the kind of thing you need to make available to spiders, etc. Would you want a search engine to crawl GMail?
Comment about combining frameworks. Would be great if I could use feature X, but I have to swallow the whole elephant? Are we building up walls?
Joe: Aware of these issues, there’s definitely the intention to work with them.
Alex: Mochikit and Dojo coexisting is probably the best example I can think of. Can easily work with one or both.
Aren’t MS the ones who invented XMLHttp, etc. Shouldn’t we hear more about Atlas?
Ben: We (Ben and Dion) don’t have a bias against MS. Working with them, etc.
Greg: Sun’s looking at it with J2ME group.
Posted by Michael Mahemoff at 11:21 pm