JD on EP

For me the key advantages of XMLHttpRequest technology over Macromedia Flash-based RIAs are not ones of compatibility. They are ones of cost and UI consistency. RIAs are slow and costly to develop, whereas HTML routed interfaces and quick and cheap. With standard HTML, it's also just HTML. Everyone knows how to operate standard form elements so there's nothing to relearn. (I dislike the way that every Flash designer feels the need to reinvent how even something as simple as a scroll bar looks and operates).

It's a lot like comparing Apple Computer to Dell. Dell use standard components to assemble good products quickly and cheaply. Apple use custom components that come at a higher price and are less readily available, but the end result is something a bit special. Apple will always have a market (I'm typing this on a Powerbook), but Dell will consistently ship more units to business as such purchases are head, not heart decisions.

I'm rambling now :)

"RIAs are slow and costly to develop, whereas HTML routed interfaces and quick and cheap. "

Umm, how exciting. This is 180 degrees counter to everything I have seen and read from the world. I am quite willing to examine any evidence you might offer for such a startling assertion, however.

(Hmm, you might have an out there, because you wrote "it's just HTML, standard form elements", which is a little bit different than the topic under discussion. This would make it just a problem of reading comprehension and communication abilities, instead of the startling "ceiling is down, floor is up" type of statement this appears to be.)

Let's see, how might you demonstrate such a thing... some background on why Google Suggests is so browser-limited might be one path towards attempting to substantiate such a statement... getting some info on the actual development costs for Google Maps might be another... or having that evangelist article under discussion describing their product costs and timeframes like I originally mentioned might help make your case. Filesize comparisons for equivalent functionality might be an indirect indicator of such a globe-upending situation too. Any of these possible proof attempts sound attractive to you...?

(btw, it's okay to ramble, it's a full moon today, such things are expected.... ;-)

jd

Looked at the Ajax and thought: wow, they've invented Flash! Except it's kind of a crappy Flash.

Actually, John, the browsers seem to have reached a maturity level that by using standards, you can achieve a lot of functionality, with minimal "death by a thousand cuts" development. Whether that will be true in six months when Microsoft releases IE7, is another story. The advantage Flash has in this area is that it's not a standard and cannot be implemented independently or incompetently by separate companies intent on sabotaging each other.

Seriously, John, you find RIAs quicker to develop than HTML?

I've done a reasonable amount of work in Flash, and in particular XML driven dynamic interfaces, and my experience is that it takes an age because there's almost too much flexibility. Everything that can be taken for granted in a browser environment like a concept of pages that can be linked, browse history + controls, scale and flow and so on have to be built manually from scratch in Flash. Layout is difficult because there's no block model. Does Flash support CSS yet?

I think most of all it's difficult to script the creation of an app with Flash. Self-generating Flash is possible, but it's cumbersome. Look how quickly you can put together a basic HTML CRUD app with scaffolding in Ruby on Rails, for example. In less than a few minutes you can data flowing in and out of a database in a pretty functional way. Flash MX 2004 Pro takes about the same time just to launch, sadly.

Apart from the extra development time, there is extra expense involved in tools and personnel. It's hard to find good people who are also prepared to work with tools like Flash. I'm sure they exist, but finding someone who's a good Flash developer and is also geographically close and available for work is hard.

I was serious when I said that compatibility wasn't a key issue. If you're in a situation where you're using any sort of dynamic scripting like this (with ajax or RIAs) then it can be taken for granted that you've already assessed the needs of your audience.

I've got to get to a meeting, but will return here with more time later. Once again, I noted the lack of info about production costs and audience restrictions in that article... it could be buttressed by adding the context, in addition to the "we dun it!" aspect.

Google Suggest, Google Maps, Gmail... they have some star DHTML talent over at Google now (Tantrek, Goodger, Bosworth)... it would be useful to learn how these top-flight JavaScript engineers fared throughout the production process, the testing process, and (eventually) the maintainence and upgrade process.

Key concept: Are you making instructions for one engine, or many?

The key concept is *much* bigger than the number of engines you're writing for. That's trivial stuff.

Take your typical web app - not a small self-contained example like the Google Labs stuff or even something narrow in scope like Flickr - but a reasonably meaty software product delivered via the ASP model. Or a big app like Amazon.com. You may have 40 or 50 forms in there, a whole bunch of reports, 20 or 30 different listing pages, different kinds of search, commerce, accounting, you know the drill.

Now consider you might have an awkward bit of interface that could be smoothed out by being redesigned to make a few trips back to the server in the background. No problems - you can write some basic JavaScript (optimized for a small number of similarly behaved browsers, naturally) and get that sucker beat. Easy - perhaps a couple of hours work and some testing.

-or-

You can redevelop your entire app in Flash as an RIA. Hmmm

I can see how if you take a small, isolated example like Google Maps it would be better to develop that in Flash. I agree 100% on that point. Totally. Flash is the best tool for that job. But not for medium to large scale web application development of the sort of stuff that 99% of the people are doing 99% of the time. No way.

Recurring unanswered question here: How much did Gmail etc actually cost to develop, test and maintain, and what audience constraints do they impose? That's how this conversation started, and this has not yet been addressed.

(I was thinking about this discussion in the cab, and realized that no one has bothered doing an RIA-to-DHTML comparison because it is only recently that Google introduced their nice examples, and production costs are not discussed. There are no metrics to see how economically they measure up.)

"Number of engines" is extremely significant, as we saw with older DHTML using embedded data. Asserting the contrary does not prove the contrary. Safari and Opera users are locked out right now -- we haven't seen text-to-speech accessibility -- and then any port to mobile would be an entirely larger issue. Abstracting the underlying environment is a key factor in reducing development costs. Developing for five engines costs more than for one, particularly as project complexity increases.

Next clarification: "Web apps" use serverside interactivity and minimal clientside interactivity, with page-refresh model... distinct from the post-RIA generation with high clientside interactivity and separation of data from interactivity and display instructions. If we could avoid talking about the older "web apps" here that might help clarify the discussion.

(One further ambiguity in the original article is the name "Ajax"... as a reader, I could not tell whether the author used this as moniker for the general nouveau-DHTML approach, or if he had sold an actual JavaScript engine to Google. I suspect the former, but the writing implies the latter.)

How many developers spent how much time on Gmail? Google Suggests? Google Maps? How many QA engineers were there? How quickly will those costs increase in versions 2.0 and beyond? These are the missing parts in any "Go XMLHTTP!" discussion which uses those projects as examples.

John, I get the feeling you're just skim-reading and looking for dollar signs. I don't have access to Google's accounts any more than you do. However, even if we could put a figure on Google's investment, we don't have a figure for the same people doing the same project as an RIA, so it's meaningless.

I'm not going to bother explaining why compatibility isn't an issue or why vagaries of scripting engines are minutia yet again, because you probably won't read it and without the actual experience of the real world, you probably would appreciate it either.

You know, this is something I have to tell the seven-year-old, but it applies here too. If you're going to ask a question, you have to listen for the answer. Even if it's not the answer you were expecting.

JD -

Both models have there pros and cons.

DHTML: One can use pengoworks for older browsers (ie. Netscape 4.x), or xmlhttp for newer browsers. The cost of implementing this model is not too much since the code is just a google away. It will initially load the page quickly, since the data can be rendered in a div/span of form elements. The data can be compressed/uncompressed for large amount of data. DHTML doesn't have video capability and might lack in drag/drop ability.

Flash MX: Even Flex is usually slower to load than a html/js/css page. Flex has some nice drag/drop capabilities and the video of Flash can help in a help system. The cost of Flash/Flex is a higher initial cost (ie. FLEX) and developer cost can be a 'little' steep for some small/middle companies.

For those still reading, it seems that that term "AJAX" was just a newly-coined word by the original linked writer, which was swarmed by multiple blogs earlier this week. I'm still not sure whether Adaptive Path contributed to the Google apps described in that article.

(Patrick, I'm definitely with you on that "pro and con" issue... the task is always to fit the technology to the job, rather than, maybe, to force the religion upon the world.... ;-)

(And yes, Flex apps can have high initial transfer costs... number of different components is one frequent critical factor (these aren't just one big block of code; it's modular)... after that, though, it's just data transfers, as with "AJAX", without retransmission of local logic and display elements... the classic RIA argument reborn.)

jd