Ajax: A New Approach to Web Applications

By robert castelo on 23 Feb 2005 at 12:32 UTC

There's a well written summary of the direction web applications are taking these days mixing technologies/layers:

http://adaptivepath.com/publications/essays/archives/000385.php

"The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities."

It's worth reading the article as background to what may emerge from the User Interface meeting that Drupal developers will be having this week.

Comments

Very interesting read..

javanaut commented 23 February 2005 at 14:51

Not much new for me in terms of technologies, but rather what clients now support. Historically, JS was seen as a double-edged sword that you couldn't rely on for a user interface. For efficiency purposes, any duplication work was avoided in favor of the more robust (though perhaps more clunky) server-side approach. Any site that you went to that required JS to be enabled was scorned and often avoided for not accommodating non-JS browsers (before that, it was about cookies being required).

I suppose the average browser has advanced enough to have JS comfortably enabled by default and we can start to comfortably turn people away who don't have it enabled? This is what we often do for non-cookie browsers. Is the non-JS browser next?

or

tvst commented 11 March 2005 at 04:18

*or* you can just make sure your page degrades gracefully for non-js browsers.

but, yes, i wish drupal was more ajaxy :)

agreed..

javanaut commented 11 March 2005 at 05:20

I just finished a site feature (for a non-drupal, unprofessional site) that completely relies on JS to function. The best I could do (which I haven't done yet) is put up a notice that JS wasn't enabled and for them to go away until they were ready to comply :P

That said, there are many UI goodies that would be great accessories to current web applications. Even simple things like context-sensitive form field suggestions (like Google answers, of course). I'm no UI expert, so I'll shuddup now.

i know what horse i'm betting on

harry slaughter

Omaha NE USA

commented 14 August 2005 at 05:47

you hit it, the main barrier for widespread adoption of javascript in general (and of course ajax) is that it has not been considered (by smart people anyway) something the web developer could assume was available client-side. at first it was an issue of browser support. then it became more an issue standardized javascript support among browsers. now i'm not quite sure what the resistance is. there will always be that hard core "lynx" type crowd that doesn't believe in the modern browser. but there a pretty small minority.

today, how can web developers be expected to program modern web applications based on the assumption that everyone's using a 1990s era web browser? but that's still the "safe" assumption a lot of folks make.

it's going to take more folks like google saying, hey, if you want to view today's web, you need today's browser. it's not like we're talking MicroShaft trying to screw web users by implementing non-standard protocols. javascript is pretty widely adopted and functional. it's the horse i'll bet on for client side web programming :) java, flash, whatever, are still years from being where javascript is today in terms of being supported by the browsers that are out on the web.

(vision for you: imagine drupal making ajax available to webmasters everywhere via a (hypothetical) module that somehow dummified ajax programming. suddenly all the coolest sites are running on drupal ;).

--
Devbee - http://devbee.net/

About 10% without javascript

Thox commented 16 August 2005 at 18:08

Looking at various statistic gathering websites (tracking many sites), the percentage of users without javascript varies from about 9-15%. That's quite a big number of users that won't see the extra features that javascript might be giving.

e.g. thecounter.com

high level

moshe weitzman commented 11 March 2005 at 13:37

a fine high level overview of this new breed of user interfaces. its greatest contribution is sure to be the abbreviation 'Ajax'. It is perfect.

For technical details about GMail and Google Maps, see these two articles respectively. they are linked from the Ajax article.

Apple Dev Article

robert castelo commented 11 March 2005 at 18:19

A bit more reading matterial here as well:

Dynamic HTML and XML: The XMLHttpRequest Object

[MegaGrunt]

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

oops

harry slaughter

Omaha NE USA

commented 14 August 2005 at 05:53

i misread a post and am "deleting" my comment :)

--
Devbee - http://devbee.net/

Wouldn't mind...

carl ditzler commented 11 March 2005 at 14:11

seeing an XMLHttpRequest approach for category/vocabulary selection when posting an article.

Excellent Idea

javanaut commented 11 March 2005 at 14:16

I've always wondered what happens on sites with a huge taxonomy and what the select field would look like with 2000 terms in it :) This would be a good solution to the huge taxonomy problem.

I'm working on this

factoryjoe commented 10 April 2005 at 00:21

I've got drag n'drop category sorting just about done and I'm working on in-line editing of category terms.

I should have a demo later this week. :)

Chris

Awesome

Gunny-1 commented 18 April 2005 at 00:54

Looking forward for your demo

can u please guide me the

priya-1 commented 15 June 2005 at 09:07

can u please guide me the way to use ajax in drag and drop without using .php files

Ajax Toolkits

fubar commented 23 July 2005 at 17:07

Ajax is being used as a catch-all term for both Javascript/DHTML/CSS widgets as well as XMLHTTPRequest to talk to the server (which would require some sort of back-end support). You don't really need PHP to do DnD. If it's just the front-end you're looking for, check out http://www.walterzorn.com/dragdrop/dragdrop_e.htm

For a full-featured Ajax toolkit with lots of Widgets, might want to also look at OpenRico (http://openrico.org/) or Backbase (http://www.backbase.com).

Update after code sprint

Steven commented 11 March 2005 at 16:13

Ajax was discussed at the usability meetings on the developer sprint, and we will definitely be implementing it in Drupal. But it has to be clean and degradabe.

--
If you have a problem, please search before posting a question.

General Framework

javanaut commented 11 March 2005 at 18:27

Would it make sense to develop a general framework or set of libraries to facilitate this? I could see many applications for this type of interaction, with much overlap in code.

Check out Sajax

travischristopher commented 24 March 2005 at 22:20

There’s a serious buzz going on with XMLHTTPRequest since JJG coined the term AJAX 4 weeks ago. Its great to know that Drupal development is already heading that direction. Check out the Simple AJAX toolkit.

http://www.modernmethod.com/sajax/index.phtml

also here' s an impressive link dump of xmlhttprequest bits

http://www.fiftyfoureleven.com/resources/programming/xmlhttprequest

Search engines

alex2005 commented 8 April 2005 at 22:36

Everything is good, but Ajax sites content is invisible to search engines.
How to deal with it?

Degrading

Steven commented 8 April 2005 at 22:50

Any Ajax usage in Drupal will degrade to a non-JS version for old browsers and people without JS turned on. This is what search engines will see.

--
If you have a problem, please search before posting a question.

Yes, non-JS version of

alex2005 commented 10 April 2005 at 13:29

Yes, non-JS version of content if neccessary.

How do you plan to implement Ajax in Drupal?

I guess that all noduless will need to provide content in XML
and themes will be mostly client-side.

Testing for javascript

factoryjoe commented 18 April 2005 at 17:42

It seems to me that Drupal needs a JS utility scripts file. One of its functions could detect whether certain JS features are supported in the browser and then output AJAXy features where supported.

I imagine that this would also require heavy use of the <noscript> tag, which makes a lot of sense to me.

One of the first AJAX projects that I'm working on is a Quicktags-style editor that leverages Drupal's built-in input filters to do real-time previews. I don't know if this will work for PHP, but it will work for HTML and Textile. I imagine that I would need to test to see if the browser supports AJAX and then if so, hook up the necessary piping to send the user input back to Drupal. If JS is off or XMLHttpRequest is not supported, then you simply have to use the standard Preview roundtrip.

Note that the purpose of this project is not to cut down on server load but rather to make editing and creating content more immediate, enjoyable and efficient.

Chris

Prototype.js

osmif commented 18 April 2005 at 20:26

Don't know what the license is on this, but Rails (Ruby framework) includes just such a file, called prototype.js

See: http://dev.rubyonrails.com/file/trunk/actionpack/lib/action_view/helpers...

Cheers.

Prototype.js has an "MIT-style license"

Geary commented 9 May 2005 at 17:10

Here's the home page for Prototype.js:

http://prototype.conio.net/

I think we should only offer

killes@www.drop.org commented 18 April 2005 at 21:38

I think we should only offer JS to browsers that are known to be fully compliant to whatever standard JS follows.
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

SAJAX

carl ditzler commented 18 April 2005 at 23:35

SAJAX?

Exactly!!!

haisam commented 8 December 2005 at 17:46

Exactly!!! So perhaps it's a step backwards with respect to searchability.

Interesting use of AJAX tech

javanaut commented 10 April 2005 at 00:02

I just thought this thread might be interested in yet another use of AJAX technology:

http://www.livejournal.com/community/lj_dev/680115.html

Livejournal is working on an AJAX interface for managing comments.

gmail-style attachment module

tvst commented 21 April 2005 at 19:17

i feel like some of you may like this

Article on Ajax and PHP

kbahey commented 27 April 2005 at 23:58

Slashdot has this article on Ajax and PHP with some interesting links. Some of it could be relevant to Drupal.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

My favourite bookmarks

anders.fajerson commented 1 May 2005 at 15:37

Unobtrusive Javascript -A must read. Maybe the techniques proposed here even satisfies killes??? :)
Tabtastic -Unobtrusive tabs
Edit in place and Drag & Drop Sortable Lists with JavaScript and CSS -Ultra cool interfaces

and finally some "AJAX":
JSPAN -tools to “hook up” PHP and Javascript.

I just want to point out

killes@www.drop.org commented 9 May 2005 at 13:51

I just want to point out that although I am known as a anti-JS zealot, I've been committing some JS code to the event module. I dodn't write it (aaron did) but I've been told it would be unobtrusive.
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

I'm with you

anders.fajerson commented 9 May 2005 at 16:53

Great to here! And I was of course joking, but you know that ;)

And I’m totally with you that javacript and AJAX implemententation in Drupal should be unobtrusive and build upon the principles of progressive enhancement.

Autocomplete

Thox commented 9 May 2005 at 12:34

I use AJAX-based autocomplete for the ingredient names on my recipe module. If I type "sugar, then it suggests things such as "caster sugar", "soft brown sugar", etc.

Here's a screenshot: (near the bottom)
http://brandedthoughts.co.uk/images/screenshots/recipe/recipe-edit-and-p...

My module has to call in all the JavaScript itself. It would be handy if Drupal had some built-in AJAX code that developers could make use of.

I am concerned..

adrian commented 9 May 2005 at 15:15

About contributed modules implementing this on their own steam.

What happens if several different modules have their own ajax implementations for just one or two fields? Boris asked me to add an ajax field to something, and I refused because of the problems that could arise.

Why not drupalize your code that you use to do this, and create an extra 'ajax.module', with a form_autocomplete function that is written similarly to the form_textfield() function in common.inc.

This would mean any other modules that wanted to do that could use your autocomplete api function, and it also means we are one step closer to adding
that function to core.

--
The future is so Bryght, I have to wear shades.

actually this was agreed upon, on the HIG meeting

Bèr Kessels commented 9 May 2005 at 15:21

We there agreed that (i) there will be some autocomplete api function, and (ii) we will make *core apis* for ajax and some other javascript.

Therefore, please look around on drupal, ask on the ML or in the developer channel on IRC. and help us get this in core, instead of implementing yet another javascript thing that is not opimal.

[Bèr Kessels | Drupal services www.webschuur.com]

Is the new Yahoo News Beta employed ajax approach?

ica commented 9 May 2005 at 14:49

I am not totaly conversant with the tech side you guys talking about but New Yahoo News Beta seems to function similar to the way Gmail functions (even a better example of rollover, Unobtrusive Javascript rollover and tabs, CSS, JSPAN stuff you referred above.

http://beta.news.yahoo.com/

The way it works is very interesting technical and user interface point of view. I wonder what technologies they use above exactly and possibilty to implement those for Drupal.

regards

http://www.ajaxmatters.com

also this one
http://openrico.org/rico/
demos etc.
http://openrico.org/rico/demos.page