Comments for ajaxWrong
Ajax stands for Asynchronous Javascript and XML. XUL applications can implement Ajax. As can HTML/XHTML and, possibly, XAML (not sure what the in-browser scripting is for that).
"The unspoken promise of Ajax is that it makes cross-browser apps that are more responsive possible."
Ajax isn't intrisically cross-browser. Select Ajax toolkits are.
"Stunts like 'ajaxWrite' not only break the contract locally, they start to cast aspersions on the efforts of scripters everywhere who are dedicated to an open application platform."
Firefox isn't open?
"The web has succeeded in part because in trade for control over UIs, businesses gained the ability to deploy to everyone everywhere."
Which is why so many Web sites bill themselves as IE-only, and a reasonable fraction of them truly are.
"Single-render apps are bad for the web and bad business."
That's like saying Gnome/Qt applications are bad business. Or MFC applications are bad business. Or applications targeting mobile users via WAP are bad business. XUL is merely a UI rendering language. If anyone is "casting aspersions", it's you.
"More capable than the Open Web is today, but they are not the Open Web."
Not applications are for the "Open Web". ajaxWrite, by your presumed definition, is not part of the "Open Web". That doesn't make ajaxWrite evil, any more than OpenOffice.org is, since Oo.org isn't exactly "Open Web" either.
"The term âAjaxâ? is a proxy and an ambassador for Open Web technologies today."
This is your opinion. It is not universally shared. IMHO, Ajax is a "proxy" for being a UI development technique, nothing more.
Now, frankly, I'm surprised that Robertson wrote a XUL app, and I'm more surprised that he stuck "ajax" in as a prefix, since that term is meaningless to 99.44% of the computer user market. And if you think XUL is the seventh sign of the Apocalypse, that's certainly your right. I happen to be writing a XUL app (and, no, it won't have "ajax" in the name), because it fits my technical needs today. I'll probably create a XAML implementation next year, once it's more fully baked. And so as much as you dislike Robertson for appropriating the Ajax name, I dislike you for bashing things that don't qualify for your narrow definition of the "Open Web".
I don't think XUL is the "seventh sign of the apacolypse". I also don't think "ajaxWrite" is evil (as an app). Its branding, OTOH...
XUL is a good technology that isn't (yet, if ever) suitable for the Open Web. That you're choosing to write your apps multiple times for the benefits these closed platforms provide pretty much prooves my point. Perhaps I'm coining my own term here (and a generic, fungible one to boot), but this stuff matters. I hope that it's never OK to appropriate parts of the web's user base to a particular technology. It's one of the reasons we work so hard to make sure Dojo is degradeable by default.
The definition of "Ajax" expands by the day, but I won't watch it get abused for this purpose. Esp not this purpose. Perhaps I am tilting at windmills. Time will tell.
Regards
You assume that people are aiming for the "Open Web". Many many applications aren't written for the "Open Web". They're written for doctors' offices, churches, civil engineering firms, community service organizations, and whatnot. Many of them won't choose HTML+Ajax as their presentation layer, for various technical reasons. While by definition you're a huge Dojo fan, I hope you are open to the notion that there are, and always will be, non-Dojo non-"Open Web" applications in the world.
"I hope that it’s never OK to appropriate parts of the web’s user base to a particular technology."
Again with the Web focus. Do you really think that random passersby are just going to start writing documents in ajaxWrite? For whoever chooses to use it, ajaxWrite is just an application with some specific characteristics. That's not significantly different than a user choosing some other application that happens only to run on PalmOS (which, last I checked, Dojo doesn't support, either).
To paraphrase a popular quote, "it's the user, stupid". My users won't care that my application doesn't run on IE, any more than they don't care than their desktop accounting package doesn't run on IE, or that their spreadsheet doesn't run on IE, or that their business card scanner software doesn't run on IE. In fact, my application might not even require Firefox -- it might install via XULRunner and, from the users' perspectives, be just another application. So long as they're happy, I'm happy. And if I choose to create a XAML front-end for user benefit (e.g., gets me on Windows Mobile, where neither XUL nor Dojo really go), that too is my prerogative. I'm not aiming for the "Open Web". Many XUL applications won't be aiming for the "Open Web". The "Open Web" is a very small place, in terms of percentage of applications.
As I hinted at in my earlier comment, I'm surprised that Robertson went XUL. Not that XUL isn't capable, but that XUL does limit the market for a drive-by application like ajaxWrite presumably aims to be. For things that are truly designed to be used by anyone anywhere, I am in agreement with you that "traditional" Ajax, as exemplified by Dojo, is the much better choice. For the portion of my application that will be public-facing, I won't be using XUL (though I'm not sure how much Ajax I'll be using either...haven't gotten to that part yet).
I just want readers of your blog posting to understand that XUL has its place. Probably not really where Robertson's putting it, that's all. XUL itself is not harmful.
Knowing Alex pretty well (I think), it seems to me that the crux of his argument here isn't that XUL is harmful. Alex seems to be saying that by sticking the marketing term du jour in front of what is a very specific platform application, he is doing a major disservice not only to himself but to the community as a whole.
The acronym does indeed stand for Async JS and XML. The reality is that XML is very often not part of the practice--and the practice is touted and aimed at the idea that it is, in fact, cross-browser. Bringing up mobile devices that have yet to gain the same capabilities as thier full-fledged brethren don't help your argument at all.
In fact, I'd say that "Ajax isn’t intrisically cross-browser. Select Ajax toolkits are." is a patently false statement. Javascript as a whole has no problems supporting asynchronous programming techniques--and this is just within the core set of objects, no browser attached. You are referring here to the use of the XmlHttpRequest object, which in fact is cross-browser at this point (if 4 major browsers capturing 99% of the market support it, it's cross-browser).
Either way, you're missing Alex's point. The point here is that by naming an application using the latest marketing buzzword for the sake of using the latest marketing buzzword is bad practice all around and is the beginning of that slippery slope of being the butt of jokes 2 years down the road (yeah, I have this toilet paper Web 2.0 app that wipes my butt online--its called AJAXTeePeeForMyBunghole).
Get it?
It's not a spec, so you can't get away with a literal reading of "There's no HTML in AJAX, so neener!" It's a community concensus term. And, XUL ain't a part of it. Hell, read the list from the original article coining the term 1:
* standards-based presentation using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* asynchronous data retrieval using XMLHttpRequest;
* and JavaScript binding everything together.
That's what AJAX means to us. If you want it to mean something else and get away with it, you're going to have to convince everyone who read that article and ran with that definition.
http://haarball.wordpress.com/2006/03/24/incompetent-business-receives-unmerited-attention/
Adobe's Flash Player is a single-renderer approach for SWF files, true. But it differs from XUL, MS and other approaches in being a multiple-environment renderer as well... a visitor would not need to run within a new application, but would instead use their current browser, on their current operating system, and very likely would not need to download anything new at all in order to work with this content.
(Matter of fact, sending content to the client as SWF is likely more audience-friendly than any use of XmlHttpRequest, although real stats on what percentage of consumers actually support "AJaX" work is lacking.)
I like that you're looking at the "single-renderer vs multiple-renderer" problem, although I think this is more related to higher development/support/maintainence costs than to overall audience approachability. We'd need to look at total audience costs to assess the practicality of varying engagement levels of content, and in this sense working with clientside SWF may be the most friendly and universal technique of all.
jd/adobe
But leaving this and the questionable marketing aside, AjaxWord seems to be just an online version of the old Mozilla Composer--which is hardly "revolutionary".
Haven't tried the app but I don't see anything to get all pissy about. Unspoken promises don't exist. If cross-browser is a requirement, the market will let them know in a hurry.
Regardless, the point still stands: there's only one renderer implementation for XUL, which means that this app is inextricably tied to a walled-garden technology.
Regards
Say what you want about Robertson, this is a big win for Web 2.0.
Stop the silliness about "walled gardens." Cross-browser compatibility is important at the level of HTML 1.0. But the Web is not stuck in 1996 any more. Let's move forward.
At the risk of incorrectly representing their position, it seems their argument boils down to "you don't control the term Ajax, how dare you say we aren't?", "we'll add support for other browsers eventually", and "but firefox is free".
I'd suggest that until they do add support for other browsers, they're still hurting us collectively. I realize that the theory under which they are causing harm is less compelling than if they had, say, implemented the whole thing in XAML and tried to call it "ajax". But how much water are they carrying for those who will come after them and try such abhorent marketing stunts? What slipery slope would they enjoin us to go sledding with them on?
I don't think my assessment is any less accurate today than it was last week. I'm happy to revisit it when they launch something that's actually cross-browser.
Their defense currently consists of hand waving about future releases and "ooh, look at the shiny open source browser!" misdirection to draw people away from the essential conflict that their app embodies. I can't expect them to care about the health of the web. They're just trying to make a buck. Fair enough. That doesn't mean I have to let them pretend their shit doesn't stink.
xulwrite.com is still available.
Regards
That's cool. You want to defend AdaptivePath's definition -- one that handily included the work of other companies to add legitimacy -- to the point of resenting all those who "sully" it. That's okay. I'm sure the prgrammers at google.com were just as amused to learn that they were preforming "AJAX" programming without even knowing it as we were amused to learn that ajaxWrite isn't "really" Ajax.
XUL is a neglected technology; we'll be able to use it to distribute applications that look and behave just like applications running natively on your operating system. Yes, that aim is different from a pure legacy HTML/CSS approach; yes, we're excluding I.E. How do you know we won't wind up CREATING a community centered around Firefox use, all enjoying our AJAXUL*-based applications?
Look, the application is heavily beta, and is missing a lot of features. I certainly can understand complaints there. I guess I sort of understand your much more abstract complaint. One almost has to wonder, however, if you think the whole "Web 2.0/Ajax" phenom. is really as grand as you project it to be. Is there a community of dedicated cross-browser developers out there, all sulking over ajaxWrite? Or is Ajax -- right now -- really just a few very different, interactive, asynchronous, applications and frameworks sprinkled over dozens of companies, the most interesting of which being google?
You basically say you don't want to eat our marketing bullshit. I submit that's because your mouth is already too full of AdaptivePath's.
*XUL IS XML, a fact you seem to enjoy neglecting...XML is very mutable, as mentioned in the post; I guess 99% of your sound and fury would evaporate if Safari ever decided to support it
Flash is AJAX
- run on any browser with Flash, in order for XUL to be on other browser you would also require XUL engine.
- Asynchronous
- Can transfer XML, JSON, whatever.
- ActionScript. If you can relax the fact that main content is HTML, then it should be ok to relaxed Javascript to just scriptable.
Java Applet is AJAX (run on any browser).
- run on any browser with JVM, in order for XUL to be on other browser you would also require XUL engine.
- Asynchronous
- Can transfer XML, JSON, whatever.
- Java. You don't modify XUL script at run time, so it is ok to just use compiled language. Or may be include new jar file just like you would include new js file for dynamic behavior.
ActiveX is AJAX (run on IE). My superApp.exe is AJAX (run on Win32, rememeber XUL only runs on Moz).
Useless truth by distorting the original intention of the terms.
But XUL would be AJAX by that stupid sense.
XUL's format is XML and that satisfy it's requirement of being open as much as XML format of MS Words. What's the point of implementing in XML if you don't have full specs and other implementors.
It is used to avoid people from having to wait and load the whole page every time they click on a link, button on the page (asynchronize, XMLHTTPRequest).
They have to use Javascript because it is the only language supported by all major browser at the time.
That's why it's called technique.
If you use XUL which is already interactive. What's the darn point of calling it AJAX; you are not using any technique to work around anything!!!
If I write a thick client exe that contact the server by using GET, POST request to get XML data from server, does that makes my app AJAX ???
Stupid reasoning for trying to use buzzword to market the app.
So now, we have a bunch of fat Americans eating their "Lite" ice cream and still wondering why they're fat. Just because you can misuse a term doesn't mean that you should.
Let me give you an example. I started MP3.com. Users didn't really care about "mp3" they just wanted to hear digital music. When we first launched, all of lofi clips were in real audio, not MP3. Users didn't care about the specific audio compression being used, they just wanted their music.
To me, ajax is the same. Users could care less how the new Yahoo mail interface (not technically ajax) or Google maps (technically ajax) is coded, they just want rich interactive applications. And if ajax is a trend that pushes the industry in that direction (which I think it is), then great.
Yes, ajaxWrite uses XUL and also doesn't need client server interactions with this version since there's no online collaboration features - yet.
ajaxWrite could run on other browsers, but we choose to launch with Firefox for now because it gives us cross-platform (mac,ms,linux) but limits QA needs at this time. Plus I like the folks at Mozilla and if I can help them in their epic struggle with MS so much the better. Competition is a good thing and the only reason MS is investing anything into browser development is because of Firefox.
-- MR
Thanks for taking the time to respond in person.
I understand your point about users not caring about the underlying technology, but I think your example does more to prove my point than yours. You say that "users didn't care about 'mp3', they just wanted to hear digital music", and that's the power of Ajax in a nutshell.
Users don't have to know what browser is "more ajaxy", they just point their browser at a particular site and they get an enriched experience over the previous generation of webapps. Your application breaks this contract.
Attempts to justify marketing a single-renderer experience under the banner of a more inclusive technology aren't easier for me to swallow because you're somehow playing off a cause everyone supports (Mozilla) against one that has a broader but less vocal constituency (the Open Web). It's simply misdirection and does nothing to address the salient points of this debate.
A ship-date committment to a cross-browser version of "ajaxWrite", on the other hand, would.
Regards
AJAX = Amazing JavaScript And XUL AJAX = Almost JavaScript And XAML
It is analogous to l33t speak. 4j4x^/r1+3 y0!
The font you use on your post is so damn small, makes my eyes hurt!
http://www.michaelrobertson.com/ajaxtunes (later just http://www.ajaxtunes.com) is their latest product; it's nothing more than a Flash-based MP3 streamer controlled by a little Javascript. Ajax my red rosy ass.
http://www.ajaxxls.com/