The Future of AJAX and the Rich Web

jg21 writes "This AJAXWorld Magazine article indicates how far AJAX has come since devs complained here two years ago that it sucked all the time. Eight experts were asked what questions we should now all be asking about where AJAX is headed next. The suggested questions are refreshingly hard-headed, including: 'How are we to fix the web?'; 'When will AJAX development finally be easy?'; and 'Do we really need JavaScript 2.0? Won't it be somewhat irrelevant by the time it becomes commonplace and thus usable?' One of the most interesting questions came from Kevin Hakman, co-founder of TIBCO's General Interface: 'On what timeline will AJAX skills become commoditized like HTML skills became?'"

Re:will AJAX development finally be easy?

[brunascle]

i was thinking the same thing. there's all of about 5-10 methods/properties to learn, and then you just need to know basic DOM functions for the response. it's not hard at all.

Re:Ajax will be obsolete before it becomes mainstr

[e4g4]

Ajax *is* mainstream - Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications. Now - as to your other claim, that Ajax doesn't stand up to Silverlight or Flash; I say Flash!?! Have you every built an application in flash? It's a nightmare to maintain. I can't speak to Silverlight, as I've not yet played around with it. But the design theory of ajax combined with a good JS api (like prototype [prototypejs.org]) Makes it a much more maintainable and IMHO a nice way to build interactive web apps.

the suck/non-suck divide

[abes]

I think a large part of the people's opinion on AJAX depends on what they're doing. It's difficulty depends in part on the framework/libraries you use. For example, script.aculo.us and RoR hide many of the details for you. On the other hand, if you do outside of what they do well, the difficulty level quickly rises.

I think one sign of this difficulty is that just about all AJAX libraries do the exact same thing. The same basic special effects, field additions, etc. The fact that none of the libraries go beyond these, points to what's hard to do.

Javascript isn't a great language. It's not robust, and it's difficult to really do good architecture with libraries using it. HTML is a pretty decent method to mark up text, but wasn't meant originally to ever be interactive.

Tying together a hacked together language with HTML doesn't make for the greatest programming experience. Especially compared to any real GUI framework.

Maybe most people don't want/need a real GUI framework, and AJAX covers all the bases for them -- in which you're probably going to say you like AJAX.

However, I suspect if AJAX and HTML were really so great/powerful/easy, many people would have stopped using flash already. I have no love for flash, but it can do things much more easily/faster than AJAX can for many tasks (disliking both technologies I'm pretty non-biased here).

What I would love to see is a standard *real* GUI for the web that is non-language dependent (i.e. whatever scripting language you prefer you can use). I'd even use something like Jython with newer/better GUI libraries. But we really need something written from the ground up with GUI in mind.

Re:HTML skills are a commodity?

[brunascle]

How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?

use the onclick attribute, with return false at the end to cancel the href. that way, you can use the href for a URL to degrade gracefully. for example, if it's opening a popup window, have the href be the URL of the page that loads in the popup.

Re:Do you also welcome AJAX hosts holding your dat

[AKAImBatman]

However, one thing that continues to surprise me is how willing most people are to having a third party store all of their data. All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider.

How does that differ from regular web applications holding your data? There's been well over a decade of time for users to become comfortable or uncomfortable with the idea of entrusting a third party with their data. So far, users have been leaning toward "comfortable".

Re:HTML skills are a commodity?

[Osty]

This is not pedantry. If you are thinking that layout is somehow achieved with <div> elements, then you are looking at things completely upside-down. You use the most appropriate element type for the information at hand, whether that's a table, a list, a paragraph, or whatever. You then arrange those elements with CSS. The particular element types you've used are not relevant to the layout. If you think <div> elements are in any way interesting for layout purposes, then you don't understand how the whole picture fits together.

A div is just a non-semantic block (just like a span is a non-semantic inline bit, though of course either of those could be changed by CSS). A table is very specific. Semantically, only tabular data should go into a table, and thus tables are completely wrong for layout. Divs, on the other hand, do make sense. For example, you're building a page with two columns, perhaps for a nav sidebar and a main content area. You have two separate components to your page, but they don't have any semantic meaning other than being blocks to put stuff (that is, they're not tabular data, list data, paragraphs, headings, etc). In that case, a div (short for "division", as in "page division" or something logically separate from other bits on the page) is absolutely correct to use. So now you have two divs on your page, one for the sidebar and one for the content. Using CSS, you can make these look however you like. Put the sidebar on the left or right, it doesn't matter (can't do that with a table without editing content). Put the "sidebar" along the top or bottom of the content area (can't do that with a table without editing content, either). Obviously that's CSS's doing, but you need something to work with in order to style appropriately. Within the sidebar, you have semantic data, as nav data can be considered a list. Within the content division, you have semantic data consisting of paragraphs, headings, etc. If you modelled your page as a table with a single row, with the sidebar being one cell and the content being another cell, your page is not semantic. Modelling it with divs, it is.

Divs can definitely be over-used. There are a lot of specific layouts that require wrappers and such, which usually means using divs. While you can avoid much of that, there's still some tag soup required if you want specific layouts with today's browsers, and you just have to deal with the fact that reality is intruding on your perfect little world. For my part, I would much rather have two divs wrapped in a third in order to do a two-column page layout than have a single table with columns as cells in the table.

Re:will AJAX development finally be easy?

[truthsearch]

Fair enough. I was awfully obnoxious, so I should make up for it with some actual information.

For a quick, but useful and accurate, starting point I like Mozilla's introduction [mozilla.org].

Then I recommend downloading and trying prototype [prototypejs.org]. It saves the mundane tasks, makes code a little easier to read, and is used by other popular frameworks.

Those cover the base scenarios. I haven't seen any good intermediate documentation. After the intros I suggest reading more reference documentation and just trying things out.

Re:will AJAX development finally be easy?

[brunascle]

here's a good intro [w3schools.com]. this assumes you have a file time.asp on your site that just outputs the time.

if, instead, time.asp outputs an XML file, in the code change .responseText to .responseXML, and from that you can use DOM functions (e.g. xmlHttp.responseXML.getElementsByTagName("time")[0].childNodes[0].nodeValue.

Re:will AJAX development finally be easy?

[iamacat]

I am sorry for the abuse you went through. I dabbled a bit with JavaScript and gave up when I found out that <img src="foo.gif" style="width: 50%;height:50%;"> does not work in IE, even the latest version of IE7. So I installed http://code.google.com/webtoolkit/ [slashdot.org]>gwt and gwt-ext [google.com] and had the first page of my application running in a couple of days using nothing but the plain Java code. I create a tree of serializable Java objects on the server and get the same tree on the client and then use it to update my UI.

My only complaint is crappy documentation. To understand gwt-ext I actually have to read the documentation of ext itself, with is Javascript based. I wish they copied the comments to javadoc. Then also to have a standalone text box on your page you need to put it inside a form and then set a bunch of options to make sure the form does not try to decorate the space around the text box in any manner.

Re:will AJAX development finally be easy?

[hobo sapiens]

How well do you know javascript?

As someone else pointed out, XMLHTTPRequest is what makes AJAX tick. But without knowing Javascript, what are you gonna do with it?

Assuming you are very good with javascript, here are two resources for you. 1 will help you see what the XMLHTTPRequest object does. 2 will help you tame it a bit and abstract things.
[1]: http://w3schools.com/ajax/default.asp [w3schools.com]
[2]: http://www.prototypejs.org/learn [prototypejs.org]

The thing is, the AJAX bit is a very small part of the total AJAX package. Then you'll need to learn JSON (a good data interexchange format) and how to use Javascript to create elements.

There, now that I have provided what you asked for and not just some smart alek remark about how you need to google it, this has to be said...If you seriously expect to master a useful skill in an afternoon, then you have some expectation issues. If there's one thing life has taught me, it's that something worth having doesn't come in a day, and if it does come in a day, it's probably not worth much. Did you learn to program in one day? No? Then why would you expect to learn a complex object and a totally new technique for making web applications on one day? But if you really want to learn then you'll thank me for those links later when your web development reaches the next level. If you are just bashing AJAX with a cudgel of ignorance, then you'll ignore those links and keep griping about AJAX being too hard. I guess time will tell.

Re:will AJAX development finally be easy?

[sackeri]

You just can't say it any better than that.

From a lot of the comments I get the impression that most people really don't get it. AJAX is incredibly useful, but it's mostly a really clever hack. The need for dynamically updating elements on the web page is definitely there, and AJAX manages to fill that need somewhat. But Javascript/DOM + XML/HTML is a terrible set of tools to build GUI widgets with.

AJAX works by sweeping the nitty-gritty details under the rug, but scratch the surface, and you realize how filthy the whole thing is. The first time you try to use a cool feature of your favorite GUI widget, and expect it to work the way your favorite desktop widget does, the cool-factor quickly degrades into frustration. Even with some of the best libraries out there, they still don't seem to have the problem licked.

It's amazing how far we have gotten with the tools available, but there really is a threshold forming due to these weaknesses. I'm not smart enough to envision how to get there, but there really needs to be a fundamental change that better integrates these technologies. Otherwise we're gonna be in spaghetti-code hell for a quite some time to come.

Re:will AJAX development finally be easy?

[hobo sapiens]

Please do not take offense, but the fact that you tried using the position property shows that you don't really understand CSS that well. That's not meant as an insult, just a statement of (apparent) fact. I just wrote a very simple page (just a div and image tag, no doctype or anything) that had this content:

<div style="width:40pt;height:40px;border:solid;">
    <img src="foo.png" style="width:50%;height:50%;" />
</div>


That displayed the image correctly in Firefox and IE6, the image's dimensions being 50% of the div's width and 50% of the div's height. Not that you *should* use points for dimensions, but that's just in keeping with what you said you did.

That said, browser behavior is very flaky. Your frustration is not unjustified. Especially with IE. IE sucks. There's not much more to say about it.

"It would be even better not to use the defective product at all, but that is hard when the vendor has a monopoly status."
Preaching to the choir, dude.

Re:silverlight

[moreati]

You are wrong, the web is a sloppy combination of repurposed standards and half-implementations that has evolved. It isn't clean, it isn't pretty but it works for the widest range of people: those with a web browser.

Silverlight is like flash, only worse:
* It ignores all the work on document layout and styling, instead it chooses to reinvent the wheel. XAML is untested beyond a few Windows developers and power users on Windows with a PC. HTML has been deployed, tested & debugged on about every platform in existence.
* It is in no way cross platform. The DLR class libraries are not an open specification beyond 'do what MS does', whomever independently implements it will be forever playing catchup. Needless to say MS will not be releasing the a DLR runtime for Solaris on SPARC anytime soon.
* It brings C# to the browser. It is my opinion that this move to a less expressive, more heavyweight language would be a step backward. In my opinion it would be better to fix Javascript, than to rip and replace with another language.
* Granted, the web does not have universal vector and HD video native to the browser. Neither would DLR/Silverlight, only Microsoft's implementation could be relied on to have full support of any given video format, due to restrictive licensing of US software patents. SVG support is improving in all browsers except Internet Explorer.
* Ease of update of a runtime is an implementation issue. It has nothing to do with how widely deployed implementations of a revised standard would be.

Silverlight is not the web and it is not an improvement in my opinion.

Re:Do you also welcome AJAX hosts holding your dat

[Xabraxas]

Oh, and Javascript was NOT designed as a "display customization language". It was originally designed to script (drumroll please...) Java. As in Java, Java. Not Java Applets (though that was included in the spec), but straight-up, plain-Jane, gosh-darn-that-looks-like-semantically-funny-Java Java. Mozilla still supports the full Livescript API in case you want to play around at some point.

Not exactly true. Javascript was not invented to be a scripting environment for Java. It wasn't named Javascript initially and the syntax is similar to C just as Java syntax is similar to C. In fact the name Javascript was more of a marketing ploy than anything else. Javascript was developed by a Netscape engineer and indeed seems to be invented for the purpose of web-based scripting, not Java scripting.

Re:Do you also welcome AJAX hosts holding your dat

[AKAImBatman]

Please check thy facts, kind sir. Javascript was conceived of as a Java-like script language. A poor man's Java for those that found object oriented concepts a little too brain intensive. Thrown in the first netscape browser to allow a little customisation of the DOM on the fly, for things that then then HTML 3 couldn't do properly.

You may be surprised to know that I am well in possession of the facts. I used to believe that Javascript (formerly Livescript, formerly Mocha) got its name in simply a cross-branding deal. In fact, it was far more complex than that. Javascript was created to script Java as well as the DOM. The original concept would have blown today's AJAX out of the water in usability. Alas, it was not to be.

Here's more history for you: http://safari.oreilly.com/0768666775/ch01lev1sec1 [oreilly.com]

Also, here's a bit of Javascript for you, demonstrating how powerful it was intended to be:

<script>
var myobj = Packages.javax.swing.JOptionPane;
var Frame = java.awt.Frame;

var frame = new Frame();

frame.show();

myobj.showConfirmDialog(frame, "Hello from Java! See Ma? No applet!");

frame.hide();
</script>

(That will work in FireFox with a recent Java plugin. I guarantee that it will not work on Internet Explorer.)

You have to remember, Java already existed in the browser when Javascript was created. Netscape internally discussed just using Java itself for scripting, but decided that a new, more dynamic scripting language would be more useful. (Source [netscape.com]) Thus the birth of Javascript. Eich described the first revision as "having gotten out of the lab a bit earlier than intended [scribemedia.org]". Javascript 1.1 was much closer to his vision, and what we think of today when we talk about Javascript.

You also need to understand that the Javascript language went beyond just the browser. Much of its development was driven by its use as a server-side CGI language [sco.com]. So it became a "real" language very quickly, despite its slow start.

And if you think that's cool, remind me sometime to tell you about how multipart/x-mixed-replace could have been server-side push long before AJAX, Comet, or <event-source> ever existed. ;)

Javascript is not an object oriented language.

Incorrect. Prototype-based languages [wikipedia.org] are very much OO languages. They're different from class-based, languages, but that doesn't make them any less powerful.

There is no polymorphesm

I think you misunderstand the very meaning of polymorphism if you believe that.

Here's the "Runnable" interface implemented in Javascript:

var MyObject1() {}
MyObject1.prototype.run = function() { alert("Running 1!"); }

var MyObject2() {}
MyObject2.prototype.run = function() { alert("Running 2!"); }

var objarray = [new MyObject1(), new MyObject2()];

for(var i=0; i<objarray.length; i++) objarray.run();

The polymorphism appears to work fine?

or inheritance

Funny, Netscape's Client Guide has an entire chapter [mozilla.org] on that.

strong type checking

Strong typing [wikipedia.org] is not a OOP requirement. It is a feature of some languages. Nothing more, nothing less. In any case, Javascript actually has quite a few typing fe