JD on EP

During the first panel block I floated among the five presentation, scanning the thoughtfully-provided paper handouts of the speaker's slides. Each session, aside from the crowded "intro to ajax" presentation, seemed to be an "intro to the framework I developed with my friend" type of affair.

Two prior themes at the conference, "Don't code JS yourself, use a framework" and "Nobody has really figured out how to make different JS frameworks work with each other", seemed to collide with the "Hey, lookit what I can do!" impression I got from watching multiple framework presentations at once. To handle differently-implemented XHTML/JS/CSS/HTTP/CPU/etc systems in multiple browsers, the advice is to use someone else's library so that *they* can worry about browser differences.

This can work for creating a project, but runs into problems for the lifecycle maintainence of such a project. A crew who tries to rev the website 18 months later can easily be faced with the choice of learning the framework "those other guys" used at initial development, or chucking it and using the JS frameworks they already know.

(Sun had some type of press release yesterday about reconciling various Ajax/JavaScript frameworks, but my time has been constrained and I haven't been able to study their work yet.)

Result? The "browser differences" problem looks like it's being pushed up the stack, into the "framework differences" problem. Techies tend to have a weakness in focusing on initial development, and ignoring support and maintainence costs... we tend to be fascinated by Bright Shiny Details, and get excited about new things we can accomplish. I could easily be wrong in this prediction, but the sense I got at this conference was that there was a looming problem in sustainability that remained unaddressed by the speakers I heard.

Second takeaway: JavaScript developers tend to be unaware of what their audience's current browsers can actually do. The focus of conversation was on what developers touch -- what to return from an XmlHttpRequest, how the frameworks differ, the syntax of different prototype functions -- not on their goals of what they want to accomplish

During the first evening's keynote the hosts described their ideal browser of the future: high-performance graphics (with SVG, CANVAS, and videocard acceleration mentioned)... better debugging and memory transparency in the varying runtime environments... faster logical processing, possibly with just-in-time compilation of neutral web code to machine-optimized code... larger local storage than browser cookies for cross-session persistence.

In his Thursday morning session, Adobe staffer James Ward showed that these are already available to JavaScript control in today's varied browsers via Flex-Ajax Bridge, and then he rattled off half-a-dozen more highly desirable features too (server push, binary sockets, cam/mic control, realtime conferencing, all the rest).

During Kevin Lynch's Thursday afternoon keynote, I stayed in the back of the room, watching audience response, learning from them. The room was full -- not what I expected after a late night, a lunch, a break, and a gorgeous day in San Francisco. A half-dozen people left when Kevin discussed how Flex Builder and Flex Data Services paid for the development of the free framework, compiler, and clientside engine, but otherwise I didn't see much audience movement until the Q&A opened up. There was an average of one person per table with an open computer... seemed low. Heads were pointed forward -- the first time I really saw people converse with others at their table was after Kevin showed how to take standard Google Maps and make it a collaborative experience, with synched viewing and drawing overlays and webcam conversation while choosing a route together. Intra-table conversation spiked during the "online mortgage" demo when Jaime Austin appeared in the support cam and they filled out the form together -- I retain one mental picture of a guy smiling at two others at the table, slapping his head in an "ohmygosh!" moment.

(But then again, in a quick blogsearch last night I read comments like "Flash, bleh, onto the next session", so sample size needs to be checked.)

Your browsers can do more than you think, that's the second main understanding I achieved at this event. The abilities Ajax people say they want most are already available for their practical use today.

More:

Most of the paying attendees I spoke with were trying to solve current work problems. This was not an abstract conference for them -- I met few who were merely curious about Ajax or thought it the next big thing, not a "Web2.0" type of bunch -- when asking attendees why they invested in the conference they would usually start by talking about a specific project at work which needed a better interface.

I saw more situational blindness than I expected... people having difficulty walking without colliding into others... suddenly stopping or veering without first looking around themselves... rearranging chairs to block pathways and doorways, obliviously. Maybe it was jet lag, I don't know, but by the end of the day I was wondering at how so many seemed unaware of what was going on around them.

I saw more emphasis on low-level detail than I expected: the indeterminancy of how simultaneous XML requests are handled... differences by version in JS object-construction via prototype calls... different worldviews on whether to use XmlHttpRequest to return data, or markup, or JavaScript... a long session on how to do GMaps-style tiled panning in local script (this problem was first solved in the CD-ROM era with Director & Lingo, ten years ago)... which debuggers to use in which browsers, and how they differ... a novel Bright Shiny Detail would frequently cause a hallway conversation to veer off into a new and smaller tack.

I heard little spontaneous conversation about the problems we all face when presenting advanced media and interactivity in a document browser -- no hallway conversation about text-to-speech translation, or other accessibility, or browser bookmarks to represent applications tate, or how to get your project found by search engines -- there was a little bit about structuring data transfers for both local performance optimization and practical server load, that's as close as it got to (what I consider) the hot issues.

But the one, overriding thing I learned from my time at The Ajax Experience conference was that these people, whether they come from a Java background or a web-purist background or whatever, are all trying to solve valid problems. We're on the same path. Newspaper articles will likely try to dramatize things to increase their ad revenue. But seeing these people face to face showed me the truth, that we're working towards similar goals, and trying to bring the same types of improvements to how the world uses computers. It was good.