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

Reduce the Quirks and Exceptions to HTML/CSS

[JoeCommodore]

Probably the biggest thing I see is that we live with a 'quirky' web where you write an HTML/CSS document and have to adjust for problems with one browser or another (or not support some because of such things), while the use of standard libraries and tools have provided automatic solutions for much of the quirks they still limit the possibilities.

HTML skills are a commodity?

[Bogtha]

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

It seems to me that developers that can write decent HTML are still an extreme minority. I still see href="javascript:", "<div> s are better than tables for layout", a chronic amount of invalid code, and all kinds of other idiocy all the time. Sure, if you want monkeys to throw tag soup all over the place it's not hard to find them, but that doesn't mean they know what they are doing or that it's easy to find people who actually understand HTML.

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

[Bogtha]

I strongly disagree that divs over tables for layout is idiocy.

It is idiocy because it shows a complete lack of understanding of the separation of content and presentation. <div> elements are content, not presentation.

Saying that <div> elements are for layout is exactly the same mistake as saying that tables are for layout. The consequences are less severe because the <div> element type has almost no associated semantics to pervert, but it's still the same mistake.

Re:HTML skills are a commodity?

[Bogtha]

For an AJAX project, the ability to work with javascript disabled is a moot point--thus invalidating your event handler argument.

Did you read past the first few words? I gave examples of opening links in a new tab or window. This is a problem for javascript: links regardless of whether Javascript is switched on or off.

In any case, why is the ability to work with JavaScript disabled a moot point just because Ajax is used? Just because you use Ajax, it doesn't mean that you need to give up on situations where JavaScript is disabled.

You seem to be completely unaware of the fact that clients pay for the way the page/app LOOKS

We're talking about how well a developer understands HTML, your tangent about what clients pay for is irrelevant to that.

Re:HTML skills are a commodity?

[Osty]

Yes, and what was the motivation for using elements? If it was because you have two separate components without a more appropriate element type to describe them, then that's a structural issue, not a layout issue. If it was because you are building a page with two columns, then you are screwing up and don't understand HTML. Either way, saying that "divs are better for layout" is not a sensible thing to say.

Now you're just being pedantic. Obviously it's the CSS that positions things in your layout, but when discussing table layouts versus CSS layouts, most people will call the latter "div layouts" just because it's easier to understand ("I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS"). If you're doing a layout that would traditionally require a table, you have several blocks of information that need to be positioned correctly. Those blocks usually don't have any semantic meaning other than "I'm a block", in which case divs are appropriate. I'm going to lay out my page using CSS regardless, so if not divs then what? Spans marked as display: block?

Re:HTML skills are a commodity?

[Bogtha]

Now you're just being pedantic.

No, it's not pedantry. This isn't merely a case of wrong terminology, it's a sign that a developer is looking at something in a completely upside-down way.

most people will call the latter "div layouts" just because it's easier to understand

"Div layouts" is not easier to understand than "CSS layouts".

"I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS"

If you tell people to replace layout tables with divs, then you don't understand HTML. You replace layout tables with the most appropriate element type available.

I'm going to lay out my page using CSS regardless, so if not divs then what?

I'm not telling you not to use divs. I'm telling you that you are confusing content and presentation. What element types you use is not a layout issue.

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

[elbobo]

Sounds to me like you don't know as much as you think you do about CSS then. Getting CSS layouts right isn't just a matter of knowing the appropriate CSS properties - it also requires considerable experience. But once you've got that experience you can do everything with CSS that can be done with tables, and much more, and with relative ease. If you're giving up and going back to tables, then you've got more to learn and more experience to gather.

Looking at your website I see you're using divs and spans in places where there are more appropriate semantic tags. It also looks as if you're using more nested block elements than should be necessary for that layout. I'd also suggest trying multiple CSS classes per element in some cases. An example (that will be entirely wrong because I haven't spent the time to learn how your layout is working): class="wrapper outer float-wrap center" instead of five separate divs with one class each. You're also often using classes that describe the CSS properties, rather than semantically describing the content. eg class="float-wrap" instead of class="newsitem" or some such.

I'm not trying to be condescending. I really like your design. I'm just saying that if you're ending up with the answer being tables then you need to acquire more skills so that you can better answer the question.

Let's see

[smittyoneeach]

In the beginning, there was client server.
Then, there was n-tier with the thin client.
Now, the client seems past the bout of anorexia, we've gone back to client/server, and AJAX has fattened it right up.
Next (mis)step? N-tier, repackaged as "federated", with an emphasis on thin, mobile clients. But you knew that. The real question is, what will AJAX for the hand-held be called? I say: BORAXO.
I will confess some guilt that this has not been reduced to a Burma Shave troll, but I'm still slightly under the weather.

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.

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.

Make a new protocol already!

[Anonymous Coward]

Toss out JS, and put python on both client and server.

Toss out HTML and make an XML based form layout language, with a *proper* rich widget set, and GTK-style splitter based layout mechanics.

Toss out the request-response paradigm and go with a proper connection.

In other words, make it a browser based application framework, because that's what people actually seem to want.

All this AJAX malarkey is just a *huge* kludge.

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

Re:When did AJAX stop sucking?

[secPM_MS]

The rich web is all well and good for those with nice screens and good vision. It does not do so well for those with highly constrained devices and/or bad vision. I would love it if companies pushing commerce web sites started having acessibility requirements.

If a user has bad vision, they can feed text into a text to speech converter. GUI into a speech converter doesn't work so well. There are an increasing number of older folks using the web, and expecting a large screen real state is not appropriate - they may have large screens, but they may have increased the font size for readability.

As for me, I am paranoid. I don't believe in running script unless I have a good reason to trust the site in question. Thus by default, I have Java, Javascript, Flash, ActiveX, et al off. Thus, no rich web for me. Too bad.

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.

Do you also welcome AJAX hosts holding your data?

[compumike]

Lots of people seem to welcome AJAX, and it does provide a huge step in the interactivity of web interfaces without sacrificing platform compatibility or development time.

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. A big reason is because Javascript can't touch your local filesystem, but another is that Javascript isn't powerful enough to really be useful for all of the processing, so back to the server-side scripting it goes.

In fact, one of the things that scared me today was how excited a friend was to discover that Google's chat application logged all of their Jabber conversations -- even if they had been made with a 3rd party GUI client (Pidgin). This, to me, would just be scary.

--
Educational microcontroller kits for the digital generation.

Re:will AJAX development finally be easy?

[Dragonslicer]

Doing simple AJAX stuff is easy. Drag/drop a few lists. Insert a new div into the page... Repeat after me: DHTML/DOM manipulation has NOTHING to do with XMLHttpRequest.

Re:AJAX vs. Flash is the real question

[LWATCDR]

Why?
Yes people that use flash for layout and menus are just as stupid as people that used Java buttons.
But Google doesn't need to read applications.

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:will AJAX development finally be easy?

[misleb]

True, but there's little point in doing XHR if you're not manipulating the DOM. They go hand in hand. Together they make up "AJAX" as is commonly implemented. While doing XHR and manipulating the DOM are, in and of themselves, not particularly difficult, making a a truely rich desktop-like application using them can be tricky. Especially considering the relative sparseness of HTML with regards to application control.

Re:When did AJAX stop sucking?

[hobo sapiens]

Well too bad for you.

Developing for the web is about knowing your audience. If I were designing a site like ebay or amazon, in other words, trying to have the widest possible user base, or if I were working for some entity that had to abide by ADA requirements, then maybe avoiding AJAX would be advisable. For a site that is not a necessity, like, for example, youtube, slashdot, digg, flickr, etc AJAX is great. When done properly, AJAX makes more efficient applications that enhance the user experience.

Also, if you really want to, you can develop sites that use AJAX but also degrade nicely. Everyone here (at least, anyone who calls himself a serious web developer) is using web standards and writing good semantic markup, right? Well, that will make your site at least accessible. If you just use the noscript tag to handle non javascript user agents (where necessary, obviously not where there isn't ROI anyway) then your site should work pretty well.

As someone else who replied to you mentioned, we cannot develop web sites around people who for some crazy reason refuse to use new technologies (if you call javascript new, as if!). That, along with MSIE, are holding the web back.

I think people who hate AJAX just hate it because of all the bad AJAX sites. But that's like hating the web because there are bad non-ajax sites. AJAX, like other technologies, makes things better when used properly.

Re:will AJAX development finally be easy?

[Just Some Guy]

porting large parts of business logic to JS to offload your application servers,

Whoa, hey, full stop. I was with you until then, but... You're really trusting your business logic to the least controlled (both in the "security" and "standardized" sense) part of the stack? Ouch. Good luck, man.

Re:silverlight

[ghempton]

What distinguishes silverlight from flash? Silverlight in its current state is not only less pervasive, but it is also very limited in features and capabilities.

Re:will AJAX development finally be easy?

[CandideEC]

You can skip of a lot of that crap if you just learn Java and use GWT. I mean *really*...is there any other option?

First as tragedy, then as farce

[Anonymous Coward]

You missed out

*Is designed to kill the cross-platform web

Like Active-X before it and Internet Explorer, Office, Exchange email, etc etc, what seems at first to be a useful tool will quickly turn to being a 'Works best on Windows" genuine advantage for the users involved - herding them onto a platform where everything requires a payment to Microsoft.

Re:Do you also welcome AJAX hosts holding your dat

[rmerry72]

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

I'd say users have been leading towards "don't care". Of course the solution is to host your own web/app server. Then your client talks to your server and stores your data.

Javascript and HTML are for content and presentation, not processing data. That's because browsers are optomised as display platforms, because they are built to display documents. Javascript is not a programming language its a script language to allow designers to customise your display, just like CSS.

Want a customisable, interactive, client-server GUI. Code one in a real language. Use C, C++, C# or even Java, then throw an XML over HTTP client comms library in. Easy. Well easy for programmers with a little training. Not easy for script monkeys who can't code. AJAX is just a bastardisation of what was easiest for most people to build with.

AJAX is to the Web what Lego is to the building industry. Useful in its place.

Re:Do you also welcome AJAX hosts holding your dat

[AKAImBatman]

No offense is intended, sir, but your comment reeks of inexperience. Javascript is far more capable than you give it credit for. And I say that as someone who's coded a variety of applications (including client/server) for well over a decade, in a variety of different languages. The number one problem I've found in Javascript critics? They have no idea how to actually code in the language. They don't understand that it's object oriented, they haven't given more than a cursory glance to the W3C specs, and they are blissfully unaware of where the WHATWG is taking HTML applications.

Want a customisable, interactive, client-server GUI. Code one in a real language. Like Javascript. If you know what you're doing, you'll actually find it a LOT easier than writing a comparable C, C++, C#, or Java GUI.

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.

AJAX still sucks

[Animats]

Reasons AJAX still sucks:

• The concurrency model is lame and buggy. Open Google Maps in Firefox 2. Roll the mouse wheel rapidly to zoom in and out. Watch the maps break up as the browser gets out of sync with the server and doesn't properly repair the window damage. It's like a window system from 1990 or so.
• Firewalls and AJAX still don't play well together. Rewriting JavaScript source in the firewall is not the answer.
• The conflicts between cross-site scripting, mashups, and security illustrate that Javascript's security model is inadequate.
• The JSON concept opens security holes. JavaScript has the wrong primitives. In LISP, there's the reader, which takes in a string and turns it into an S-expression, and there's "eval", which executes an S-expression. In JavaScript, there's only "eval", which takes a string and runs it. Oops. Not the right tool for marshalling.

JavaScript itself isn't that bad a language, though. It's the integration with browsers that's not good enough.

Re:Do you also welcome AJAX hosts holding your dat

[rmerry72]

Oh, and Javascript was NOT designed as a "display customization language". It was originally designed to script (drumroll please...) Java.

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.

Javascript is not an object oriented language. It is at best what can be called object-based, but then anything that uses "objects" can make that claim. There is no polymorphesm or inheritance, strong type checking, nor even much encapsulation. Its all function based monolithic code. And even if javascript, per se, is capable of the above, examples of such are very, very rare indeed.

As for the W3C specs, they aren't worth that much as most of the javascript interpretors - aka browsers - haven't given much more of a cursory glance at them either. No point writing code to spec if the interpretor won't run the code in the same way. At least Sun managed to force JVMs to be written to a more standard standard.

My brother builds model planes in his spare time. According to your Javascript defence guess he can call himself an "Aircraft Engineer" now. Everytime I see recruitment ads for "HTML / Javascript Programmer" I kack myself. Well, at least it leaves the real programming jobs for those of us that can.

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.