Hello Eric,
Sorry for contacting you on an unsolicited basis, but I've read a few
of your posts on
comp.lang.javascript. I'm a journalist with Application Development
Trends (ADT,
http://www.adtmag.com) and I'm working on a story on AJAX.
(Will wonders never cease, eh?)
If you don't mind, I'd like to ask you a few questions about your use
of/interest in AJAX. If you would be willing to answer a few questions
via e-mail, I'd very much appreciate it. I've appended some questions
below, and I'd ask that you answer as many (or as few) as you wish.
Don't worry about answering all of them (although, hey, that would be
fantastic :) -- just tackle the ones about which you have the most to
say.
In addition, I can quote you any way you like, so if your employer
doesn't want its name used in print, I'll be more than happy to
obfuscate its identity. Or your own, too, if you would prefer.
Thanks very much. Appreciate your time and trouble, and I apologize,
again, for contacting you on an unsolicited basis.
Best,
Steve
1. If you're working with AJAX, what kinds of (business) problems are
you using the AJAX vision/concept to try to solve? What other
products/technologies/methods have you explored, and why or why do you
not think AJAX' asynchronous JavaScript-based model is a potential
solution?
2. AJAX isn't the first spin on asynchronous remote scripting. If I
recall correctly, Microsoft introduced Remote Scripting several years
ago, after all. But Microsoft's implementation was plagued by security
problems. (I can't be bothered to look -- not right now, at least --
but I believe I can remember at least one Remote Scripting-specific
exploit for Windows NT 4.0 or Windows 2000.) As far as security is
concerned, what makes AJAX any different?
3. The "X" in AJAX stands for XML. As I understand it, however, you
don't necessarily have to use XML to "do" what is called AJAX. (AJAX,
as I understand it, describes the concept of having JavaScript
communicate directly with a server without first reloading HTML.) At
the same time, one of the most popular ways of "doing" AJAX seems to be
with the XMLHttpRequest, which -- as the "X" in AJAX indicates -- seems
to have become synonymous with the technology. So...do most of the AJAX
solutions you're aware of/have worked with use XML (or XMLHttpRequest)?
Are you aware of any approaches to doing AJAX that don't involve XML?
Can you think of any benefits or drawbacks associated with either
approach? (For example, why is the (non-standard) XMLHttpRequest one of
the most popular ways of doing what is called AJAX?)
4. Similarly, isn't there a sense in which smart developers have been
using AJAX-like approaches since before AJAX was explicitly identified?
Haven't programmers who care about application performance issues
(e.g., load times, quality-of-experience for end users) long been
"circum-coding," as it were, the inherent limitations of the
conventional HTTP client request model? If so, what approaches have
they used? Why is or why isn't AJAX any better?
5. There's a sense in which XML could actually be a hindrance -- if,
for example, you're using XMLHttpRequest to send large amounts of data
between a JavaScript client and server. Is this a potential limiting
issue for the AJAX vision, or is it largely a *non* issue (apps that
need to exchange large amounts of data by definition won't do so using
JavaScript, but -- instead -- by some other, more robust means)? I'm
leaning toward the latter understanding, mainly because AJAX seems to
describe a way to exchange *new*, *changed* or otherwise *requested*
data (i.e., rather than reloading the whole page, the HTTPD just sends
the data that the client requests.)
6. AFAIK, XMLHttpRequest isn't currently standardized, even though it's
supported by all major browsers. There are other concerns, too, in that
AJAX methods don't always conform to expected browser behaviors. (e.g.,
WikiPedia says "it might easily break the expected behavior of the
browser's back button.") Are thesee potential issues? Are they mostly
overblown?
7. Not sure if you've already addressed this issue in your
pros-or-cons-of-AJAX responses, but I've read some folks in different
newsgroups who say that the AJAX vision does away with some of the
biggest pain points associated with Java applets, namely, performance
issues and UI kludginess. (As one poster put it, because AJAX basically
consists of HTML, JavaScript, and CSS, "you can resize windows and
expect to see text and tables wrapped and presented in all the normal
ways.") Is the UI kludginess of Java aplets a significant issue, from
your perspective, or have you and other developers largely licked this
problem?
8. I wanted to ask some questions about AJAX and Microsoft's .NET
development universe. I'm aware of several thriving AJAX for .NET
solutions/sites/communities, but I'm wondering if the inimical
opposition of J2EE and .NET often precludes the use or adoption of
AJAX-like approaches in the Microsoft universe? Is AJAX such a good
idea that it's also taking root (or will take root) among .NET
developers, too? Or -- perhaps more to the point -- has JavaScript
become such a generic technology that it more or less transcends the
divisions of J2EE vs. .NET? And does Microsoft have an AJAX-like (but
..NET-centric) technology vision of its own?
