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?'"

Comments

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) Makes it a much more maintainable and IMHO a nice way to build interactive web apps.

marchitecture alert

[anomalous cohort]

I claim first serious post.

Most of these questions appear to me to be either leading questions, whose intent is to foment desire in the questioners product(s) and/or service(s), or marketing questions.

Some of the questions are legit, however. For example, those questions concerning security, performance, unit testing, and analytics.

With regards to the question about which framework to choose, I have posted my favorites here.

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:the suck/non-suck divide

[Osty]

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.

Once you understand it, Javascript is an awesome language. It's C/C++/Java-like syntax hides its fundamentally functional underpinnings. The core datastructure in Javascript is a method. Everything can be represented in terms of methods, even to the point of not using any variables. With that in mind, it's a very powerful language that is often maligned precisely because of what it is -- many people just don't "get" functional languages (why C/C++/Java/etc are so popular and Lisp/ML/Haskell/etc are not), though you can certainly write procedural or even OO code in Javascript. It's also very easy to shoot yourself in the foot with Javascript, depending on implementations (using anonymous methods is a good way to leak memory in IE if you're not careful, for example).

As a scripting language, Javascript has a lot too offer. Too bad it's been forever tied to HTML and web stuff.

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).

People like Flash because it gives you lots of pretty, shiney bits for very little work. It's also vector-based, so you can build a pixel-perfect layout like so many bad web designers want ("Our web site must look exactly like our magazine"). Too many people associate "AJAX" with flashy Web 2.0-y visual effects (fading highlights, rounded corners, wet reflections, large fonts, etc), when AJAX is really about communication. If all you care about is glitz, go ahead and use Flash. If you want to build something that actually works well, I'd go with javascript+HTML.

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).

You may not want to hear it, but Microsoft has much of that with ASP.Net AJAX, as have others like Script#. In each case, you're writing most (or all, in the case of Script#) of your code in a .NET langauge and the compiler handles generating the javascript appropriate for your target browser(s). These work with at least Firefox and IE, and should also work with Safari, Opera, and others with minor tweaking.

Re:will AJAX development finally be easy?

[Larry Lightbulb]

Ok, point me to a place where I can pick up all the knowledge I need to use it, I've got a free afternoon. And I mean that seriously.

Re:will AJAX development finally be easy?

[jma05]

The challenge is not technical. Devs need to change their mindsets while about thinking about web applications. I am not talking about putting an occasional AJAX widget. The change is from synchronous to asynchronous web applications. That's about as big a change as writing distributed applications for someone who mostly wrote 1-tier applications. Design is different as is debugging.

when will AJAX skills become commoditized?

[Ralph Spoilsport]

'On what timeline will AJAX skills become commoditized like HTML skills became?'"

Easy: when a WYSIWYG editor, a la Dreamweaver, can accomplish all basic AJAX functionality without having to mess with much, if any, code.

Yeah - sure - Dreamweaver is suboptimal, but for 95% of what you need in a site (and if your site is fairly simple, 100%) it does the job, just fine, and you don't need to mess with that messy HTML and javascripty goopety glop. you just treat it like InDesign or Quark, and design your page - no muss, no fuss, nothing too fancy.

When Dreamweaver (or some similar app yet-to-be-developed) can do Exactly That - let me do AJAX without touching code, then you know AJAX coding skills will commoditise and disappear. How many hear can read PostScript, raise your hands! Not too many. I figured as much... FreeHand, Fontographer, and Illustrator removed the need to know how to program a page description in PostScript. Dreamweaver ate HTML and trivial Javascript. AJAX is next... I'd say, give it 2 years. Tops. I'm sure the programmers at Adobe are hard at work mulling over how to do just that.

RS

how far HAVE we come?

[vsync64]

It does suck.

As for the "refreshing[] hard-headed" questions, all I see are questions about performance and silly flitting about with their own buzzwords and pipe dreams about getting rid of real applications in favor of their toys.

Here are some questions:

• Whatever happened to degrading gracefully? If you look at the apps produced by Google, the poster child for "AJAX", you'll see that they took the time to make most or all of the functionality work without JavaScript, without images, without CSS, or with a deranged hodgepodge of those. I don't see others making the same efforts.
• How about semantics, and security? We're getting back into the mess of data intermingled with code. I'm seeing more and more sites out there have a blank page that loads, and then JavaScript that loads the content. Now you have to have scripting enabled for every site you visit. MS Office macros all over again. And forget trying to spider the content without having some sort of bizarre Turing machine debugger to try to get at the real content.
• Yeah, how about mobile devices? If you were doing it right (see above) you wouldn't have to worry about the iPhone or about a special mobile AJAX. It would work fine within the constraints of any device. Google does.
• How do you plan to interact with the local filesystem? Java has an effective sandbox, signed codebases, and granular user permissions (although the latter are kind of sucky). Are users not allowed to retain control over their own data?
• How are users supposed to have any confidence about what you're doing to them? The previous model was good. Users knew when they were sending anything to the server, and if the UA vendors would do their jobs they would also know when they were affecting data. What are users supposed to do now, have wireshark running all the time? Not acceptable.

I'm implementing Web-based applications as of this writing, and I plan to have some dynamic features to simplify some of the UI (such as cascading follow-up questions during user signup). But these will be an optional extra.

These jokers forget that the World Wide Web is a repository for mutual citation of academic-style documents. New stuff is good, just don't break the old stuff.

Every improvement on the Internet has been in the direction of better user controls, decentralization, caching, peer-to-peer, transport tunnels, etc. The AJAX people are swimming against the tide and they need to realize it and shape up.

silverlight

[wwmedia]

i know alot of people here hate microsoft (duh!)

but i believe silverlight will be a large part of the rich web

now this is my personal opinion and heres why:
*it was designed with web applications in mind (XAML) unlike the current html/css/javascript mess
*its more or less crossplatform
*it brings C# to the clients browser (see javascript mess above)
*has vector and hd video supprt of the box
*is designed to be easily updated

Re:HTML skills are a commodity?

[Frosty Piss]

Repeat after me: tables are not intended, nor suited, for layout.

What a particular tag was meant for when it was first implemented is entirely irrelevant as to if it can be effectively used to do something.

Re:HTML skills are a commodity?

[Bogtha]

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

Add an event handler to a normal <a> element with a proper href attribute. It works when JavaScript is switched off, it works when your event handler has an error, it works when you try to open something in a new tab or window, it works when the browser doesn't support whatever it is you are trying to do in your event handler, it just plain works.

DIVs are better than tables for layout.

No, they aren't. They are absolutely useless for layout.

They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.

You have confused the <div> element type with CSS. They are totally different things.

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.

Re:will AJAX development finally be easy?

[SharpFang]

It is not quite as easy.

Assuming you start from zero...

The beginnings are easy. Learn basics of HTML and CSS. A week and you're intermediate. You still don't know all the hacks and caveats but you know quite enough.

Learn basics of Javascript. Say, 3 days. Simple JS is easy. If you think all JS is easy, read some scripts by Douglas Crockford and see how wrong you were. But for a starter, you need simple JS.

Then learn using DOM. This isn't all that hard. There are some caveats like some browsers inserting whitespace text nodes between tags and such, but that's all doable. One evening to master it.

Learn some backend language. PHP probably. With some database too. Quite easy but the amount of knowledge you need to absorb is at least 2 weeks of learning.

Next you learn basics of using xmlHttpRequest. This is one evening and you know how it works and you know there's no sense using it as-is.

You spend the next afternoon picking an AJAX framework/library/toolbox and another day learning it.

They you spend another year writing AJAX and learning how to properly react to unreliable connections and handle all kinds of errors, corrupted data, browser incompatibilities, how to protect your apps from script injection attacks or exploiting your application server by someone "from outside", deal with load ballancing on the server side, sharing scripts between domains, making the code non-conflicting with other JS and self (2 instances of the same AJAX-based tool on one page? It's broken more often than you think!), creating javascript files dynamically using PHP to allow better flexiblity of your app, parsing, traversing, modifying and extracting data from style sheets, interacting with Flash, Java and APIs of a dozen external services, writing XUL based apps, optimizing data for transfer, porting large parts of business logic to JS to offload your application servers, then finally using the advanced javascript where modifying system methods and objects is not a taboo anymore.

Then you know AJAX.

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.

Then I recommend downloading and trying prototype. 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?

[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:HTML skills are a commodity?

[hobo sapiens]

Ah, the old divs vs tables flamewar.

I used to be on the side of using semantically neutral elements like divs and css to specify layout.

Most layouts work fine with semantically neutral elements (divs). Some don't. I have used tables for layout in one or two cases, but not before trying VERY hard to make a purely CSS driven solution. To approximate it using no tables, I'd have to put javascript in my CSS expressions to make IE simulate min-width and min-height, among other things. Since that's a clever but ultimately sucky solution, tables won out. We're talking very specific layouts here. Usually you shouldn't need tables.

I said it in another nearby post, but I'll say it again here: being a professional is knowing the rules. Another part of being a professional is knowing when to break them. Yes, using tables for layout is a semantic faux-pas. But sometimes it makes the most sense.

If you find yourself having to cobble together a collections of hacks to make a certain layout work without tables, then you either need to abandon the layout, or if you cannot, use tables. Semantically incorrect, but it's better than some of the hacks that you have to use to work around browser (IE) flakiness. I am not talking about wrapping floating divs in a container with negative margins. That's a pretty elegant solution. I am talking about several layers of nested divs with wacky CSS tricks and IE hacks on top of Javascript magic. That stuff is ridiculous. In short, use the best tool for the job and get over your prejudices about a certain design methodology being "bad".

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

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) Thus the birth of Javascript. Eich described the first revision as "having gotten out of the lab a bit earlier than intended". 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. 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 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 on that.

strong type checking

Strong typing 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

Re:Do you also welcome AJAX hosts holding your dat

[AKAImBatman]

Microsoft implemented Javascript with full DOM access at the time Netscape Navigator had rather limited and tedious Javascript support.

Correct. And what happened to Netscape's market share?

Now a bunch of folks came together and declared that Microsoft got it all wrong and has to re-implement its browser with 80% market share to conform to minority's opinion of how a web browser should behave.

I hardly think that a "minority" of the development community are the ones mad at Microsoft. Anyone who has used IE to any appreciable degree is mad at them. When 5.0 came out back in '99, it was incredible. The best browser, bar none. Microsoft released a fairly insignificant update called 6.0 in '01 and that was where the browser sat. For about 5 years. Then when everyone had almost given up hope that Microsoft would keep developing their browser, they announced 7.0. They also announced how they were going to meet W3C standards and make developer's lives better. 7.0 came out, and it turns out that Microsoft couldn't even be bothered to add support for simple things like DOM2 Events or SVG. (Things which they effectively already had support for, just in a proprietary-yet-not-quite-dislike manner.) In reality, they stamped out a few CSS bugs, screwed up the IE interface, then developed a new certificate scheme that was practically the same as the old one but made more money for all involved.

I say punish Microsoft for illegal use of its monopoly power, but otherwise let critics develop their own software and let the best program win.

The funny thing is, the only reason why IE hasn't died out is aforementioned monopoly power. I have met very few users who prefer IE over Firefox or Safari. However, I have met managers who force the use of IE (thus leaving themselves vulnerable to IE's massive security holes) for the purpose of 100% Microsoft "corporate standards". As a result, IE has lost market share in the home computer segment, but is not taking any losses in the B2B arena. And it's NOT because it's a good product.