Will Ajax help Google clean up?

(continued from previous page)

threat posed by Microsoft's plans for the proprietary XAML/Avalon Web and Windows application coding system that, if successful, could marginalize standard approaches.

"Microsoft published an outline of what they were trying to achieve, which is using markup languages to build applications," said Hakon Wium Lie, chief technology officer at Opera Software, that company's representative on W3C's advisory committee, and a WHAT-WG founder. "We thought we could do the same thing with existing Web languages. People were writing applications like Amazon and Hotmail and Google search, so why not have a specification for it?"

One benefit of working with JavaScript and HTML, say proponents, is the preponderance of experienced developers as compared with Flash developers or specialists in other systems. Flash, while widely distributed, isn't as universal as a Web browser, and some developers say their clients fret about Flash-incompatible firewalls.

Some developers mix and match. The popular online photo site Flickr, for example, uses Flash for some tasks and JavaScript for others on the same page.

Passing fad?
Technologists working on the next generation of Web application technologies scoff at the idea that a JavaScript renaissance is going to threaten their vision of the future. Instead, they insist Google's rising tide is lifting their boats.

"For a company serving that many people at that scale, Google is taking uncharacteristic risks on their front end to do things that other companies with old infrastructures in place don't know are even possible," said Laszlo's Temkin. "I'm incredibly happy that Google is taking this step, because it's forcing the market to realize what to us has been incredibly obvious about rich Internet applications. It's forcing the portals and others to notice the value here. That's tremendous for us."

"Google is taking uncharacteristic risks on their front end to do things that other companies with old infrastructures in place don't know are even possible."

--David Temkin, chief technology officer, Laszlo Systems

By the same token, Google denies any ideological attachment to its standards-based approach. Instead, the company says it has evaluated all the options before it and will continue to do so as new technologies become available or existing ones get refined.

The JavaScript approach, Google acknowledges, leaves some things to be desired. For example, it's harder to integrate applications with third-party applications.

In the final analysis, however, Google has given JavaScript that crucial programming designation: good enough.

"We've considered these other things, and we've talked about some of the other options, but thus far the technologies haven't gotten to the point where we feel the need to switch to them," said Paul Buchheit, the Google engineer who spearheaded the Gmail project.

"If something like Avalon or Mozilla's XUL (Extensible User Interface Language) were to become powerful and common enough, that would be interesting to us," Buchheit said.

Ultimately, any push away from JavaScript and other DHTML technologies may stem less from the improvement of other options than from the demands of the applications.

"Google is a first step or second step, not an end point," Temkin said. "The successors to Word and Excel and Powerpoint are not going to be written this way. It's just not going to happen."

[citizencontact]

Actually the story is more about the success of XML

The success of JavaScript and CSS stylesheets has a lot to do with its ability to process XML and XHTML. As long as HTML was non-compliant in terms of XML, depended on imperfect presentation tools (e.g. tables for design), and was very kludgy in terms of showing XML, other technologies were seen as necessary. HTML, in its XHTML incarnation, is an excellent "query result" document. The division of presentation, code and data is now possible with the triad of CSS, JavaScript, and XHTML.

Your next article might be on how XQuery is sneaking up to allow for database access into XML documents.

For performance, XML is a BAD choice for Google Maps

Here we go again. XML was probably not used here due to the extremely high performance necessary for Google Maps.

Knowing Google, they DO NOT use XML. They use shortened data, the shortest possible. Variable names are kept to a few characters at most. Anywhere they can eliminate a space or a carriage return, they do.
It's probably some sort of comma delimited string anyway.

XML is so unnecessary verbose and wordy there is no need for such overhead.

Again, typical I.T. so-called architects, authors and so on get it WRONG again.

[citizencontact]

Actually the story is more about the success of XML

The success of JavaScript and CSS stylesheets has a lot to do with its ability to process XML and XHTML. As long as HTML was non-compliant in terms of XML, depended on imperfect presentation tools (e.g. tables for design), and was very kludgy in terms of showing XML, other technologies were seen as necessary. HTML, in its XHTML incarnation, is an excellent "query result" document. The division of presentation, code and data is now possible with the triad of CSS, JavaScript, and XHTML.

Your next article might be on how XQuery is sneaking up to allow for database access into XML documents.

For performance, XML is a BAD choice for Google Maps

Here we go again. XML was probably not used here due to the extremely high performance necessary for Google Maps.

Knowing Google, they DO NOT use XML. They use shortened data, the shortest possible. Variable names are kept to a few characters at most. Anywhere they can eliminate a space or a carriage return, they do.
It's probably some sort of comma delimited string anyway.

XML is so unnecessary verbose and wordy there is no need for such overhead.

Again, typical I.T. so-called architects, authors and so on get it WRONG again.

[David Arbogast]

Explain the error....

The article suggests that the Google map site only uses older common technologies such as javascript and DHTML. It even alludes to the fact that they avoided Microsoft technology.

Maybe somebody can explain why, when I visit the site with IE and leave ActiveX disabled, I receive this error:

"ActiveX is not enabled in your browser. If your browser is Internet Explorer, you must have ActiveX enabled to use Google Maps."

It would seem that Google Maps uses DHTML, javascript, and ActiveX... no?

[David Arbogast]

Found It

XML DOM.
I guess the map site does use XML all the way to the client, and then parses it on the client machine. So, I'm guessing you get a different version of the site depending on which browser you use...??

[JuggerNaut]

Active-X and Google Maps???

I'm not sure about how Google Maps work with IE for Windows users, but it sure does work as expected for Mac and Linux (with Safari, Firefox and Opera), which lack Active-X. So I'm assuming either that Google provides different functionality for different browsers, or maybe not??

[David Arbogast]

Explain the error....

The article suggests that the Google map site only uses older common technologies such as javascript and DHTML. It even alludes to the fact that they avoided Microsoft technology.

Maybe somebody can explain why, when I visit the site with IE and leave ActiveX disabled, I receive this error:

"ActiveX is not enabled in your browser. If your browser is Internet Explorer, you must have ActiveX enabled to use Google Maps."

It would seem that Google Maps uses DHTML, javascript, and ActiveX... no?

[David Arbogast]

Found It

XML DOM.
I guess the map site does use XML all the way to the client, and then parses it on the client machine. So, I'm guessing you get a different version of the site depending on which browser you use...??

[JuggerNaut]

Active-X and Google Maps???

I'm not sure about how Google Maps work with IE for Windows users, but it sure does work as expected for Mac and Linux (with Safari, Firefox and Opera), which lack Active-X. So I'm assuming either that Google provides different functionality for different browsers, or maybe not??

[JuggerNaut]

Keeping the World Wide Web 'open' is most important

Keeping Microsoft from locking the web into a proprietary mess (XAML/Avalon, etc...) is what is most important because it ensures that the web will remain open and free with maximized inoperability and compatibility amongst the wide range of computer platforms out there. I sure hope that Google wins the hearts and minds of those who prefer that the web should be accessible to all who surf the net.

[TerryField]

We have to deal with what's here and now

Web standards have largely created the opportunity to build these so-called AJAX applications. What is not obvious to a lot of people is that until recently web developers have had to factor in Netscape 4 users because there were still a significant percent of them out there.

These days we predomninantly have IE and mozilla-based browsers with a smattering of Safari and Opera. While the latter two are a still a little problematic, the first two cover about 98% of the user base. Between them have a sufficient set of common functionality that they can be considered 'standard', so long as you keep to that common subset.

If Microsoft want to run off and create a better way of building these applications, then they need to consider that developers won't touch it unless they're dealing with a captive audience. As long as you have proprietry extensions, there will be a percentage of the user base that won't have the technology. Besides, how long is it going to take to see these browsers proliferate.

While it is true that build AJAX applications is slow and hard to get right, that can be alleviated over time by developing libraries of standard functions. There is a real growth industry here. For the present, this is what's going to deliver the richer user interactivity with the browser.

[JuggerNaut]

Keeping the World Wide Web 'open' is most important

Keeping Microsoft from locking the web into a proprietary mess (XAML/Avalon, etc...) is what is most important because it ensures that the web will remain open and free with maximized inoperability and compatibility amongst the wide range of computer platforms out there. I sure hope that Google wins the hearts and minds of those who prefer that the web should be accessible to all who surf the net.

[TerryField]

We have to deal with what's here and now

Web standards have largely created the opportunity to build these so-called AJAX applications. What is not obvious to a lot of people is that until recently web developers have had to factor in Netscape 4 users because there were still a significant percent of them out there.

These days we predomninantly have IE and mozilla-based browsers with a smattering of Safari and Opera. While the latter two are a still a little problematic, the first two cover about 98% of the user base. Between them have a sufficient set of common functionality that they can be considered 'standard', so long as you keep to that common subset.

If Microsoft want to run off and create a better way of building these applications, then they need to consider that developers won't touch it unless they're dealing with a captive audience. As long as you have proprietry extensions, there will be a percentage of the user base that won't have the technology. Besides, how long is it going to take to see these browsers proliferate.

While it is true that build AJAX applications is slow and hard to get right, that can be alleviated over time by developing libraries of standard functions. There is a real growth industry here. For the present, this is what's going to deliver the richer user interactivity with the browser.

Accuracy Matters

While it is interesting that they use Javascript and XML, these are not noticeable to customers. It is the quality of the information. The neat graphics only go so far. If a query to a map returns a location that is a half-mile from the actual location, then it won't take long to figure that out. The real task confronting the dataMegaMarts is improving accuracy.

For that reason, the dataMegaMarts cannot rely on spidering the web itself. They have to purchase data from companies that make it their business to ensure the data is high quality and vetted. What is emerging is a feedback loop where some companies (such as Answer.com or GuruNet) can provide services to the dataMegaMarts and buy services as well. This is an interesting ecotone in the evolution of the system because the rate of exchange is high and the potential to evolve quickly is there.

Accuracy Matters

While it is interesting that they use Javascript and XML, these are not noticeable to customers. It is the quality of the information. The neat graphics only go so far. If a query to a map returns a location that is a half-mile from the actual location, then it won't take long to figure that out. The real task confronting the dataMegaMarts is improving accuracy.

For that reason, the dataMegaMarts cannot rely on spidering the web itself. They have to purchase data from companies that make it their business to ensure the data is high quality and vetted. What is emerging is a feedback loop where some companies (such as Answer.com or GuruNet) can provide services to the dataMegaMarts and buy services as well. This is an interesting ecotone in the evolution of the system because the rate of exchange is high and the potential to evolve quickly is there.

[dinkhome]

XAML/Avalon isn't about web apps

While I found this article interesting - saying that a rise in the use of DHTM is a threat to XAML is inaccurate.

XAML is a Windows application UI markup language - not a web application markup language. It is used to create interfaces for native windows applications. It is hoped to facilitate thin client/smart client development - but could work for any type of Windows GUI application.

Occasionally. MS shows XAML UIs running in IE, but that is not its main purpose.

Another "Ooo - MS is in trouble now" article - too bad the point is deluted by this slant.

point well taken

Yes, Avalon and XAML are designed to create Windows applications that are tightly integrated with the Web. But the point about competition stands. If a Microsoft competitor can create powerful, fast and scalable Web applications that run on any browser on any networked computer with a standards-compliant computer, how does that affect a consumer's decision to shell out for a Windows upgrade when Longhorn finally ships? The viability of the JavaScript approach poses the same kind of Web vs. Windows threat that inspired Microsoft to take on Netscape ten years ago. I'll reserve judgment on how serious that threat is in this instance, but I would hazard a guess that the Outlook team is looking long and hard at Gmail. The Hotmail team certainly had to.

[JuggerNaut]

XAML and XUL will have a future in web development

Of course we all know that the XAML/Avalon combo will set a basis for future UI development for Windows applications, be we all also know the potential of anything XML has on the future of the web. XML's first success was databases (if I'm correct) and now it's defining the way we describe documents, spreadsheets and etc... and with web developers playing around with XUL (Mozilla's own UI specification via XML) shows the grand possibilities and its forward thinking approach to web-based applications. Microsoft's own XAML will also play a role in this arena if Windows-centric web developers make it happen. The only scary thing is if the web is infiltrated with XAML (a closed and proprietary standard that works only on Windows at this time) over XUL (an open standard that works pretty much everywhere Mozilla does), this will put a damper on the web and its greatest asset; openness.

examples of XUL and future web-based applications...

<a class="jive-link-external" href="http://www.faser.net/mab/remote.cfm" target="_newWindow">http://www.faser.net/mab/remote.cfm</a>

[dinkhome]

XAML/Avalon isn't about web apps

While I found this article interesting - saying that a rise in the use of DHTM is a threat to XAML is inaccurate.

XAML is a Windows application UI markup language - not a web application markup language. It is used to create interfaces for native windows applications. It is hoped to facilitate thin client/smart client development - but could work for any type of Windows GUI application.

Occasionally. MS shows XAML UIs running in IE, but that is not its main purpose.

Another "Ooo - MS is in trouble now" article - too bad the point is deluted by this slant.

point well taken

Yes, Avalon and XAML are designed to create Windows applications that are tightly integrated with the Web. But the point about competition stands. If a Microsoft competitor can create powerful, fast and scalable Web applications that run on any browser on any networked computer with a standards-compliant computer, how does that affect a consumer's decision to shell out for a Windows upgrade when Longhorn finally ships? The viability of the JavaScript approach poses the same kind of Web vs. Windows threat that inspired Microsoft to take on Netscape ten years ago. I'll reserve judgment on how serious that threat is in this instance, but I would hazard a guess that the Outlook team is looking long and hard at Gmail. The Hotmail team certainly had to.

[JuggerNaut]

XAML and XUL will have a future in web development

Of course we all know that the XAML/Avalon combo will set a basis for future UI development for Windows applications, be we all also know the potential of anything XML has on the future of the web. XML's first success was databases (if I'm correct) and now it's defining the way we describe documents, spreadsheets and etc... and with web developers playing around with XUL (Mozilla's own UI specification via XML) shows the grand possibilities and its forward thinking approach to web-based applications. Microsoft's own XAML will also play a role in this arena if Windows-centric web developers make it happen. The only scary thing is if the web is infiltrated with XAML (a closed and proprietary standard that works only on Windows at this time) over XUL (an open standard that works pretty much everywhere Mozilla does), this will put a damper on the web and its greatest asset; openness.

examples of XUL and future web-based applications...

<a class="jive-link-external" href="http://www.faser.net/mab/remote.cfm" target="_newWindow">http://www.faser.net/mab/remote.cfm</a>

[bahead]

Hurray for Google for using standard web technologies

Hurray for Google! While I acknowledge that proprietary technologies such as Flash have a place on the web, they are not standard technologies and they ultimately tie the web to specific corporate interests. Imagine a future where Flash is used for everything online - do we want Macromedia to have that control? (The same applies to Microsoft).

The fact is, the simplest solution is usually the best one. I see a lot of web sites that use Flash to do things that could be easily done using JavaScript/DHTML -- and with much smaller file sizes.

I'm glad to see a company like Google leveraging DHTML and JavaScript for their applications. These technologies aren't the solution for all interactivity, but they are available for all developers and they are free.

Other than the impact of Flash, the reason that DHTML/CSS were never exploited to their full potential in the 1990s was because of a lack of standards support in web browsers (e.g., very poor support in Netscape 4). This made it very difficult to create DHTML applications that worked properly cross-browser and cross-platform.

If browser companies had invested their time and effort in standardizing DTHML/CSS and fully exploiting these technologies, maybe we'd be further ahead. Instead, companies like Microsoft continually abandon older web technologies before they are perfected and introduce new ones (just like their operating systems).

[bahead]

Hurray for Google for using standard web technologies

Hurray for Google! While I acknowledge that proprietary technologies such as Flash have a place on the web, they are not standard technologies and they ultimately tie the web to specific corporate interests. Imagine a future where Flash is used for everything online - do we want Macromedia to have that control? (The same applies to Microsoft).

The fact is, the simplest solution is usually the best one. I see a lot of web sites that use Flash to do things that could be easily done using JavaScript/DHTML -- and with much smaller file sizes.

I'm glad to see a company like Google leveraging DHTML and JavaScript for their applications. These technologies aren't the solution for all interactivity, but they are available for all developers and they are free.

Other than the impact of Flash, the reason that DHTML/CSS were never exploited to their full potential in the 1990s was because of a lack of standards support in web browsers (e.g., very poor support in Netscape 4). This made it very difficult to create DHTML applications that worked properly cross-browser and cross-platform.

If browser companies had invested their time and effort in standardizing DTHML/CSS and fully exploiting these technologies, maybe we'd be further ahead. Instead, companies like Microsoft continually abandon older web technologies before they are perfected and introduce new ones (just like their operating systems).

Ahhh! This is what I've been saying!

I've been writing web apps like this for 3 years now! Why is that when Google does it, it's something special!
I mean congratulations on discovering the wheel here!
I was totally here first www.jonandnic.com/jonathan/jsobjects

Um, you were not "totally first here"

If you've been doing this for 3 years then you were not "totally first here." Stuff like this has been possible since at least 1998, and even Dreamweaver has provided features for this going back to its first release.

Ahhh! This is what I've been saying!

I've been writing web apps like this for 3 years now! Why is that when Google does it, it's something special!
I mean congratulations on discovering the wheel here!
I was totally here first www.jonandnic.com/jonathan/jsobjects

Um, you were not "totally first here"

If you've been doing this for 3 years then you were not "totally first here." Stuff like this has been possible since at least 1998, and even Dreamweaver has provided features for this going back to its first release.

[Chung Leong]

Another retarded article

The newsworthiness of this article is zero. What's so special about s web site using a matured technology like DHTML? Google uses a GIF for their logo. Is that a "blast from the past" too?

[Chung Leong]

Another retarded article

The newsworthiness of this article is zero. What's so special about s web site using a matured technology like DHTML? Google uses a GIF for their logo. Is that a "blast from the past" too?

Looking forward to SDKs and more...

I was building something using a similar approach
along these lines from late 1999-thru-early-2003,
and stopped because I thought I was going down the wrong path... And was in the process of ramping
this work back up and going with a more
traditional approach, i.e Java Server Pages, or
PHP with a fairly static user view...

see: <a class="jive-link-external" href="http://qbal.mozdev.org/oldQbal.jpeg" target="_newWindow">http://qbal.mozdev.org/oldQbal.jpeg</a>

I may ramp the old stuff back up again...

Looking forward to SDKs and more...

I was building something using a similar approach
along these lines from late 1999-thru-early-2003,
and stopped because I thought I was going down the wrong path... And was in the process of ramping
this work back up and going with a more
traditional approach, i.e Java Server Pages, or
PHP with a fairly static user view...

see: <a class="jive-link-external" href="http://qbal.mozdev.org/oldQbal.jpeg" target="_newWindow">http://qbal.mozdev.org/oldQbal.jpeg</a>

I may ramp the old stuff back up again...

[tfardella]

Missing Link

The main reason that everyone is getting so excited about
"AJAX" and Javascript in general centers around a object that was
added in the past year or so.

The XMLHttpRequest object allows Javascript to send a query to
a server and receive a response. This is the key that is opening
up all kinds of new doors. Before, Javascript was pretty much
limited to using data that was loaded in the initial page load. If
you wanted new data you reloaded the page. Javascript has
always had to ability to update sections of a web page using it's
DOM and XML abilities.

Funny thing is that it was Microsoft that first added this to their
version of Javascript in IE5. Other browsers followed suit shortly
after.

Apple has a very good article on using this functionality on their
developer website:

<a class="jive-link-external" href="http://developer.apple.com/internet/webcontent/" target="_newWindow">http://developer.apple.com/internet/webcontent/</a>
xmlhttpreq.html

hidden frame works too

In the past I simply used a hidden frame to pass data between the browser and the server, and with mozilla used the sidebar for persistence

see: <a class="jive-link-external" href="http://qbal.mozdev.org/oldQbal.jpeg" target="_newWindow">http://qbal.mozdev.org/oldQbal.jpeg</a>

[tfardella]

Missing Link

The main reason that everyone is getting so excited about
"AJAX" and Javascript in general centers around a object that was
added in the past year or so.

The XMLHttpRequest object allows Javascript to send a query to
a server and receive a response. This is the key that is opening
up all kinds of new doors. Before, Javascript was pretty much
limited to using data that was loaded in the initial page load. If
you wanted new data you reloaded the page. Javascript has
always had to ability to update sections of a web page using it's
DOM and XML abilities.

Funny thing is that it was Microsoft that first added this to their
version of Javascript in IE5. Other browsers followed suit shortly
after.

Apple has a very good article on using this functionality on their
developer website:

<a class="jive-link-external" href="http://developer.apple.com/internet/webcontent/" target="_newWindow">http://developer.apple.com/internet/webcontent/</a>
xmlhttpreq.html

hidden frame works too

In the past I simply used a hidden frame to pass data between the browser and the server, and with mozilla used the sidebar for persistence

see: <a class="jive-link-external" href="http://qbal.mozdev.org/oldQbal.jpeg" target="_newWindow">http://qbal.mozdev.org/oldQbal.jpeg</a>

Well, let's see...

&gt;If a Microsoft competitor can create powerful, fast
&gt;and scalable Web applications that run on any
&gt;browser on any networked computer with a
&gt;standards-compliant computer, how does that affect
&gt;a consumer's decision to shell out for a Windows
&gt;upgrade when Longhorn finally ships?

Well, gosh, let's see. How useful is a DHTML web app when you don't have a live internet connection? Oh, that's right - you can't use it when you're offline.

How useful is a DHTML web app when you want to integrate the content into another application? Oh, that's right - it's a self-contained web page running in a browser.

How useful is a DHTML web app when it needs to work directly with the client system, for doing things like working with local files? Oh, that's right, web apps can't do that.

There's a time and a place for web apps, and a time and a place for local client apps. PhotoShop and Dreamweaver will NEVER be implemented as web apps. they just don't fit the model. There's plenty of other examples of this.

Well, let's see...

&gt;If a Microsoft competitor can create powerful, fast
&gt;and scalable Web applications that run on any
&gt;browser on any networked computer with a
&gt;standards-compliant computer, how does that affect
&gt;a consumer's decision to shell out for a Windows
&gt;upgrade when Longhorn finally ships?

Well, gosh, let's see. How useful is a DHTML web app when you don't have a live internet connection? Oh, that's right - you can't use it when you're offline.

How useful is a DHTML web app when you want to integrate the content into another application? Oh, that's right - it's a self-contained web page running in a browser.

How useful is a DHTML web app when it needs to work directly with the client system, for doing things like working with local files? Oh, that's right, web apps can't do that.

There's a time and a place for web apps, and a time and a place for local client apps. PhotoShop and Dreamweaver will NEVER be implemented as web apps. they just don't fit the model. There's plenty of other examples of this.

With all due respect to David Mendels

Google didn't succeed at this because they hired "Rocket Scientists". Information about how to develop applications using this method have been available for years, and it's just a question of developers learning to use the tools out there to get the job done.

Of course, if you're just a script kiddie, then something like this is probably out of reach. But does David really think that developing these kinds of apps with Flash is easier? ***?

With all due respect to David Mendels

Google didn't succeed at this because they hired "Rocket Scientists". Information about how to develop applications using this method have been available for years, and it's just a question of developers learning to use the tools out there to get the job done.

Of course, if you're just a script kiddie, then something like this is probably out of reach. But does David really think that developing these kinds of apps with Flash is easier? ***?

really, really, really hard

&gt;"It is really, really, really hard to build
&gt;something like Gmail and Google Maps," said David
&gt;Mendels, general manager of platform products for
&gt;Macromedia

No it's not. In fact now that I've gotten the hang of it, I'd almost say its easier to make a web app this way. The biggest thing google did was publicize that this sort of functionality was available. I never heard of it until I noticed gmail was doing something unusual to retrieve data. But to my suprise IE, firefox, &#38; mozilla have supported it flawlessly for years.

If this 'hurts' anyone it's going to dent Flash. I just built a web app using the XML/DHTML technique in place of the originally planned Flash interface.

David, baby, give me a jingle. I'll get you guys up to speed in no time. Low six figures.