A little while back, I mentioned that some people in the patterns community have been noticing the Ajax Patterns. In particular, there have been a series of discussions about the patterns by the Software Architecture Group in the University of Illinois Computer Science Dept (home of Netscape forerunner Mosaic btw). The SAG is led by Ralph Johnson (Gang Of Four “Design Patterns” author) and the group also includes Brian Foote, who blogged about Ajax as a pattern earlier on and has kindly been keeping me updated on the MP3s emerging from these discussions.
The feedback has been very helpful and I’ve been able to incorporate it in time for the physical publication – thanks again to everyone in the group.
While listening to the audio, I’ve been taking notes and writing some comments. With the permission of Ralph and Brian, I’m going to be posting these, each discussion as a separate post. It’s an opportunity to see how a group of very intelligent people without much Ajax experience respond to Ajax and the Ajax patterns. You’ll notice two conventions here: “TODO” is a note to myself that some action needs to be taken. “MM” signals my ideas, views, and comments back to the group.
30/1/2006 Ajax Workshop
9:45 XMLHttpRequest Call
What it's about. - Probably missing in old browsers if you can't use Ajax on them. - Remote call to server without refreshing a whole page. - I assumed in JS you can open a socket, you could have done this yourself. - Depends on what the browser provides. But not cross-browser. [TODO Mention HTTP restriction and what JS can do, cf Richer Plugin] - Ironically, because JS isn't general-purpose (due to security), it's wound up being a better citizen. Also because it was kind of low-brow, everyone kind of ignored it. - The big idea is this is a way to call the server.
Interesting characteristic of XHR: - Asynchronous - Built-in security (originating server)
Did you find this pattern easy to understand? - One thing that troubles me (not particular to this pattern), pretty soon the code becomes spaghetti-like. Nd good patterns on how to manage code. [MM Agree, we need a JS patterns book! That's not the aim here, the book will make that explicit]. - Part of the problem here is JS itself. - Haven't seen the word "simple" "elegant" or "pretty" to describe JS architect. This is a Rube Goldberg solution, duct-tape ... at it's best. [MM Sort of true, but there's a lot that can be done to improve it] - There are libraries that help. (AjaxCaller, Prototype).
Writing here, even though it doesn't address these problems, could understand/follow it? - I don't like the Problems section. "How can the browser communicate with the server?" But this pattern is more specific than server communication. The next 1-2 patterns have the same problem. - But the problem might be the same, but different Solution. What I dislike is the forces are also the same. How does it mitigate the forces? Maybe there should be some different forces. - Only difference between IFrame and XHR is only restricted to same host, so maybe okay other than that. [MM Actually, even this difference doesn't exist, since you can't read a remote IFrame's content] [TODO Possibly update forces to be different, back-reflect the solution]
22:30 Doesn't say anything about being asynchronous at the start - Ajax should be highly responsive. Distributed system, so you want to minimise communications. ie Must be asynchronous [TODO Revise forces. HOWEVER, note that XHR doesn't have to be async.] - "Conventional means ... slow." He's trying to rule out Solutions, before we get to the solution. [MM This sort of goes against the previous suggestion that IFrame and XHR need different Forces. Maybe suggests different people have different views on this issue of the forces.] Doesn't so much talk about the forces as take potshots at existing solutions. [MM This is a fair point, more prevalent in the initial patterns as they're arising as a reaction to conventional web dev, but it's true you don't have to formulate them that way.]
26:30 It's a long pattern, is that okay? - Yes, longer than all the others, problem if all patterns were this long, but given it's so core to Ajax, it's fine. - Length is fine, but a lot of code there. - I would like more examples of the old way of doing things. [Covered in the Anagrams tutorial, perhaps reference it] - The general idea is if you have a big object and only small things change at a time, then you keep going back to the server and grabbing small bits of it. I think of Google Maps. - Pattern could be shorter if PHP wasn't written. - So you'd like less example code, others want more. - It's a Chimera/Frankenstein ie PHP (or whatever serverside) on the one side, and even JS is a kind of Frankenstein language. So it's important to have the PHP, reminds me that's the game I'm playing. I didn't mind it, seeing all the pieces together reminds you we're receiving small chunks etc. - The pattern is really introducing XHR, not how to use it. - Disagree with people who are trying to call everything a pattern. - Well, these particular patterns are what he calls foundational. He says they're not really patterns, they're just how the technology works. - I know what you're saying about that, and it bugs me too, but I've been trying to come up with a rationalisation for admitting that this kind of design exposition is a contribution to our software architecture literature ... and if designs recur, if a lot of people come up with the same solution to a problem ... my mind cries out to keep distinct from Visitor and ... Composite, but I don't have the vocab to keep them distinct, and I want to maintain this notion that the patterns community is talking about good ideas that keep coming up over and over that we haven't come up with ourselves ... true, it's a different kind of discussion from the GoF, without having disclaimer kind of nags at me [MM Agree wholeheartedly, why I've sounded a bit apologetic describing these as patterns, but they just fit into the overall language well. See earlier blog post.] [TODO Needs better "disclaimer" in the book] - So then what are the patterns around XHR? - Event handling, Asynchronous call - Lots of people dealing with SOA, problems s.a. async smell the same but with different names [MM Later patterns, e.g. Distr'd events] - Error detection - Invesion-of-control/DepInj/Observers. People patternising closures. There's an aspect of dealing with callbacks. Callbacks are part of the discussion here, and that's an idea that comes up here. - Feedback from the call. Or using poll. Fire-and-forget. Typical remote invocation styles: What does XHR do? - In JS: Callbacks used here (XHR), also used for user interops. We want to follow flow-of-control, but if everything is event handlers, hard to follow. (ie JS hard to follow because of this style.) A lot of the time, "callbacks" are basically continuations. It's a general pattern discussion we could have.
41:30 Real-World Examples and Code. - These systems are not thoroughly responsive as claimed. Google Suggest surprisingly fast. Others like Backpackit and Kiko not. [MM See perf optimisation, also comments in HTML Message, etc. Alex Kirk mentioned Kiko a while ago as a problem due to too much browser-side rendering.] - Need to avoid too many requests - Curious didn't mention the most famous examples (Google Suggest etc) Maybe can't see the code. But it's JS, have to be able to. But maybe unclear. [MM Yes, obfuscated. Also, tried to avoid the cliche references too much, they're mentioned elsewhere] - Discussion about mint stats package, security issues in uploading data. - Next, ways of telling your web browser what to report back. - If trying to keep people from attacking you. It's interesting to me. - Applets got crucified for some of the security problems that JS has. People moved on from panicking about them, but got away with it because browser wars finished etc.
=============================================================== 49:00 IFrame Call - Poor Man's version of the previous one. - More like a hack - What can you do with one that you can't do with the other? XHR and not with IFr? - I only know the other way round...IFrame is more compat with older browsers. - Long discussion about relative benefits etc. - Comment about Google using IFrame. Not sure if it's true as you can zoom in.[TODO More specific about how it's being used. (I think book version already does that)] - IFrame Call doesn't talk about hidden frames. [MM XHR Pattern alternatives has a detailed comparison)] [TODO XHR comparison should briefly explain how the two are diff, not just compare the benefits] - IFrame has no timeout function. (But could fake this using polling) - Calls IFrame a hack ... Pot calling the kettle black, since Ajax itself is sort of a hack. Is it bad just because it's old? [MM Again, comes down to the comparison. XHR is a more intention-based, intuitive, API, although it's true that you won't care about that because you should use a wrapper lib anyway. Better argument is the extra functionality such as call tracking.] - Would like better explanation on what's so bad about IFrames. [TODO Include x-reference in IFrame Solution. Also mention the portable wrappers in the Solution, ie you shouldn't actually care/know which you're using is the more pertinent issue here.] - I'm feeling historical. The room we used to sit in is the room where the original Mosaic web browser developers sat. Continuously astonished in the web industry, using things that in ways they weren't invented for. Go down this list, frames, tables ... Ungodly mess, but really impressed, poster child for pragmatism and "worse is better". IFrame is a typical example. - I didn't get any feel on whether I would use one or the other. - Intrigued by the history of JS. Knowing that IFrame predated XHR because features that made it easier to do the second came along in 2003. Whether it needs to be here, not sure. [TODO Sidebar?]
=============================================================== 49:00 HTTP Streaming
Is it competition for the other two? - Different problem (push/streaming) - "How can the browser communicate with the server?" Same problem as the other two. - I don't know, it turns the table. Little pattern device of using the same problem with different solutions may be okay here. Here, the forces would be different. Could make the case for having the same problem. [TODO Change the problem statement, just enough to make it a little different from previous two.] What would make you choose this over the others? - Changes coming from lots of other sources, not just the client. - e.g. Chat system. - I don't want to do this. Don't want to grow the system ... - But scaleability is oversold. You'll never be like EBay, don't need to scale up like that. [TODO Good point, mention in the pattern.] - Our wiki - 4-5 hits per second - can handle that, but not scaleable. Wikipedia is not a wiki in that sense, pages don't change because I believe something like 90% of all edits are done by 200 people, these are official wikipedia authors. Specific process. - Doesn't fit into proxies. Caching etc doesn't ddeal with longer responses. Long refactoring illustration here. Do the others have one? - Streaming wiki demo. - Seemed nice to refactor in this way. - The group is looking at the live version on the web - "There's about a half dozen laptops in it for the author's information". It worked. [MM Phew]
=============================================================== 1:20 - I didn't get the feel of which one to use. - Was hidden in the Alternatives section [MM TODO Emphasise this in the partintro, maybe in the solutions]
====== Next time: Different patterns - Problem with web version [MM Incidentally, the wiki publishing hasn't worked out ideally, didn't get the full benefit as I didn't open up the wiki (and still haven't due to spam). Ideally would have better PS format. (Blogged about printing from the web a yr ago as it happens.)] - Being on the web doesn't seem to affect (ie drop) sales. [MM We'll soon find out...:-)]