developerWorks chats: Making the move to Ajax 
Moderator: Bill Higgins

1:02 billhiggins: My name is Bill Higgins. I'll be your host this afternoon. The topic is Ajax, the format is pretty much whatever folks want to talk about. People are welcome to ask questions to the group and if there aren't questions I have questions FOR the group. If we run out of things to talk about, my plan is to start pre-announcing top secret IBM Ajax projects. 

1:03 billhiggins: Alright, so Matt Lavin from Rational had a question on how well does Ajax work over HTTPS. My experience has been that it works just as normal web pages do with both the upside (additional security) and the downside (lack of cacheability at nodes along the Internet). 

1:03 billhiggins: Anyone have any different experiences with HTTPS? 

1:04 billhiggins: (Hey Cote!) 

1:04 pmuellr: I think the caching is the biggest problem. 

1:04 pmuellr: (lack of caching) 
 

1:05 billhiggins: To be clear though, I believe you still get browser-caching, just not intermediate node caching. 

1:05 billhiggins: Alright, here's a question to the group - please speak up. If you're currently doing Ajax development - what are you using as your toolkit/framework. E.g. Dojo, Prototype, GWT, roll-your-own. 

1:05 jaredj: For me, Dojo Toolkit 

1:05 jayallen: well, we use DWR and GWT here in dW 

1:05 mdlavin: Are we separating complex javascript/dom manipulation from actual async server requests? 

1:06 zedot: Did a minimal POC using Dojo. 

1:06 jayallen: Nick is our GWT expert 

1:06 wallaker: I've used dojo and DWR 

1:06 frodenas: In my case, Dojo 

1:06 jyellis: IBM JSF Widget Library in RAD 

1:06 billhiggins: Matt: by the time you're in the JS/DOM realm, HTTPS doesn't matter, no? 

1:06 npoore: GWT mostly. 

1:06 billhiggins: So Nick, what's your impression of using GWT for non-trivial applications? 

1:07 billhiggins: Jared, which parts of Dojo do you find yourself using the most? 

1:07 mdlavin: bill, true, I was just thinking that I've used Dojo for DOM manipulation widgety stuff, but thought the ASYNC stuff was not as simple as others 

1:07 billhiggins: We also use Dojo and tend to use the Event system heavily, the packaging system heavily, the widget system heavily, but we don't use any of the reusable widgets except for the date picker. 

1:08 joshstaiger: Async tends to be a bit different from traditional programming 

1:08 jaredj: For Dojo? Right now I've used a lot of the container widgets for layout (TabContainer, ContentPane, LayoutContainer, etc). I've also used TreeV3, and written a few custom widgets as well. I heavily use the Topic subsystem (I really like it. It makes many things easy). The connect() and io.bind() are also very useful. 

1:08 joshstaiger: but once you get the hang of it it's not too bad 

1:09 npoore: Well the way GWT is architectured presents some limitations. For example you have to use the javascript generated by the GWT compiler on the same server. Usually with javascript there are the browser security cross domain problems but I have noticed even with two servers in the same domain there are still problems. 

1:09 gerderpa: i have done some research on using Dojo, prototype and DWR 

1:09 billhiggins: [wallaker] - I'm not that familiar with DWR (just looked it up on Wikipedia - http://en.wikipedia.org/wiki/DWR_%28Java%29 ) what's your experience been with that? 

1:09 npoore: This chat room uses DWR. 

1:10 jayallen: yeah 

1:10 billhiggins: [npoore] - is it possible to use JS language features like closures that arent' really present in Java? Also, one of the things I find myself doing is mixing-in arbitrary properties into Objects (which you can'd do naturally in Java). 

1:10 wallaker: DWR (at least v1) handles the 'plumbing' - basically gives you client-Javascript to server-Java RPC for 'free', comes with its own servlet - you configure what server-side objects you want to expose and it will create JavaScript proxies for them 

1:10 wallaker: Technical explanation aside, it rocks  

1:11 npoore: Yes GWT compiler supports native javascript language in your java code. 

1:11 jaredj: Is GWT using Rhino/BSF, then? 

1:11 billhiggins: [npoore] Do you find yourself writing much native JS? 

1:11 cote: Somewhat along those lines, I'm curious how much people like to be seperated from the "pure" AJAX stuff (HTML, JavaScript, CSS, etc.) by frameworks. GWT always seemed like it was very far where as other frameworks maybe not so much. Is it better to be closer or further to the "lower lever" stuff? 

1:12 wallaker: DWR is great tech if you want to add Ajax to an existing Java webapp - no new servlets, reuse existing domain objects via RPC, write some new client-side JavaScript and you're up and running 

1:12 billhiggins: That's a good question Cote. My experience is that most people start using a pure Ajax framework like Dojo kinda dreading it, and after a while they like it a lot. 

1:12 billhiggins: I know for me I find it actually very painful to write Java these days, code completion or not. 

1:13 npoore: Not too much. What I really like about GWT is that google gives you the source of the javascript code. So if you are not sure how something works you can figrure it out. Basically GWT is a bunch of all ready written native javascript functions that you call. 

1:13 gbooch: bill, in moving from an existing java web app to ajax, what has been your experience in the biggest obstacles to advancement? 

1:13 billhiggins: Nowadays when I write Java I feel like I'm talking to my two year old. I have to speak very slowly and very clearly so that he understands me. 

1:13 billhiggins: w/r/t typing. 

1:13 npoore: I meant to say google gives you source to the java code which has the javascript native code in it 
peller has joined the room.

1:13 billhiggins: Actually Grady, we had the rare luxury of starting with a clean slate, so we didn't have to port to Ajax. I'd be curious to hear about other folks' experience with migration though. 

1:14 wallaker: [cote]It depends on what you're trying to do....if you want full-blown RIA (Rich Internet Apps), go to Dojo or another full featured framework....but if all you want to do is add basic ajax features (typeahead, cascading selects, etc) I'd prefer to use something simpler 

1:14 cote: I ask because -- to be cynical -- it seems like the further away from the "raw technology" you get, the less advantages (like Bill's closures in JS point) you get in exchange for "easier" coding and tooling. It's the classic problem of using GUI and CASE tools that spit out code. 

1:14 billhiggins: Ok, question for Grady - you talk with lots of our customers about their technical strategies. What do you find to be the opinions on Ajax (and REST) at the very senior technical and mgmt. level? 

1:15 billhiggins: I agree with wallaker and cote completely - I think that some of the stuff that 'dumbs down' (for lack of a better term) the raw Ajax might be perfect for an application with rather simple requiremetns. 

1:16 billhiggins: Now please don't take that as a slap against GWT because I've never actually used it, so it could be as advanced or more advanced than Dojo for all I know. 

1:16 gbooch: ajax and rest are pretty much invisible to the management level for most groups i've encountered 

1:16 gbooch: ebay and yahoo are the exception 

1:16 billhiggins: The reason I prefer a pure Ajax/REST architecture is because it makes it very straightforwad to follow the program flow when you're (*gasp*) debugging! 

1:16 gbooch: but they are different beasts 

1:17 gbooch: the banks and folks i speak too have ajax on their radar, but for most, it's not central 

1:17 billhiggins: Grady, how long does it take for a "hot" technology like Ajax to get to the senior technical levels at large enterprises? It seems like they're fully aware of SOA. 

1:17 billhiggins: Do you agree on my point about SOA awareness, and if so what's the difference between SOA and Ajax to these companies (it seems like both buzzword began taking off in 2004 or so). 

1:18 gbooch: they may be fully aware....but that doesn't mean they know how to use something like soa effectively 

1:18 wallaker: wrt migration...you learn how flexible your API's really are...if you have domain object API's that all take other domain objects as parameters, it's much harder to expose them to Ajax calls since the servlet will be getting a few string params.....in that way it's not very different than adding web services functionality to an existing web app 

1:18 gbooch: for many, it's still just hype 

1:18 gbooch: think the same is true of ajax at the more senior level 

1:18 billhiggins: BTW, does anyone on this chat use ATF (besides the folks on my team)? I see Bob Goodman, one of the lead developers on ATF from the IBM emerging technologies group is on the chat if anyone has an ATF-specific question. 

1:19 billhiggins: For folks who aren't familiar with the temr ATF, its an acronym for "Ajax Toolkit Framework", an open source set of Ajax tools that plug into Eclipse. My team's been using it for about six months and we find it to be a huge productivity booster (esp. w/r/t the JS syntax validation) and XHR monitoring. 

1:20 BobGoodman: If you haven't tried, check it out. It is available on www.eclipse.org/atf 

1:20 jaredj: I've used http://www.jslint.com for JS syntax checking. I haven't tried ATF yet. 

1:20 joshstaiger: ATF is nice. It gives you the red squigglies inline for errors 

1:20 gino: ATF bundles JSLINT 

1:20 joshstaiger: similar to eclipse's java tooling 

1:20 billhiggins: Ah we also have Gino Bustelo from ATF I see! 

1:21 BobGoodman: The project is still under development. We want to understand what Ajax developers want 

1:21 wallaker: Bob, I'm wondering if the ATF team looks at Firebug much and what your opinion is on putting functionality into the browser vs. the IDE 

1:21 jaredj: Ah, then ATF must have a good syntax checker. Jslint ha sure saved me from some headaches. 

1:21 billhiggins: The one thing that ATF really lacks right now is any kind of content assist (outside of a few well-known objects like Window and Document) but apparently that's on the radar for 2007. 
1:22 billhiggins: Jared, how do you use JsLint? With ATF it's seamless - you just get the yellow/red-squigglies when you've done something naughty/evil. 

1:22 BobGoodman: Yes, we look at Firebug. We are using Mozilla XULRunner as our engine, so the functionality should be similar
 
1:22 rbackhouse: Any chance of IE integration especially on the debug side. 

1:22 gino: ATF uses both JSLINT and Rhino for as you type validation... and I tell you, just that feature saves a lot of time
 
1:23 billhiggins: Grady, what do you think for a technology like Ajax to go from "buzzword" and "awareness" to "adopted" and "deployed" with big companies? 

1:23 BobGoodman: We want to do I.E integration. The biggest issue beside effort is that we don't have rights to ship the Microsoft dll required to do debugging' 

1:23 gbooch: it's a good idea  

1:24 gbooch: two things, i think, bill 

1:24 npoore: One thing that is very good about GWT is it supports IE, Firefox, Mozilla, Safari, and Opera. 

1:24 gbooch: first, is some stability in the patterns/toolkits 

1:24 rbackhouse: But we could get those ourselves ? 

1:24 gbooch: second is some more proof points 

1:25 billhiggins: Right, so with Dojo (the framework we use) it's still at a 0.4 level and has a lot of major things still on the to-do list. 

1:25 gbooch: we here tend to be early technology adopters; many organizations with public facing web fronts are much more conservative and so don't like to use volatile technology 

1:25 joshstaiger: Dojo also smooths over the differences between different browsers. Thta's one of the big wins with going with a framework. 

1:25 billhiggins: I guess another thing that will hinder Ajax adoption is some of the accessibility concerns. 

1:26 wallaker: [Grady]For ibm.com, we have a requirement for 100% functionality with JavaScript disabled, which limits how you could apply Ajax. Do you see this in many other large co's ? 

1:26 gerderpa: i agree with what josh says about using frameworks for dealing with cross browser issues 

1:26 jayallen: uh, this chat would never work with JS disabled 

1:26 peller: wallaker: there are other ways of achieving accessibility, so companies will need to revisit their assumptions about JS 

1:27 wallaker: Yeah, I think devWorks has an exception....the main customer-facing ibm.com does not 

1:27 jayallen: we have lots of exceptions 

1:27 wallaker: I agree, but it's very hard to change corporate policies in big companies 

1:27 peller: the wai-aria spec is one way of enabling AJAX accessible UI 

1:28 billhiggins: Has anyone doing Ajax development here gotten beaten up about accessibility or standards for their Ajax apps? 

1:29 jayallen: yes 

1:29 billhiggins: Hey Adam, welcome to the chat. Folks Adam Peller is one of IBM's contributor's on the Dojo Toolkit, so if you have any particular Dojo questions or comments, he's your man. 

1:30 billhiggins: Brief interlude: Grady Booch (on this chat) will be hosting another dW chat tomorrow at 4pm Eastern time. The topic is the new versions of the Rational design and construction tools that we released yesterday - i.e. the Caspian wave. You can join the chat via the dW Rational zone I believe. 

1:30 gerderpa: what do you think about Dojo widgets? we are planning to use Dojo´s drag and drop functionality and probably some of it widgets like the treeV3 

1:31 frodenas: wallaker, I work for a savings bank. We use Ajax on our Branch Teller apps, but not in Internet banking. The reason is that in the first one, you could control the envionment (platfotm, browse, ...) but not in the second one. This is a huge problem, there are lots of clients with older browser, and the compatibility of JS is not so great. 

1:31 billhiggins: I must say gerderpa (real name please?) I'm not a big fan of Dojo's widgets, though I'm a big fan of their infrastructure for creating your own custom widgets. 

1:31 joshstaiger: In our experience we've had some problems with using the prepacked dojo widgets. I think it's just very early days for those right now. 

1:31 joshstaiger: But the widget system itself is great 

1:31 billhiggins: The big problem I have with Dojo's widgets it that they always seem to satisfy 75% of our needs, but the missing 25% is enough to cause us to create our own widgets. 

1:31 joshstaiger: we've had great success writing our own custom dojo widgets 

1:32 billhiggins: We need to do a better job on providing feedback to Dojo. 

1:32 peller: gerderpa: well, I am a big fan of the widgets, but biased, of course. They are extensible so hopefully you can get at least some of that 25% 

1:32 gerderpa: hi, bill i´m Gerardo Der Parsehian 

1:32 gino: I totally agree with Bill's comments on widgets, I see myself creating new widgets more often than reusing the ones that come with Dojo 

1:32 peller: and Dojo's widgets are built on an engine so that you can make your own creations as well, hopefully leveraging some of the framework 

1:33 peller: and leverage some of the benefits, like cross-browser abstractions, and now some i18n and a11y. i18n = internationalization, a11y = accessibility 

1:33 billhiggins: frodenas (real name?) makes a great point about being able to control your client. If you have to support every conceivable web browser ever release, it's not feasible to have a real Ajax app. This is actually one thing that makes me think companies would be *more* willing to deploy Ajax apps for their internal apps. Because they actually can (in theory) control the exact browsers that folks use. 

1:33 gerderpa: i noticed it seems simple to extend current widgets 

1:34 billhiggins: I think the Dojo widgets will get their eventually, but I think they need to get better w/r/t being able to override the out of the box look and feel. 

1:34 frodenas: Bill, my name is Ferran Rodenas. 

1:35 billhiggins: So anyone here experiment with Microsoft "Atlas" (or ASP.NET Ajax or whatever they're calling it these days)? 

1:35 billhiggins: I remember Adam telling me that there was some neat technology there. 

1:35 billhiggins: Somehow I think I'd get more "yes's" to that question if this were an MSDN chat rather than an IBM dW chat.
 
1:35 billhiggins: So Adam, since we have you on the line. Can you tell us about anything new and exciting coming in Dojo v0.4.1 or Dojo v0.5? 

1:36 peller: [billhiggins] not sure how much it has developed in the past year or so. I believe they did have a jump on things when they did their announce at the PDC 

1:36 peller: ah, shameless plug: we released 0.4.1 today. I can point you at the blog entry... 

1:36 billhiggins: Anne, Cote, others - do you have any awareness of or thoughts on Microsoft's Ajax efforts? 

1:37 peller: well, dojotoolkit.org is probably the best place 

1:37 annez: I don't think MS has much mind share within the Ajax community 

1:37 peller: 0.4.1 includes the first work on i18n and a11y, a neat charting engine, some new widgets... 

1:37 billhiggins: [Anne] what do you think causes that 

1:37 Paszt: ASP.NET Ajax is in Beta 2, seems allmost ready for deployment. I find it very simple to use and they are constantly adding controls to the control toolkit. 

1:37 cote: That they're uni-platform? 

1:37 peller: 0.5 should be more about stability and performance 

1:37 annez: my sense is that MS-only shops are not technologically driven 

1:38 billhiggins: [Paszt:] - how does ASP.NET Ajax do for targeting non-IE browsers? 

1:38 peller: My recollection upon seeing Atlas was that the client end was truly browser-agnostic 


1:38 billhiggins: I was heartened to read in the IE blog that they were dropping support for VBScript to focus on cross-browser compatibility 

1:38 peller: but they didn't have their story straight and wouldn't open up the license, now it's a branded ASP.NET technology, I think 

1:39 cote: I'm still curious about the a11y concerns. That was always a big challange in my past AJAX encounters. 
1:39 annez: with wpf/e MS is aiming cross-browser, cross-platform 

1:39 billhiggins: Adam can speak to a11y 

1:39 peller: well, not too well, but I'll try 

1:39 Paszt: regarding non-IE browsers and ASP.NET ajax: they are almost fully compliant with the major browsers; still some things to work out with safari. 

1:39 peller: we do have one of the experts from IBM's accessibility team working on Dojo as a committer 

1:40 cote: Is it a matter of the readers out there not yet supporting AJAX apps, or AJAX apps not being friendly to a11y? 

1:40 billhiggins: rant on behalf of all Ajax developers everywhere: I will be happy when Internet Explorer's DOM and CSS implementations are as good or better than Firefox's so that my team doesn't spend 25% of its time on the care and feeding of IE. 

1:40 peller: this includes everything from keyboard accessibility on the widgets to working with screen readers using wai-aria
 
1:40 cote: And, if I understand, there's one de facto a11y reader, right? 

1:40 gerderpa: i have read that openLaszlo and dojo are partening . what do you think about openLazlo? 

1:41 annez: openlaszlo doesn't generate dhtml yet does it? 

1:41 annez: only flash? 

1:41 peller: I love openlaszlo. Both communities are open, and the developers have met in person. I'm not sure exactly what the extent of the relationship is or will be 

1:41 peller: openlaszlo is more about a declarative grammar abstraction. ajax is just an implementation to them -- they were originally flash-based 

1:41 peller: yes, they now have an Ajax runtime, and I believe they're working on Java mobile, too 
1:42 peller: so it's a drastically different programming model. It really depends how you feel about using markup -- pretty much for everything 

1:42 gerderpa: i was planning on trying openLazlo for DHTML instead of flash. have anyone tried it? found any issues? 

1:42 gino: I think OpenLaszlo rocks, and if the Ajax version works coparable to the Flash version... I think that is the way to go 

1:42 billhiggins: I haven't used OpenLazlo myself. 

1:42 annez: yeah, and what do people think about using markup to build apps? 

1:43 billhiggins: ah markup - isn't that the big dream Adam? declarative markup Ajax apps? 

1:43 joshstaiger: Anne - ugh  

1:44 billhiggins: Gino/Bob, any chance you guys can talk about the plan next year for the new Javascript edtior in ATF/WTP? That's a very interesting and ambitious project. 


1:44 jaredj: I'm of two opinions on markup. One: It's easier for novices. Two: It stinks when you're really trying tofigure out what is going on under the covers.  

1:44 billhiggins: Anne, back to markup - with Dojo (my area of expertise) you can build your widget templates using plain old HTML and then do the dynamic bits during the widget creation process and by responding to user events post-creation.
 
1:44 annez: some Adobe guys were telling me it's cool to use all markup (MXML, of course).  

1:44 joshstaiger: I think markup is fine for templating but once things get more complex the syntax kills me 

1:45 BobGoodman: On the ATF site on Eclipse we have a proposal for JavaScript Development Tool project. 

1:45 peller: yes, I think when you use Flex or Laszlo, you're really working at a different level of abstraction and trusting their engine. Debugging the results is something like debugging assembler for C-apps 

1:45 gino: jaredj, if it is done well, you don;t have to worry 

1:45 billhiggins: Oh bummer, Grady left. He's been chatting with Adobe about some stuff and said that their Ajax plans are pretty interesting. 

1:46 annez: Adobe put some cool ajax stuff into dreamweaver with spry 

1:46 annez: it's easy enough for designers to use 

1:46 BobGoodman: the ATF team would like to here what people think of the proposal. We have already started working on the project. 

1:46 annez: but it's not just special interface effects 

1:46 billhiggins: yes, Adam makes a good point about the pluses and minuses of higher levels of abstraction. As Joel Spolsky says abstractions are fine things into something breaks. 

1:46 jaredj: Don't get me wrong, I love Dojo's HTML template mechanism. But I find it difficult at times to figure out how all the markup really works together in a fullblown app without going down into the widgets to uncover the linking magic. 

1:46 gerderpa: so we can say maybe using some dojo/prototype/json combination would be more flexible than going with a framework such as openLazlo, right? 

1:47 billhiggins: I really like to know what's going on at a low-level in my app,so depending on high-level abstractions (esp. in these early days) is very scary to me. 

1:48 billhiggins: Jared, can you say more about the "linking magic" issue? The only issue I ever had with Dojo widgets and complex apps is the situation where CSS rules in parent elements having surprising side-effects on a contained widget. 

1:48 gino: one thing about Laszlo is that you can write JavaScript if you like and create new TAGS using a combination of their XML lang and JavaScript... That is one of my favorite features 

1:48 jaredj: [billhiggins]: Agreed. Given how early things are, without knowing what happens inthe low level, it's nasty at times to debug problems. 

1:48 peller: gerderpa: there are still interop problems with toolkits -- openajax is trying to address these 

1:49 billhiggins: Getting back to abstractions, one of the problems I always had with JSF is that when things go wrong, you get these stack traces from hell because of the many, many levels of abstraction between the framework and your code.
 
1:49 jaredj: The linking magic? Well, for example, say you want to catch events on things like ContentPane, such as perform an action when the content actually loads. Without going into the content pane itselfff and seeing what apis are actually fired on load completed, you certainly can't tell what your widget may need to bind to to monitor. 

1:50 annez: Seems like the problem is not working at a high level of abstraction but that the debuggers aren't good enough. 

1:50 billhiggins: Ah yes, I frequently find myself learning about the Dojo widgets via the debugger, which is a bad no-no from a software enginering point of view. 

1:50 cote: But it's what seems to always happen. 

1:50 jaredj: Yes, the debuggers are pretty poor right now 

1:51 cote: I recall learning all about WebSphere's architecture while debugging some JMX problems  

1:51 peller: annez: it's both, I think. With some of these abstractions, the resulting code is obfuscated or just plain unreadable, not intended to be debugged directly 

1:51 billhiggins: [Anne]: the debuggers are ok (not good), but it's just that when things go wrong it's very hard to figure out if it's something you did or a problem with the framework. 

1:51 peller: OpenLaszlo has its own debugging framework at their level of abstraction, which is interesting 

1:51 billhiggins: with a simple Ajax/REST app the problem is either: 1) in your code, 2) in the framework's code (usually only 2 or 3 levels down), 3) or on the wire (easily inspected via a XHR monitor) 

1:51 jaredj: I end up using dojo.debug() a lot, the javascript console in Firefox, and a few other things to track down issues. I've had to track down a few Dojo problems, which were not fun. 

1:51 GustavoAndresBrey: I would like to know if you have any concer about using JSON for interchanging data between browser and server, intead of XML, of course... 

1:53 billhiggins: [GustavoAndresBrey] I actually prefer Json because it's so easily brought into the JS environment. Pat Mueller is a big fan of JSON as well.... 

1:53 jaredj: [GustavoAndresBrey] I prefer JSON as well.
  
1:53 pmuellr: definitely love json; all the data types you'll ever need, built into the markup 

1:53 billhiggins: [Cote], Jared is on the WAS architecture team, so you can direct any WAS/JMX questions to him  

1:54 wallaker: If you're building a service that will only be called from JS, JSON is much nicer. 

1:54 billhiggins: Richard Backhouse (rbackhouse) also used to work on WAS, but has since joined the friendly confines of Rational. 

1:54 GustavoAndresBrey: I read somewhere that JSON has some encoding problems, is it true? 

1:54 pmuellr: json also has a lot of similiaries to SDO, if folks know what SDO is ... only ... simpler than SDO 

1:54 npoore: I have noticed some inconsistances of IE and Firefox with JSON though. On really long JSON returns Firefox doesn't always like them. IE doesn't seem to have a problem though. Anyone else noticed this? 

1:54 jaredj: I'll freely admit tracking down errors in WAS isn't easy at times either.  

1:54 jaredj: [pmuellr]: SDO: UGH! 

1:55 billhiggins: I've been using JSON in both FF/IE via dojo's remoting libraries (dojo.io.bind) and have not had one browser-specific issue in 10 months. 

1:55 jaredj: I've used JSON strings greater than 1MB in size in both without issues. 

1:55 peller: GustavoAndresBrey: the encoding is really the responsibility of the HTTP layer. JS is all unicode. If you use UTF-8, everything *should* be handled right by default most of the time 

1:55 pmuellr: I'm not sure I'm ready to trust clients reading JSON directly, even though they CAN. You better hope your server's not sending you something ... nasty. Executable data. Powerful. Dangerous. 

1:55 jaredj: I don't recommend that big, of course. 

1:56 wallaker: pmuellr: Trust the server ? If I'm writing the app I trust the server, not the client 

1:56 jaredj: JSON isn't supposed to be executable, though,. Just data. 

1:57 peller: never trust the client. 

1:57 pmuellr: big json actually has some problems, in parsing. The properties are pretty much by definition unordered, so you need to parse the entire string to make sure you got everything; XML allows some ordering where you can get by with a streaming parser. 

1:57 billhiggins: 3 mins left? Anyone have any burning unanswered questions? 

1:57 pmuellr: I think that's the odd case though (huge wads of JSON).
1:57 wallaker: My least-favorite feature of browsers is the ability to type Javascript into the address bar and have it execute against the current page DOM 

1:57 npoore: Well with JSON you can do cross domain so your ajax app maybe calling a JSON service. 

1:57 pmuellr: [jaredj] not much of a difference in JS ...  

1:57 npoore: so you would need to trust that server that is providing the JSON service 

1:58 billhiggins: [wallaker] Actually, I did find one instance where that's really useful. 

1:58 wallaker: It's nice for hacking/debugging, but it limits what functionality we'll ever put in client-side JS 

1:58 billhiggins: determining quirks mode vs. standards mode for the current page (see: http://www-03.ibm.com/developerworks/blogs/page/BillHiggins?entry=determining_quirks_mode_vs_standards ) 

1:59 billhiggins: Alright, it's just about time to end. I  want to say thanks to everyone for joining the chat, and don't forget about Grady's chat tomorrow at 4pm EST tomorrow on the new Rational design and construction products.