Monday, March 12th, 2007

Current Concerns with Ajax

Category: Ajax, Editorial

Our fellow Ajaxian Michael Mahemoff, has written about his current concerns with Ajax.

His main concerns are:

  • Accessibility
  • Documentation: it is getting better for Prototype, Dojo, and the rest
  • Lack of good cross domain option: Are you jealous that Yahoo! can put in a crossdomain.xml in for Pipes and Flash API users can do what they want with it?
  • Cross-browser programming is still painful
  • Comet (HTTP Streaming) is becoming really important, but is still out of reach for the typical Ajax programmer. Too resource-intensive, too many issues to overcome, especially in the server.

Do you agree with these? Do you have other concerns?

Posted by Dion Almaer at 9:35 am
30 Comments

+++--
3.9 rating from 64 votes

30 Comments »

Comments feed TrackBack URI

First off, dojo is a bloated nightmare – I looked into using it and ran away. It’s too big, tries to do too much, too hard to build. Typical of ‘accepted enterprise development’ nowadays.

We are entering (already have) the days of the browser toolkits. When I say toolkits I mean widget kits, ui elements, etc – stuff that’s been around in operating systems for some time. These controls/components are approaching OS level of interaction and dare I say, functionality. Probably the two most mature kits I would recommend are:
GWT – *if* you have to program in Java
YUI/Ext – works quite well on all browsers (of a certain baseline, of course)

Comet/streaming is a big deal. Sorta. Ways around this are polling via an Observer; this is what they did over at Campfire. I would advise against these sorts of things for the time being unless you really need it. Most people won’t care.

Some people are doing Flash/Laszlo, which is technically Ajax minus the DHTML stuff. Personally, I prefer the DHTML Ajax route.

All in all, interesting times as a web developer I think.

Comment by Jason — March 12, 2007

Will cross-domain envy usher in more widespread support for JSON-P? I think that would be cool.

Comment by Kris Zyp — March 12, 2007

My major concern with Ajax based applications or applications that use tons of JavaScript is ERRORS. (Both clientside and serverside)

I have been on so many sites where I get an error and the page is hosed. If I am bored I will open up other browsers and see if it will work. (But is a Mom and Pop user going to do that or just leave and find it somewhere else?)

You can not do a single thing on it! I been on some where the request was getting a 404 error (spotted it with Firebug). Looked at the code and there was no “OnError” type of call and there was no check to make sure the response was correct. [check status and check the response!]

I have looked at others and they are using var myRequest = window.ActiveXObject ? new ActiveXObject(“Microsoft.XMLHTTP”) : new XMLHttpRequest(); That is just plain wrong in many levels and can cause a lot of errors! [try catch is our friend!]

We have people out there not realzing that proxy servers out there are caching our JS files and they may not have the newest and greatest. (AOL is famous for it!) I had an email service yelling at me once that I did not have the correct JavaScript version and I had to clear my cache. My cache was clear and it still yelled! No checking mail for me! [Append Version Numbers!!]

My last pet peeve about COMET/ or polling based calls which kills any notion of session timeouts and developers thinking it is still there!

Comment by Eric Pascarello — March 12, 2007

I don’t find cross browser development to be all that painful, but I’ve been writing funky UI scripts for a lot longer than most people have been interested in this stuff. It’s just a matter of knowing all the browser idiosyncrasies and compensating for them.

But, I’m not a big fan of the many bloated frameworks and libraries that people have grown so fond of either, and prefer to roll my own, which is probably. When you roll your own, you are more intimately familiar with what is going on in your code, and the various browsers that will be running it–the more you do that, the less browser quirks will trouble you.

Comment by JoeBoy — March 12, 2007

Hi,

Are you not concerned about:
1. Standards – a standard way of doing a certain thing
2. Serviceability – I have seen AJAX (Javascript) code written in a way that it is very cryptic to understand. Wouldn’t that cause long term problems in serviceability?
3. Cross browser support – this is usually a hell, when programming in AJAX/Javascript.

Thanks,
Mukul.

Comment by Mukul Kumar — March 12, 2007

I’m working on point four.. I’ll let you know when I can share :)

Comment by Caleb Buxton — March 12, 2007

Using XIN, cross browser ajax programming is two attributes, and that’s that.
– Not exactly hard.
http://www.xindesk.com/blog

Comment by mikael bergkvist — March 12, 2007

What is wrong with:
var myRequest = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject(”Microsoft.XMLHTTP”);
I loathe try/catch. Anytime I visit a page using prototype and I have firebug turned on (with stopping on errors), which I always do, I get firebug popping up. I always visit Ajaxian with IE consequently, FF/FB + PT (try/catch Ajax) is just too annoying. But, I am curious what is wrong with above code.

Comment by Kris Zyp — March 12, 2007

What is wrong with:
var myRequest = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject(”Microsoft.XMLHTTP”);

Go into IE7 and start disabling “Allow Native XML Support” (advance tab under scripting – not positive that is the exact wording) and disable ActiveX.

I talk about the ActiveX error here: http://radio.javaranch.com/pascarello/2006/02/07/1139345471027.html

Eric

Comment by Eric Pascarello — March 12, 2007

@Jason: “bloated nightmare”? It actually isn’t, but because there’s so much you can *use* (note the word “can” as opposed to “have to”) it seems that way. We’re in the process of splitting it up into 3 projects to help with the perception of bloat, but the reality is that the only things that are loaded with Dojo are the package system (dojo.require); everything else is optional. How does that make it bloated?
@michael: what would you want to see Dojo do better than it does now, and how?

Comment by Tom Trenka — March 12, 2007

Hey Tom,

I use dojo. It is pretty good in my opinion. I also have written custom frameworks when clients request it.

I wouldn’t say that dojo is “bloated” or a “nightmare”. However, despite the great packaging system, it does make the js download 2-3 times bigger than custom-tailored code. The main reason is because dojo is general-purpose: you have to build it to work in both quirks mode and strict mode, for both css-driven tables and html attribute-driven tables (just using tables for instance), etc. this is true of ALL frameworks, not just dojo.

With custom-tailored code, you can eliminate about half of the code since you control the environment, too. For instance, my clients usually choose to support browsers from Safari 2.0, IE 6.0 and FF 1.5. I also recommend strict mode whenever possible. I am also obsessed with code optimization (size and speed), which dojo could use a bit more of — at least until JIT compiling arrives in FF 3.0 :-) — so my code is usually very compact.

Still, working with dojo cuts out at least half of the coding and testing time. For the most part, dojo libraries “work as advertised”. Most of my clients don’t mind a slightly slower download if it means saving many thousands of dollars in development time.

And that is what reusable frameworks are all about: saving time and money (and eliminating frustration for newbies as well).

Comment by John Hann — March 12, 2007

Some notes on some points of the ongoing discussion

By default dojo is a bit too fat, but it can be trimmed down. Nevertheless having to load all those separate files from the server is a PITA. I’d rather download a single big file than dozens of them. I’m currently developing an Ajax project. I started with dojo and made heavy use of many form widgets but I run in troubles expecially with (guess what) IE6 (performances). I switched back to plain browser widgets quite soon and I keep using Dojo only for the layout widgets, the wonderful topics system, the tooltips and the toaster widgets.

Comet is not so difficult and not so out of range. Just try Jetty 6.1 and play with the chat demo servlet. Using continuations to serve thousands of concurrent requests is pretty easy.

Documentation: unfortunately in most cases the best documentation is still the source code. In the case of most Dojo’s widgets, the best documentation is the nightly tests site.

Comment by Paolo M. — March 12, 2007

@Tom

Documentation

Dojo’s great i’m doing an app in it right now – but the documentation is really really bad. Like horribly awful bad.

i think that’s where part of the bloat perception comes from, because there’s all this undocumented ‘stuff’ which nobody know what it does, therefore they just think it’s garbage.

Comment by Steve Boyd — March 12, 2007

@John: I don’t disagree with you, and I tend to do the same.
@Paolo: that’s the point of the Dojo Build System; you might want to take a look at it and try it.
@Steve: Have you tried the API tool at all? http://dojotoolkit.org/api/
It’s still a little raw and it doesn’t lend itself to printing but it’s about as complete as it will get for a while…

Comment by Tom Trenka — March 12, 2007

“Cross-browser programming may still painful”.

After a quick check I noticed that you have 52 errors on this page that make your HTML not validate. Wow. Well, first thing first, you can start coding with Standards.

Comment by Michael — March 12, 2007

yeah ive been using the api, but it what it lacks is simple examples of how to use things. e.g. http://dojotoolkit.org/ -> “see it in action” -> “source” is fantastic. copy n paste then modify is probaly the easiest way to learn.

yesterday while coding i got stuck using ajax and recieving xml from a server. after alot of googling i ended up getting my answer from here
http://dojotoolkit.org/pipermail/dojo-interest/2006-January/002684.html
which is a pretty random place to find the code i wanted:
dojo.dom.createDocumentFromText(response).documentElement

side note: im not using the parse() method cos it produces a weird object type, am using a 3rd party XPath script since i think it’s really important to stick to accepted web standards

Comment by Steve Boyd — March 12, 2007

Mootools, fast, light-weight, cross-browser, feature rich.

I think frameworks that are 3-5 mb large are overkill and are probably a good indication that you are trying to do too much and not being efficient.

Comment by Alex K. — March 13, 2007

You simply should try FdAjax module + lighttpd. It has much simpler architecture than Comet.

Comment by Grzegorz Daniluk — March 13, 2007

@steve: Yeah, we know. We’re in the process of redoing the Dojo website and adding forums to it, so that we can kill the mailing lists. Hopefully it’ll be better in terms of searching for solutions and what not.

Comment by Tom Trenka — March 13, 2007

The problem in my opinion with all AJAX libraries is that they don’t relay on anything familiar, so with each one of them you have to learn all from scratch. This is way Visual WebGui (Extending ASP.NET with WinForms capabilities over AJAX) in my opinion took a right turn by exposing more of the same while innovating under the hood but you have a standard API.

It is a framework for a applications rather then sites but I think that other frameworks will do good by following the concept of adapting familiar API’s.

Another issue that I think is neglected is the huge footprint we are starting to have using the different frameworks. That is also in my opinion because we have abandoned the server leaving all the work for the client which is inferior and thus requires lots of learning in terms of huge kernel scripts. We should either start enhancing browsers or start rethinking the amount of tasks we are throwing on him…

Comment by Guy Peled — March 13, 2007

There is a good alternative for cross-domain AJAX. You can use Dynamic Script Attachment. By attaching scripts dynamically to the page you can gain cross-domain access with a technique which works in a wide variety of browsers and operating systems.

For more information see my website:
http://www.tomorrownext.com/hermes/

Comment by Mike — March 13, 2007

Eventhough it is convenient the way that Prototype extends base objects. I have found it to be pretty dangerous because other script includes may try to extend the same base objects an thus overwrite what another script may have done. I have had problems using prototype in conjuction with UI components from ComponentArt for this very reason.

Comment by f baldoni — March 14, 2007

For the record, my original comment on Dojo was about one thing (as with Prototype): great library, *desperately needs decent documentation*.

Comment by Michael Mahemoff — March 14, 2007

One big issue with AJAX in general is Javascript. Not just the language and lack of good development tools, a user can turn it off or use a browser that doesn’t support it. You either have to write your entire system twice, make an assumption that JS is available, or not use it at all.

One issue with most AJAX frameworks is they try to do everything from client (widgets, etc.) to server (imposing demands on your server-side code) and don’t interact well with each other or even standard HTML. For example, there are several auto-suggest components for interfacing Script.aculo.us with DWR.

Comment by Myron — March 21, 2007

I don´t have problems with cross-browser programming any more. No joke just try the link. ;-)
BTW it is full AJAX so pls no jokes like “it doesn´t work with JS turned off”

(sry for the trashy hp linked there, as you can imagine I was occupied with other tasks – impressum on hp leads to contact data – I´ll replace it asap with a new one including documentation and download area).

Comment by Frank Thuerigen — April 1, 2007

Oh sry link – just click on my Name it leads to the prototype page for my system.

Comment by Frank Thuerigen — April 1, 2007

I’ve been reading and learning a lot about AJAX from kind people like you all for almost 6 months now. And I have just finished my first AJAX web page (still under my own testing!) and solved most of the problems using code snippets from here and there, just to face a “killer problem” nobody have discussed until now (to my knowledge):

. The requestFile is a script to deliver data.
. Anybody can access this script and steal my data.

I have searched and read a lot trying to find a way to prevent this, but to no avail. With FireFox + extensions or server to server scripts, no one can stop this.

Please, correct me if I am wrong!

Comment by Adeeb Rantawi — April 12, 2007

A few weeks ago I was trying to get moo tools going. Read their lacking docs and even went as far as to view source and rip an example apart.
Now I am not a JS wizard but I can code it. Well I posted on their forum after reading the forum requirements..
Well the forum mod basically put my post to rest and told me to read the documentation because I guess I did not read it..
Well I ended up getting banned because of my constructive comments..
This is the worst one yet.
Crappy documentation..
Basically a protoype-scriptactulus ripoff I think.. Like what is unique about it. Anything that unique that is needed is easier to code yourself..
I think the developers of this should let some of the air out of their heads..
Shitty product

Comment by chris — April 26, 2007

Page views, etc.? In terms of advertising….

Comment by jobrien — May 2, 2007

I don’t agree with the crossbrowser concern. You can pull a library off the shelf or write your own AJAX library (in under 2 hours) that addresses cross browser compatibilty. After that you are off to the races and never, almost, have to worry about it again.

Comment by Justin — May 3, 2007

Leave a comment

You must be logged in to post a comment.