6 questions about problematic Ajax development
Thinking about Ajax web applications programming, I've come up with a few questions. Perhaps the solutions are obvious and I've just missed them, but they're nonetheless bothering me tonight:
Mobile Support: if Ajax-driven development is going to be the next big thing in development, with programmers pushing rich web clients to become the norm, how will this translate over to the mobile and wireless market? Even the simplest of desktop web examples powered by Ajax these days won't work on the most advanced mobile browsers. Market demand is forcing organizations to develop counterpart PDA- and WAP-friendly versions of their standard sites accessible via the WWW; how will a lack of Ajax support, whose key element is client-side JavaScript (which most mobile browsers don't have and therefore can't support) impact our wireless apps? I hope this isn't going to be another case of a tech where we just put up with avoiding some aspect of development mobile environments (i.e., cookies). A lack of true DOM programmability in WAP applications - not a control tree - does have its drawbacks. If the incorporation of Ajax-driven functionality is going to reduce the need for page reloads, redirects and post backs, can we rely on similar support in mobile apps, or should we plan on workarounds?
Deprecation for Older Browsers: most Ajax code samples I've seen handle older or incompatible browsers will a dreaded "You need IE 6+ to run this sample", much in the way we now handle IFrames. There's got to be a better way to deliver the same functionality, sans the fancier interface, for older stuff. Or at least gracefully bow out and recommend an alternate path.
Security of Code: many Ajax tutorials at this embryonic stage in the game put their full JavaScript code within the calling page, which is great for learning, but not so acceptable for production-caliber apps, depending on the implementation. Sure, we can stick our client-side function libraries in .JS files and reference them somewhere on the network (e.g. <script language="JavaScript" src="http://someserver.com/ajaxLibrary.js"></script>), but someone can just as easily see how you're doing what you're doing. (Note: you ever tried checking out the source for Google Maps? Whoa…). Craig Shoemaker from the Polymorphic Podcast indicated that, at least for the sample Ajax app he created, the remote script being referenced that generates the XML message ultimately called into an ASPX page needs to be on the same host, otherwise a JavaScript exception will be thrown, and the process won't work. Have we a better way to reference script without it having to be on the same server, and in so doing, make it secure enough not to be extracted and reverse engineered?
Custom Data Types Via XML Web Services: the case will arise where pages will need to call a web service returning a custom structure returning non-SOAP XML data. Since we can just directly call upon ASMX files and other sample output pages depending on platform, passing any parameters (i.e., <script type= “text/javascript“ src=“service1.asmx?AJAX“></script>), we won't need WSDL or Visual Studio Web References. Since the whole point of web services is to tap remote data sources, will this be suspect to the same JavaScript error(s) mentioned above?
Session State: Microsoft has directly addressed the issue of working with stateful data from within its client script framework in Atlas using callbacks. Really good work going on here. This will allow a developer to be able to use such data between client and server. But if the justifiable assumption is that Microsoft will create some great framework to produce "Ajax-like" web experiences, how about, by that time, those of us who want to use a pure Ajax programming model and take and leverage state?
Globalization: with a bigger push being more globalization of web apps, allowing for the use of multiple languages and page encoding, what are some of the issues that bubble up when changing the displayed character set on-the-fly?
Again, these are just some issues that I believe will come up and be asked at some tech talk or discussed in the forthcoming Ajax books. The answers may be obvious or unresolved. I'd just like to know which and to what degree. I'm hoping that Microsoft's ambitious Atlas effort has foreseen these and many other concerns and will work them into the eventual product. I've read that the Atlas Client Script Framework bakes-in rich string manipulation, making all apps inherently globalized and encoding-capable. Lord knows people smarter than me sit around and think about this stuff all day - this just occupied 10 minutes.
So consider this an altruistic plea for knowledge/debate: I always was that kid in school who asked the question everyone was thinking (or the question that everyone already knew the answer to), no I've got no reservations sticking my neck out and making myself look stupid for the benefit of the community. Any feedback would be most appreciated.