SWG Goes to Google
Super Web Group spent the evening of April 27th at Google Learning about how they’re using a controversial programming language called AJAX.
There has been a lot of talk recently (among programmers) about AJAX. It’s a programming language that consists of JavaScript, XML and DHTML and has been around for a while but is finding new favor among cutting edge companies, such as Google.
If AJAX takes off and browser and server protocols are standardized in a way that makes it an easily testable, secure and browser-compatible language, it will change your web experience 110%. The main benefit of AJAX web applications is that they make asynchronous calls to the server, which creates a more seamless and exciting web experience. That means the application back-fills information and basically breaks the browser window into components.
Traditionally, when a browser open’s a web page, it calls one static HTML page of information from the server. This has been referred to as load time. With AJAX applications, many little calls are made at various times as a visitor interacts with a web page so that it feels as if there is no load time for a more seamless experience.
The downside is that AJAX basically makes the browser do things that it wasn’t really intended to do - it pushes the medium. And, the medium pushes back.
One of the biggest differences between an AJAX application and most poplar web applications is that it is a client-side dominant application. What this means is that first it downloads the entire application to your desktop and stays open to receive and send information. While having an application on your harddrive makes for smoother transitions, it poses security risks because it's hard to validate senders/receivers due to its asynchronous model.
And, as we know, client side applications are plagued by incompatibility because there is no way, currently, to standardize browser protocols.
Finally, the whole application has to be very carefully and painstakingly tested for each component on each page to assure that the narrowly defined audience of browser it’s targeting will actually be able to process the application.
As with any fun and interesting web application, it will exclude the majority and only work for a slim minority of web browser and platform configurations. Also, IE and Netscape, Mozilla, FireFox, AOL and other browsers are slow to make updates to accommodate the latest technology, so for those reasons mentioned above, we’re sticking with Microsoft’s ASP/.NET just a little bit longer.
There has been a lot of talk recently (among programmers) about AJAX. It’s a programming language that consists of JavaScript, XML and DHTML and has been around for a while but is finding new favor among cutting edge companies, such as Google.
If AJAX takes off and browser and server protocols are standardized in a way that makes it an easily testable, secure and browser-compatible language, it will change your web experience 110%. The main benefit of AJAX web applications is that they make asynchronous calls to the server, which creates a more seamless and exciting web experience. That means the application back-fills information and basically breaks the browser window into components.
Traditionally, when a browser open’s a web page, it calls one static HTML page of information from the server. This has been referred to as load time. With AJAX applications, many little calls are made at various times as a visitor interacts with a web page so that it feels as if there is no load time for a more seamless experience.
The downside is that AJAX basically makes the browser do things that it wasn’t really intended to do - it pushes the medium. And, the medium pushes back.
One of the biggest differences between an AJAX application and most poplar web applications is that it is a client-side dominant application. What this means is that first it downloads the entire application to your desktop and stays open to receive and send information. While having an application on your harddrive makes for smoother transitions, it poses security risks because it's hard to validate senders/receivers due to its asynchronous model.
And, as we know, client side applications are plagued by incompatibility because there is no way, currently, to standardize browser protocols.
Finally, the whole application has to be very carefully and painstakingly tested for each component on each page to assure that the narrowly defined audience of browser it’s targeting will actually be able to process the application.
As with any fun and interesting web application, it will exclude the majority and only work for a slim minority of web browser and platform configurations. Also, IE and Netscape, Mozilla, FireFox, AOL and other browsers are slow to make updates to accommodate the latest technology, so for those reasons mentioned above, we’re sticking with Microsoft’s ASP/.NET just a little bit longer.

