Friday, May 12th, 2006

Ajax Experience Day 3: Panel

Category: Firefox , IE , The Ajax Experience

With key people present from Mozilla and the IE team present, today’s Ajax Experience panel is focused mostly on browser issues. A rare opportunity for Ajax developers to talk directly with the people who define our day-to-day constraints. As I write this, it’s thirty minutes after the panel finished and there’s still a decent crowd in the front talking to the speakers.

Alex Russell – Dojo Toolkit
Stuart Halloway – Ajax/Java/Rails Consultant
Brendan Eich – Firefox Lead
Laurel Reitman – Microsoft IE Lead Program Manager
Douglas Crockford – Yahoo!, creator of JSON, general JS evangelist

Here are some notes from the panel…

Why no byte code?
Various reasons. Compiler is a hassle. Can send malformed bytecode and make it take a long time. Was experimental in 1995.

SVG Integration in IE7?
Laurel: No, won’t make it, but we’re looking at it.

Ben: What would you like to see?
Brendan: DOM ?standardised. Local storage – offline in first-class, cross-browser, way.
Laurel: SVG and canvas – heard a lot around the conference. Also heard a lot about offline storage, important too. CSS spec. Accessibility space – Mozilla has done some great work there.
Stuart: Would be really cool to have a test suite that verified the browser does what it’s meant to be doing. Some browsers have done better than others in adopting agile/testing practices – formally having those things would help show which browsers are doing well at standards compliance, etc.
Laurel: Not just standards compliance, also what the community’s asking for.
Brendan: Sure, there’s a difference between real-world standards and those written by W3C etc. It’s not going to be downloaded with yout browser, but something we’d like to collaborate on.
Alex: Safe JSON (de)serialisation. Increasing 2-connection limit would make a lot of things possible. Next version of Windows: when a system builder, or someone bundling windows, has to ship the latest version of IE. Also fast DOM queries.
Laurel: Key word – Security. (wrt JSON)
Brendan: On the map for JS 2 – Safe (de)serialisation with JSON.

What have you given up hope on – impractical or will take 10 years?

Alex: If you’ve been coding JS for a long time, (you feel like anything’s possible) :-).
Laurel: Good to be here at the conference, hear what people want.
Brendan: It’s difficult to have security and power. We need better security models, not just a dialog model that says “Do you trust XYZ.com” becausse most users ignore it.

Robustness of applications

Douglas: Run Yahoo! Mail Beta all day in FF, doesn’t fall over. But others fall over quite readily.
Laurel: Hard to answer, depends on the implementation.
Brendan: Have to test long-running scenarios as well.
Laurel: Agrees. We do stress testing, monitoring of bug reports from end-users, etc.
Stuart: AFAIC if you don’t have a test, it doesn’t exist. As developers, we have a responsibility to meet browser manufacturers at least halfway, produce automated tests … Obviously it’s extremely hard to get coverage (if test takes hours to run). We do have tools like Selenium etc that will help us make it more obvious by way of automated tests where the problem lies.
Brendan: We’re using JSUnit, want to look at test strategy. Moz also looks at bug DB etc., please contribute.
Alex: Nice to grep source of Firefox.
Stuart: MS has a ton of v smart people and a long history of watching industry grope towards something and then jump in. Suggests MS will become a huge open-source provider. Other possibility is that they’ll fail.

What about accessibility and which toolkit should you use? (Prefaced with “I have two questions no-one has asked yet” as everyone keeps asking these at this conference)
Douglas: I’d like to see better affordances in the browsers indicating what its acessible attributes are.
Laurel: Great work done by IBM and Mozilla, we’re seriously looking at it.

Legal or corporate battles on continuing to work together more

Laurel: Patents are one of the biggest problems.
Douglas: Time to close the US patent office (Applause).

In the future, much higher expectations about what websites can do – will mom and pop be able to do it?
Laurel: Toolkits helping to deal with X-browser incompats, making it easy to do
powerful things.

FF lots of bug fixing at the same time as new stuff. Innovation in IE?
Laurel: Can safely say it’s not going to be five years before the next big improvement in the browser. Expect to see a lot of good work…

Alexa tracks popularity by page clicks, but that doesn’t happen much with Ajax.

Douglas: We now have a lot of info about what was going on in the page. But don’t have an accounting system for everyone, what needs to happen.
Brendan: (From another question) FF 3 – Q1 2007.

Just-In-time Compiling

Brendan: Looking at advanced optimisation techniques. ?Hard JITting is hard without type info, which isn’t there now but will be there in the future. Garbage collection difficult – everyone has to watch out for, ongoing area of R&D.

Anyone looking for a complete replacement of HTML, JS, etc. Flash?

Alex: Lots of people are trying, I wish them luck.
Brendan: Flash is a plugin, plugins are second class, that won’t change. If Flash were open or open-source, would be merged in ways that would be wonderful, but don’t think it’s going to happen. W3C people trying to standardise in that area – MS for XAML, FF for XUL, etc. Different languages, different runtimes, IP considerations and compatibility constraints.
Laurel: Even with web today, can use notepad/vi and create some compelling things.

Exposing hooks for IE to build any GUI with it?
Laurel: Can already do it, e.g. AOLExplorer.
Brendan: Sure, a lot of hooks in IE. With Gecko, can write your own ?app.

Is anything we, the users of your tools, aren’t doing which you wish we
would take advantage of?

Stuart: Would be great to see people picking toolkits. Taking advantage of JS as a language, prototype-oriented etc.
Brendan: Functional programming is trickling down – it’s a better style for a lot of JS. I’m not up with the latest JSAN.org

IE7: Fix for Select box, overlapping
Laurel: Select control, can now see over it now. And transparent PNGs. Native XHR.
Ben: Issues about dealing with IE7?
Alex: At one point, NS was wearing the crown, now it’s IE6. From the perspective of a scripter, IE7 is not significantly different. In the same way the CSS community made the point that IE6 wasn’t good for CSS, we said the same about IE7 for JS.
Panel comments about talking to vendors, it’s important to give feedback, etc.

Mashup support

Laurel: Biggest challenge is secure cross-domain.
Douglas: Next thing will be third-party widgets running on the same page, the model doesn’t partition these things.
Brendan: Still under research, pushing towards it over the next couple of years. We don’t sandbox enough right now.
Stuart: Even developers don’t understand the security model within the browser, how much authority you give it. Let alone general users.

Combining frameworks
Stuart: Don’t want to end up where everyone using WebWork must use Dojo, everyone using Rails must use Scriptaculous etc. Should be able to pick things on features, mix and match. It’s not actually hard to combine these things together. Would be 10 minutes of work to fit Scriptaculous and Prototype with Dojo packaging, maybe let’s at least agree on using Dojo packaging.

DOM Compatibility

Brendan: DOM isn’t transparent

Toolkits – Seems like could incrementally keep raising the bar, agree on a common subset of syntax, etc.

Alex: Rate of change issue. e.g. DWR’s use of $() (Joe Walker later clarified this at the panel – not DWR’s issue, just the overall problem about ordering of scripts, overriding issues etc). Even if we decide on something, end up with serious versioning issue. If something’s really really important, maybe should standardise on ecmascript or DOM bindings.
Brendan: XHR is being standardised. Took C a long time to get through various API wars etc. Kind of early.
Stuart: Hard to standardise. e.g. Many people haven’t been exposed to functional programming, others have been but don’t like it. So how do you standardise when people don’t agree on the basic matters of programming style?

Competition is good. Ajax benchmarking initiative?
Brendan: Benchmarking is tricky. The browsers always game it (specific benchmark). I’d like to see a developer-driven effort.
Laurel: Need a broad set of examples, things people are really doing.

MS has an incentive not to innovate to much with IE
Laurel: Can’t speak for executives, but my role on the team is to make IE good, etc. I think both can peacefully coexist. BTW We’re hiring. Investments on Windows Live etc show MS is committed to the platform.
Brendan: If I were Adobe, I’d be pretty nervous. (Might expect action too if web apps take off.)

Ajax Experience Day 3: Stuart Halloway on Ajax for Rails

Category: Prototype , Ruby , The Ajax Experience

Notes from Stuart Halloway’s talk on Ajax support for Ruby on Rails at The Ajax Experience.

Who here is using Rails in here? About 10 people.
Who here is considering using Rails? Half of the room (about 40 people).

For a while, Stuart has been giving two bids to clients: one for Rails, one for Java. Every time, client chooses Rails.

Stuart has a great presentation style for something like this – since there are so many concepts here – Ruby, Ajax, Rails, Scriptaculous – he reasons it’s difficult to delve too much into the theory, so he focuses on building live demos and taking questions as they come up.

Stuart demoes rapidly building a GUI with scaffold. In 5 minutes, we’ve built and demo’d this app to manage a list of users. BUT it’s trivial, not customised, and not Ajaxified.

Q: What platforms does Rails run on?
A: All major platforms. There are a couple of related projects to Rails, which have had a big impact on its development – InstantRails (Windows Rails in one click). Mac – Locomotive, same thing, though many Mac users tend to install Rails using Gems.

All the source code for today’s pres and much more at http://www.codecite.com/project/download/ajax_labs.

Demo of Active Record.

View: Controller sets up attribute. Demo of autocomplete.

Searching demo.

Q: Tied to using Scriptaculous?
A: No. Can use any, but because Rails has helper libraries, much easier. I’m worried about this – I’d like to see an aspiring programmer write helpers to let you work with Dojo. Existing is already “Good Enough” – we have a danger that Dojo/Scriptaculous/Mochikit is “good enough” and won’t be able to switch around.

Q: What if we could make helper methods generic?
A: That’s kind of what I’m describing – implementation would be different, but with the same name.

Q: Versioning issues with Rails and Scriptaculous/Prototype being kept out of sync?
A: No. (A) Because projects work together; (B) Plenty of automated testing. There’s a rake task to “updatejavascripts” that will ensure your JS is current. Would only be a problem if the developer/organisation wasn’t willing to move forward with both at the same time.

Sorting Demo

Drag-And-Drop Demo

Server-Side Validation input demo

“DivDows” Demo – floating windows-like divs. Relevance (Stuart and Justin’s company) will be rolling out an open-source project in about 60 days to support this. Currently Javascript-based, as shown below, but will eventually be able to use only Ruby.

win2 = new Window("show_win_" + user, {...})
  win2.setDestroyOnClose();
  win2.show();

Discussion on RJS and how useful
RJS: page.alert(“someMessage”)
Sometimes, no need – the RJS feature is purely there for the library to use internally, no reall reason to use it. Why use page.assign() when you could just set a variable?
Rjs Templates: How much to use?

For more info:
www.codecite.com “Ajax Labs”
Mail Stuart
blogs.relevancellc.com

Ajax Experience Day 2: Keynote from Scott Dietzen (Zimbra)

Category: The Ajax Experience

Notes from Scott Dietzen of Zimbra at The Ajax Experience. Scott Dietzen was formerly CTO at BEA and now CTO at Zimbra, which produces Ajax-rich messaging and collaboration tools for the enterprise.

Zimbra – Anticipated some of the benefits of Ajax, e.g. rich UI, zero-admin,
etc. But didn’t anticipate some other things: SOA/Mashups, Ajax authoring, that it would be the RIA winner (Google, MS, Yahoo, etc), ease (at the time, seemed really hard to do it).

Zimbra – not for everyone, but a good fit for Java programmers.

Demo of Zimbra’s drag-and-drop.

Zimbra = “Pure” Ajax (MM – AKA “Ajax Deluxe”, “Client-SOA”). No HTML is provided by the server. More like a Java app than most web apps. Result is “husky” client 3-tier architecture. All UI on client, with server-side Java code for UI operations.

Sure, most existing web apps are fine just to be augmented with Ajax. But Zimbra had the luxury of starting from scratch.

COBOL wasn’t so different from the web: Mainframe COBOL program handling UI, business, data logic, against green screen client. Then, we had client/server, where most of this moved into the client. But when the web came along, pushed those things back into the server. Now with Ajax, we get to decide on the partitioning ourselves. Various strategies are possible.

“There’s a special place in heaven for whoever had the patience to get all of that Javascript right”. Paul Ambrose, Weblogic founder on Zimbra. Today, Ajax has become an order of magnitude easier than it was back then.

Toolkits should be abstracting all this browser-specific stuff.

Zimbra team got together with IBM team to extend Eclipse to support authoring. Others too, e.g. Dojo and OpenRico. Led to Open Ajax Initiative. Shared visionj: Ajax ought to continue working across browsers and across desktops (ie. OSs).

MS stack (Atlas, Visual Studio) is already great and a safe bet for efficient dev.
Zimbra/Kabuki (Zimbra will soon be Apache Kabuki), and also Dojo and Scriptaculous approaching critical mass, will be very hard for proprietary vendors (other than MS) to get a foothold.

Another challenge: browsers weren’t designed for this kind of punishment – memory leaks, performance gaps.

Complexity of authoring and debugging. “Deeper” Ajax still requires OO UI skills.

Demo of mashups in Zimbra. e.g. Phone number inside an email – shows owner’s details. Address in email – pops up map image.

ALE = Ajax Linking & Embedding. Authoring. Can easily go in and edit content. WYSIWYG authoring.

Practical Ajax Tips

Use an Ajax toolkit. Contribute too if inclined.
CSS is your friend. Parametise app so can re-skin without going into JS internals.
Use JSON (and XML). XML parsing in JS is expensive.
Use async network programming.
MVC paradigm worked for us.
Compress – jsmin saves ~1/4x. Gzip ~3-4x.
Take testing seriously. Mercury’s QuickTest-Pro (QTP). Also JSUnit etc.
Pick your fights.
No such thing as secure client-side logic.
Architect community review XML/SOA bindings.
Dedicate top UI OO talent.
…

Sweet Spots

Pick your fights – don’t do Ajax everywhere.
Richly interactive UI desirable
Combined with web look & feel and deployment
No client-side data/resources.

Ajax isn’t a business model, it’s the means and not the end.

Scott asks the audience, “What is the biggest problem with Ajax?” Everyone in the audience calls out different things – accessibility, etc. Scott: Close, but the biggest problem is recruiting – interview 40 people for every hire. So let’s figure out how to make it a lot easier.

Ajax Experience Day 2: Alex Russell’s Dojo In Depth

Category: The Ajax Experience

Notes from Alex Russell’s “Dojo In Depth” talk at The Ajax Experience, continuing on from his Intro To Dojo and covering more advanced topics.

Other Talks at the Ajax Experience

Dylan on Events, Brad on Storage

Javascript

“Javascript is not a bug that needs fixing.” Dojo builds tools that help you get things done with this great language.

Q: What’s AOL’s role in Dojo? (Alex mentioned AOL has contributed code.)
A: Dojo is run by a non-profit organisation. AOL is using Dojo, e.g. ?APages, so have a stake in making it good, feeding back, etc.

Animation

dojo.lfx.propertyAnimation. With a single call: “I want to animate those two nodes, over half a second. Move their height from x to y and their opacity from a to b”.

Easing.lfx.easeIn, easeOut, easeInOut:

Chaining (touched on in previous session).

Q: Can say “go to half size, certain percent, etc.”
A: Not yet.

Q: Can do animation loop?
A: Yes, it’s a new feature.

Build System

It’s OPTIONAL. If you pick up a standard build off the distro site, you’ll never need to see it.

Optimisation Strategies

What matters most is perceived speed, not actual. Ajax is in some respects
slower, but feels faster.

Cache. Pragmas etc.
Fewer requests Can talk to 2 domains at once using HTTP 1.1 + ?
No synchronous/blocking requests
Reduce size “on the wire” (gzip)

Build

Q:What is a shim?
A: Use it to make buildings level. Little pieces of wood to make it level. Virtual equivalent is things to make it portable, regardless of details. (MM – “an equaliser”).

Q: How to get tests running?
A: There’s a test dir. Anything with test_* will be run. Inside it, each
function is called test_…().

In this demo, runs under spidermonkey. Could also run against rhino.

Was previously using JSUnit and had wrapper for them. Now the wrapper has evolved to its own implementation, not using those anymore.

Dojo is pure JS. Has host environments (?Rhino etc)

Where Widgets Come From

Web development isn’t best-case situation. Ideally we’d be using Cocoa etc etc, but we have to make the best of what we have.

Should be just as simple to declare for SVG etc as HTML. Widget system not HTML-specific. When declare a widget the first time, Dojo searches through namespace to find the most specific widget available for this environment. dojo.widget.html.FooWidget, then searches dojo.widget.FooWidget, dojo.widget.HTMLWidget, dojo.widget.DOMWidget, dojo.widget.Widget. (That’s the inheritance hierarchy).

Widget Construction. There’s a standard call sequence: create(). satisfyPropertySets() … initialize() etc. These are implemented by each widget.

Based on templates.

Q: How are templates loaded?
A: In sequence.

How many widgets can you realistically have?
A: Spent a lot of time optimising widget system. Per-widget rendering time is
about 10 milliseconds. That figure tends to scale up linearly except on IE. ie
100 widgegts in about a second. Look at e.g. renkoo for real-world usage of
widgets.

Fastest way is often to build an entire page as the widget. ie html, head,
body, the whole thing. CSS referenced from the head in the usual HTML way.
dojoattachpoint is actually embedded in a node somewhere within the body. (It
doesn’t have to be the root of the whole thing.)

Cross-Domain IO

Standard Ajax XHR calls are pretty secure, can’t do anything couldn’t already do. But Cross-Domain is more dangerous.

dojo.io.ScriptSrcIO makes JSON calls, supports JSONP.

Yahoo’s been great about exposing services as JS, but all on different services, wanted unified interface: dojo.rpc.YahooService

Q: What is “defer”?
A: Continuation passing style for languages that don’t support it, based on Twisted Python concepts and borrowed from Mochikit.

Now have Cross-Domain Dojo. Asynchronous (was previously loading packages synchronously). Can load all from one site. More work to configure.

Q: How does this Cross-Domain stuff work?
A: By adding a Script tag dynamically. Took a while for Safari to implement, but can now do it.

Q: How does this handle different Dojo versions?
A: Working on it.

Performance

Fire up Renkoo, view source. Only around 50 lines because using all based on Dojo widgets.

Load modules only when needed.

Ajax Experience Day 2: Alex Russell’s Intro to Dojo

Category: The Ajax Experience

Notes from Alex Russell’s Intro to Dojo at The Ajax Experience.

Background

JS alone doesn’t give you much – it’s defined by the environments it runs in.
“At the mercy” of them.

Dojo provides a single flat interface for these things.

Dojo: Set of layered interfaces. Can use some or all.

Licensing: Can I use Dojo in my apps? YES. Ideally would be in public domain, but legal issues such as disclaimers of warranties. The foundation licenses it under BSD or AFL. AFL even more liberal – essentially, only have to honour copyright, not even include notice.

PACKAGING

Bootstrap and package system. Almost always see “dojo.”. dojo.require etc.

Can say “I need this package”. Other dependencies will then be pulled in automatically, and in correct order.

When pull in “dojo.foo.*” using dojo.require(“name.foo.*”), will try in this order:


http://.../dojo/src/foo/__package__.js

http://.../dojo/src/foo.js

http://.../dojo/src/__package__.js

...

Number of HTTP connections is often a greater issue than how big the files are. So Dojo lets you pull everything into a single file, one connection to download all content.

Builds: Get compressed version for speed and uncompressed version for debugging. These features initally came about from Dojo developers’ own needs. Optional – can

Q: If only want to use the core Dojo package system, how can I minimise the footprint?
A: [Alex demonstrates building it]. End up with bootstrap.js, loader.js, hostenv_browser.js, bootstrap2.js. Compresses to 15kb dojo.js, which gzips to just 5kb!

Q: Making your own packages?
A: Yes. [Alex demonstrates jotspot package and Rhino]

Q: Using Rhino/Spidermonkey
A: Yes. …

Language Utils

Including dojo.lang.isString etc. “false”, “undefined”, “null” in basic Javascript evaluate similarly, so dojo.lang.is* gives you a nice test to determine. Another eg.: Is it array-like or an array? (“arguments” given to function isn’t an actually array – has length, but not push pop etc.)

The handiest dojo.lang packages (Alex’s favourites highlighted): forEach, map, declare, hitch, extend, mixin, setTimeout, delayThese, curry, assert.

[Demo of hitch] The variable “this” is magical – always points to the object that the function is being run as part of. “this” is kind of promiscuous. hitch lets you run a function as part of a particular object (bind it), so it potentially changes the meaning of “this” inside the function.

Event System

“Like crack for web developers”
Runtime AOP.
Similar to hitch syntax. Bind dojo.event.connect

> dojo.event.connect(“before”, foo, “bar”, baz, “thud”);

Now before foo.bar() is called, baz.thud will be called.

Q: In an event system, how do I pass the event object?
A: In standard JS, apart from IE, event is always passed into event handler. In Dojo, it’s always passed in. Still respects standard W3C approach of preventing bubbling etc.

Q: What does “this” refer to?
A: Same as if was connected by hitch.

Q: Can I build cyclical connections?
A: Yes, but bad. You’ll know it due to app hanging. No cycle breaking built in to Dojo right now.

UI Utilities

Packages: io, html, style, dnd, ldf, dom

io: ie. Ajax remoting.

dom: Why doesn’t W3C allow insert at front? That’s the kind of thing in dom.

Remoting

dojo.io.bind() is an abstraction for remoting, not always XHR. bind() lets you swap in behaviour for a particular implementation. Submits forms for you. Handles text encoding (i18n).

ScriptSrcIO package: Brand New.
Can append script element asynchronously. (MM – On-Demand Javascript). Uses JSON-P. Yahoo’s exposing their APIs with JSON. This new package makes it really easy to call them.

“Isn’t an HTML form just WSDL for REST?”

Drag-And-Drop

Not just referencing DOM nodes, but higher-level components.

DragSource, DragObject, DropTarget

Animation and Effects

dojo.lfx.wipeOut(“foo”, 300);

dojo.lfx.fadeOut(["foo", "bar", "baz"], 300, dojo.lfx.easeInOut).play();

Q: Could use chaining and “play” concept for *anything* asynchronous, to chain
things together.
A: Based on Mochikit, there’s chaining functionality available. (“?defer” API)

Q: Can run partial animation?
A: Yes, can say “go up to a certain percent”

Widgets

dojo.require(“dojo.widget.Editor2″);

Custom Widgets

Declared in markup
Each widget usually has an HTML, CSS, and JS file.
JS file: defines the widgets – points to corresponding HTML and CSS.

Setting a Virtual Table

Category: Showcase

Oneida, an E-Commerce site, showcases a novel use of Ajax to illustrate its dinnerware. The Virtual Table lets you mix and match cutlery and plates, providing a live preview as you update them. You can also set the table’s background as well (that feature worked for me in Safari, but not in Firefox).

The table area itself is actually Flash-based, though it’s not hard to see how you could do the same thing with CSS and standard DOM manipulation. The selection of components is standard HTML and Javascript.

We recently posted about Old Navy’s use of Ajax for its E-Commerce site. It looks like these sites are wising up to the potential of rich interactivity, creating features that are genuinely helpful in making purchase decisions.

(Thanks Jesse McPherson.)

Watch Browser

Category: Showcase , Usability

Here’s a nice product browser focused on one thing: watches. Creator Edward Ackroyd explains:

http://watch-browser.com is a new interactive way to search for wrist
watches. It combines AJAX and the amazon.com watch database to provide
an easy and quick way to find the watch you are looking for. Main
features are:

- See results as to type search keywords
- Auto complete brand filter
- Minimum/Maximum price slider
- Category filter and sorting options

IO and event management is implemented using http://dojotoolkit.org/
and the price slider is from the http://www.zapatec.com/ AJAX suite.

Like Amazon Zuggest and Amazon’s own Diamond Search, it’s a good example of how Ajax lets you combine search with browsing.

The Ajax Experience: Day 1 Panel

Category: The Ajax Experience

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.
Stuart: If keep wits about you, can make it work without Javascript etc. “Ajax on the edges” rather than full-on Ajax – that’s where a lot of development will be over the next 18 months.

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.

Security concerns
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).

Tools
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.
David: Low-level tools coming fast and furious. Venkman, Javascript Shell, Web Developer Toolbar, Selenium.
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.

Mobile Ajax.
Greg: Sun’s looking at it with J2ME group.

Comparing Dojo and Prototype

Category: Dojo , JavaScript , Prototype

Jon Aquino has been using both Dojo and Prototype, and recently posted a brief comparison.

Overall, I like both. Prototype is more of a Porsche, whereas Dojo is more like a Hummer. Prototype is pure programming bliss (feels very much like Ruby), whereas Dojo is very much engineered (feels like Java) — possibly a little overengineered in some places (IFrame-based workarounds) in order to offer what no other toolkit offers (asynchronous file uploads; AJAX back-button handling; javascript “include” mechanism).

He also says Dojo’s event toolkit is the first useful application of Aspect-Oriented Programming he’s come across.

@Mail Ajax Upgrade

Category: Office , Showcase

@Mail is a mail solution allowing companies to serve mail over a web interface. With the latest upgrade, @Mail has gone Ajax. Product manager Ben Duncan says:

Features include message-drag and drop to folders, emails retrieved from the server via XML and displayed on the Webmail interface directly via the DOM. Message cache support via Ajax is included, to avoid requesting the same data from the server. Live spell-check support for composing emails via Ajax for highlighting misspelt words.

Sign up for a demo at http://demo.atmail.com.

Hyperlinks 2.0 – Ajax WTF

Category: Programming

Another Daily WTF featuring Ajax (mis)use. I know there’s a risk people will use Canvas graphics and other tricks to reinvent HTML widgets, but I never thought of this one: Using remoting, DHTML, and URL modification to build a brand new hyperlink system! Resume-Driven Development at its finest.

On the bright side, this would actually make a pretty nice programming exercise :-).

Instead of being coded in HTML pages, all hyperlinks are assigned a numeric identifier and kept in a database table. This identifier is then used on the HTML pages within an anchor tag:
<a href="Javascript: followLink(124);">View Products</a>
When the user clicks on the hyperlink, the followLink() Javascript function is executed and the following occur:

a translucent layer (DIV) is placed over the entire page, causing it to appear “grayed out”, and …

a “please wait” layer is placed on top of that, with an animated pendulum swinging back and forth, then …

the XmlHttpRequest object is used to call the “GetHyperlink” web service which, in turn …

opens a connection to the database server to …

log the request in the RequestedHyperlinks table and …

retrieves the URL from the Hyperlinks table, then …

returns it to the client script, which then …

sets the window.location property to the URL retrieved, which causes …

the user to be redirected to the appropriate page

Now that’s two-point-ohey.

Dojo Mentoring for Google Summer of Code

Category: Programming , Toolkit

Dojo is acting as a mentoring organisation for Google’s Summer of Code, with applications due in the next few days (May 8, 2006). The Google program faciliates students working on open-source code.

Summer of Code 2006 is a program that offers student developers stipends to create new open source programs or to help currently established projects. Google will be working with a variety of open source, free software, and technology-related groups to identify and fund several hundred projects over a three-month period. The inaugural instance of the program, which took place last summer, brought together 400 students and 40 mentoring organizations from 49 countries. We’d like to include even more organizations and participants this year.

Summer of Code is open to most students at universtities and colleges around the world.

Dojo has a few project ideas, including vector drawing primitives, OpenRecord plugins, Dojo-Django integration, Javascript RDF package, enhancing the Dojo Compressor, a Javascript linker which strips/obfuscates/etc, new widgets.

Thanks to Eugene Lazutkin of Dojo for pinging us. Eugene also noted Django has an Ajax-related Summer of Code project as well. I couldn’t spot any other obviously Ajax-related projects in the list, although the Mediawiki announcement has an interesting caution:

Hi folks, please don’t add “AJAX” and “WYSIWYG” back again. “AJAX” refers to a large number of small, isolated potential projects which are too small for SoC.

Ajax Pattern Screencasts

Category: Programming , Screencast

Andre @ eBusiness has released some nice, simple, screencasts illustrating various Ajax patterns at work. As supporting material for patterns, screencasts like this make a good complement to images and working demos.

These are a couple AJAX patterns that Alexei and I put together for a an AJAX business case webinar we did with Jupiter Media a couple weeks ago.

Master Detail or Drill Down Pattern

Retrieve related information on-demand.

Inline Editing Pattern and Real-Time Saving

Work with database data right on the webpage without having to post back to the server.

When a user makes a change to data, its automatically saved without the user having to do anything.

Copy and Paste Pattern

Rich interoperability with desktop apps and the browser via Auto-save and XML

Amigofish: podcast recommendation system

Amigofish is a Rails-based podcast (and other media) recommendation system by Dave Slusher, and has been running for a few months now. Rating a podcast is real easy, and will be familiar to Ajaxian.com visitors – just click on the star of your choosing. Repeat a few times and you’ll be able to receive recommendations on the site and in an RSS feed.

(Via RocketBoom)

S3 Javascript Bindings

There’s a new open-source project to access Amazon’s S3 storage service from Javascript. Creator Les Orchard explains:

There’s a SHA1 implementation for JavaScript.

The authentication scheme for Amazon’s S3 requires SHA1.

JavaScript-based apps can be served up from the S3 domain as files stored via S3.

All of this adds up to JavaScript apps hosted on S3 with AJAX-based read/write access to S3 itself.

Also: Imagine GreaseMonkey scripts using S3 as a universal configuration pool and long-term data store. (The configuration pool idea, by the way, came from Dave Winer.)

We’ve talked in the past about offline data storage, whether via Flash or future browser enhancements. Holding data in the user’s own third-party store is a third option for storage, an alternative to conventional online storage as well as offline storage that allows the user to control their own data without having to maintain it locally.

The service is ideal for Client-SOA apps, where the browser runs the entire UI and makes REST or RPC calls to the server, which responds with raw data. The app itself could presumably load from another URL, your local hard drive, a bookmarklet, or a plugin/extension/GM script (with varying levels of security risk involved).

There’s already a nice demo app: S3 Ajax Wiki. In this case, the app loads from S3 itself, which is also possible in certain situations:

Of course, since my demo wiki is sitting in an S3 bucket with a public-write ACL, everythingâ€™s open to vandalism and subversion (of the bad variety)- documents and application both. S3Ajax does allow authentication through your S3 credentials, though, so a private group with restrictive S3 ACLs could use this wiki successfully.

Documentation on the S3 library is currently limited, but you can read more about the S3 Ajax Wiki here.

Update: As mentioned in the comments below, there’s also a new online API, Filicio.us, that lets you access your own S3 file store from the browser. Right now, the Filicio.us service acts as a proxy, but it looks like they have plans for direct access to S3 in the future.

Ajax and Scaleability

Category: Editorial , Server

Billy Newport recently kicked off a conversation about Ajax and its impact on servers.

I think it’s becoming clear now that AJAX enabled applications generate a higher load on an application server than a non AJAX application. I guess customers will have to size their boxes appropriately as a result. The problem is related to the fact that an AJAX enabled pages simply send more requests to the server because of their high level of interaction versus a conventional web page.

The ensuing discussion led to a further post on the impact of lazy fetching (aka Predictive Fetch).

Some AJAX sites fetch all the data and then display it in an interactive fashion. Others will fetch a reduced set of data and then pull the missing data when it’s requested. It’s the latter where care needs to be taken. Lazy data fetches are great from a user point of view. They are fast, they make the app responsive. But, if a lot of data is fetched lazily then this is a high overhead way of fetching the data. It may work well under low load but as load increases, the servers may slow down unacceptably due to the extra overhead of high frequency/low content RPCs.

James Governor questions the claim, along with some commenters in Billy’s blog – Billy has some good comments and the discussion is worth following. Nate Schutta has addressed performance in the past, says “it depends”, and points to some real-world evidence of scaleability:

Considering that Basecamp ran on one server for its first year, I’m curious what causes him to make a statement like that. I’m not saying there isn’t some truth to it, but I haven’t been hearing any screaming about this issue; I’m not sure, but I suspect Gmail gets a few hits a day and it seems to be doing OK…

Tim Bray isn’t loving the whole question.

The question is dangerous because itâ€™s meaningless and unanswerable. Your typical Web page will, in the process of loading, call back to the server for a bunch of stylesheets and graphics and scripts and so on: for example, this ongoing page calls out to three different graphics, one stylesheet, and one JavaScript file. It also has one â€œAJAXyâ€ XMLHttpRequest call … Iâ€™ve argued elsewhere that AJAX can be a performance win, system-wide; but that argument too is contingent on context, lots of context.

An Ajax app doesn’t have to be like Google Suggest and respond to (almost) each keystroke. But there are times when a high level of interactivity is the ideal thing for users, and at least for those situations, it’s important to look at strategies for scaleability and optimal performance.

It’s “Ajax”, not “AJAX”, stupid

Jobs @ Ajaxian

Topics

Archive

Related Content:

Related Content:

Related Content:

Other Talks at the Ajax Experience

Javascript

Animation

Build System

Optimisation Strategies

Build

Where Widgets Come From

Cross-Domain IO

Performance

Related Content:

Background

PACKAGING

Language Utils

Event System

UI Utilities

Remoting

Drag-And-Drop

Animation and Effects

Widgets

Custom Widgets

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Related Content:

Ajax Questions and Answers

Ajax News, Tips and Guides

Ajax Glossary

Audible Ajax

GET E-MAIL UPDATES

Ajaxian Jobs

Contact us

Feeds