It is exceedingly hard to develop something like Google Suggest in a web app, particularly in a way that performs well and is portable. I hate the state of web apps. I think the "amazement" is a sense of awe that Google was able to pull off something so slick within the confines of a web app. I find nothing amazing about web app technology. All you get is a crude text box, a combo box, a list, and fonts. No real table components, no real tree components, no tabbed panes, no real drag and drop, no layout managers, the list goes on and on. Browsers are a pathetic platform for developing rich client applications. But you code with the tools you are given, not with the tools you want. Google suggest is an "amazing web app" but absolutely trivial had it been a Swing app.

(1) Mostly XMLHttpRequest, an easy way to push and pull data from the server via Javascript without hacking around with hidden iframes.

(2) Microsoft Internet Explorer 5. It was later adopted as a de facto standard in Mozilla 1.0 and later Safari 1.2

(3) Because of the slow browser upgrade cycle, and the need to wait until the feature is available to the vast majority of users. For example, until Safari 1.2, it would have been hard to deploy such an app and not have faced the wrath of the Mac community.

(4) No idea. Some unnamed engineer in Microsoft.

(5) This is hard to calculate. The main value from Google Suggest comes from all the effort that Google have put into making their search engine fast enough that such live queries are feasable.

Google also have a corporate culture in which engineers are encouraged to take a certain amount of time doing whatever interests them, in the hope it bears fruit. This feature could well be the result of such an exercise.

(6) In Google's case, this would be substantial, but on the other hand, search is the core of their business, and devoting significant resources to improving search is good for them.

And the supplementary questions:

The client-side components, obviously, are Javascript. While I have no evidence to back this up, I'd guess the server-side components were written in C, purely because they'd have to be as fast as possible.

Adding the capability to a blog search-box would not be feasable, as there'd be very little value added to a blog by having an interactive search box. (Most native search within blogs is hideously slow, for precisely the same reason). This fact does not discount the value of Google Suggest as a wake-up call to the otherwise moribund art of the web UI.

1) MSIE 5 was released in 1999. Safari 1.2 was released just over a year ago. XMLHttpRequest-enabled applications have been springing up regularly for the last year: I've noticed its use in Orkut, GMail, Amazon, Flickr and myspace.com, and I haven't even been looking for them.

2) The richer UI has been possible for three or four years, but it hasn't been generally supported for that long. Web applications are mostly bound by the web browser upgrade cycle, and for various reasons and accidents of history, the need to support Netscape 4 has been hovering over web applications like a black cloud for far longer than it should have.

People have been _experimenting_ with rich browser UIs ever since Javascript came out, but they've mostly been trying to reproduce the behaviour of thick clients in a very clumsy fashion, rather than improving the thin client experience gracefully.

The other aspect of the story is that progress doesn't just take a technology being available, it takes someone else to see the potential in that technology, and a whole bunch more people to use the results of that and pass on the word. I keep my head pretty close to the ground, and I didn't even know XMLHttpRequest existed before I used Orkut and asked "Hey, how did they do that?"

3) The breakage of the 'page load per server access' model may have complexity implications. But to be honest, it probably won't. The browser is requesting a piece of information. The fact that it doesn't use that information to display a whole new page is not something the server really need even care about.

4) This depends on what you want to do. You seem to have gone from "making a richer web UI" straight to "re-implementing a full-featured GUI in Javascript", without taking any notice of the value of the fertile ground in between.

I'm arriving a little late to this one, but I just wanted to add a little something here... I only see one reasonable alternative that is more mature than the one Google chose: Flash. Applets still suck for the majority of web users. Google could have added this functionality to their toolbar, but how many people have that installed? There are many apps that make sense to be on the web, and Flash and JavaScript/DHTML are the viable ways to provide a more responsive experience. By the way, dynamic updates of pages does not need to be difficult. Brent Ashley wrote a library a few years ago that didn't rely on XmlHttpRequest and had server-side code in several languages (JSRS was the name of the package). There's the pubsub library that people are working on today, and the netwindows.org library which provides a bunch of rich widgets. Judicious application of this technique can give a real competitive advantage to a web app. Seeing GMail's slick interface in action was enough to make Yahoo! buy Oddpost.