Tuesday, July 12th, 2005

“Ajax is rocket science”. “Ajax isn’t simple”. Enough already!

Category: Editorial

Infoworld wrote their piece on Ajax a little bit ago.

One area of the article goes into how hard Ajax is:

Ajax isn’t simple. It can include more than two Web languages plus other code, including JavaScript, Dynamic HTML, and a Microsoft-created routine called XMLHttpRequest. Since Ajax apps are cobbled together from freely available technologies, they take longer to develop than software written in commercial development environments. But the development style also obviates the need for heavy-duty programming languages such as Sun Microsystems’ Java or multimedia-creating servers and tools like Macromedia’s Flash. Since Ajax’s basic technologies are available and run in unmodified browsers, an explosion of Ajax apps could weaken demand for those companies’ products.

This has come out in various news pieces, and from various software vendors.

Now, I don’t think that Ajax is “simple”, and we are still innovating and getting better frameworks, and ajaxian components built-in.

However, even in its current iteration, Ajax is far from “hard” if you compare it to rich client technology.

“hard” and “easy” are tough items at best, and are HIGHLY relative. A straight, simple, HTML page is obviously simpler than putting in JavaScript and Ajax, but this isn’t the total picture.

Google Maps

Ben and I often tell people that the hardcode work behind Google Maps isn’t the UI (beautiful and creative as it is). I would much rather write the Ajaxian GUI compared to the really tough GIS issues!

To proove this to ourselves, we say down before our JavaOne talk and whipped together a version of Google Maps from scratch, and it took 2 hours. Now, in 2 hours we didn’t get it as polished as Google, but we had a nice workable solution.

Comparison to Swing, .NET WinForms, …

I know I would be able to whip up an Ajaxian application than a rich client in Swing, or even WinForms. So for me, Ajax is simple compared to that work… and Ajax is partly about rich clients! It is also about small things, such as ajaxian server validation.

Posted by Dion Almaer at 7:00 pm
8 Comments

+++--
3.1 rating from 7 votes

8 Comments »

Comments feed

I guess you just don’t have all that much experience with the right tools to build rich client apps. It’s a hell of a lot easier to build a Cocoa app than a web app, ajaxian or otherwise. And you can even debug it reasonably, and don’t really have to worry about bugs or misfeatures in the underlying implementation of the stuff you’re using. How novel! That’s just a single platform, which may be not be an option depending on your app.

Web apps are certainly preferable if distribution or updating is an issue, but I still say it’s easier to write a cross-platform rich app (with the right tools, anyway) than it is to write a cross-browser web app. The non-browser platform, tools and frameworks are much more mature and robust. It might be easier to *start* writing a web app, but you’ll probably finish first with a client-side app.

Comment by Bob Ippolito — July 12, 2005

Here’s the thing that most ‘good’ developers (smart and/or educated) take for granted.

There are lots of people out there who are barely qualified to do web design OR web programming, yet do so.

For example, a client of mine has a website / web application that’s written in coldfusion, and it’s got a ton of *really bad* code. I mean REALLY bad. The developer had NO idea what ‘normalization’ is, could barely use a join, and basically, he just used the most rudimentary of coldfusion tags to get the job done. (Think lots of if/else instead of while loops)

The client has zero programmers on staff, but some know HTML.

There’s not ANYONE in this type of office who’s going to know how to do coldfusion (or any type of server-side scripting language, for that matter).

So in this case, and i’m sure many others, the people involved (besides me, of course) aren’t going to be able to do Ajax anytime soon — because it’s a new concept and it requires multiple skills. (You have to be able to do some web design AND some programming)

I know we think of those skils as going together, but the fact is, there are a lot of people out there coding and doing websites who have no business doing so.

And, for them, Ajax is hard.

Comment by Matt — July 13, 2005

Ajax isn’t rocket science, however the total picture is.

People classify every application or website using Javascript with Ajax, and the awareness about what Ajax really is, isn’t really high.

What makes it difficult is not the xmlHttpRequest part, it is the markup / css / javascript / browsers / differences & hacks / architecture knowledge you only get if you worked with it alot, and even then there aren’t many developers with sufficient knowledge about architecture and web programming at the same time.

That makes it rocket science. Everybody can make a javascript ticker in the evening hours, but not everybody can whip up a complete GUI leveraging the full principles of Ajax, reusing the objects.

There are many people writing about it, but there are only few really being able to use it.

Comment by M. Schopman — July 13, 2005

Ajax is in it’s infancy. The tool support will come.

Writing Ajax right now can be a bit like writing a java app in which you need to develop and maintain your own lightweight component set, let alone write the UI without a GUI builder – frameworks like qooxdoo, rico, prototype, atlas, ‘x’, etc. etc. can do a lot of the hard ‘plumbing’ work for you, and make it easier to concentrate on the business parts of your app.

Matt’s point about the level of the average developer is a good one. Those of us lucky enough to work with talented colleagues often forget this. Compared to knocking up a few static HTML pages in front page or dreamweaver, ajax _is_ rocket science, but so is web start, swing, eclipse RPC or whatever else.

Comment by Dave Crane — July 13, 2005

So what if AJAX is hard at this point? I’m actually glad that it is somewhat esoteric compared to some of the other technologies right now. This actually prevents every Joe Blow out there from overusing it as we have seen so many of the easy-to-use technologies have become more and more accessible.

Right now, the point is for the best developers, those on the bleeding edge, to show what this platform can really do. If everyone could use it, say if it was built in as widgets to Dreamweaver or FrontPage, then we would see a glut of “Ajaxified” pages that have no right or reason to use the tech in the first place.

The tools, and the Tools that will overuse it, will come in time…

Comment by John Vilsack — July 13, 2005

I think that those of us wishing to promote AJAX application development do ourselves a disservice by trying to tell the world that “it’s not really that hard: look at what I can do!” when it really _is_ quite difficult to get started, even for an experienced developer. I receive questions fairly often from people asking me where “to get started”. And that’s the rub — that there is currently no clear place to start, no accepted set of practices, no consistent set of documentation, and so forth.

That does not impugn the idea as a whole — it simply describes the state that most “new” technologies find themselves in. The most important task for its advocates is to find ways to make the technology simpler and more effective. We need tools, libraries, and “best practices” that we can point new developers toward. These things are all in their nascent stages at this point, but will undoubtedly get much better over time.

On a side note, I also want to point out that Swing, WinForms, and the like are really not hard to use once you spend a few days with them. Rather than claiming that they are not easy to use, we should learn from their mistakes and aim to achieve a similar level of _consistency_ in AJAX libraries.

Comment by Joel Webber — July 13, 2005

Joel, I agree with you. The point is, you need to tell the company that it isn’t really that hard, or else they don’t even want to take the risk of using it.

Mostly, even when a company already has an experienced developer for rich DHTML application, the entire job depends on the shoulders of that single person. This creates a serious risk for doing such projects. Although every experienced web developer would love building such applications they only cause more risk, more stress, and alot of unhappiness with your colleages because they don’t know shit about it while you do.

Acceptance is one of the mayor things before it really starts to grow.

Comment by M. Schopman — July 13, 2005

I would say the greater point of describing the difficulty in developing JavaScript apps is the tortorous, perverse hackery that is sometimes required to get what appear to be very simple things to do. For years, web developers have been coming up with some of the most ingenious, creative, innovative workarounds to very frustrating limitations and bugs. Combine with with a very disparate technology set that is littered with many thousands of bugs and esoteric details, and you have something that is very difficult to do.

My response to the comment that this stuff isn’t rocket science is “No, you’re right, rocket science is sane. At least it follows the laws of physics, rather than the whims of user agents.”

Comment by Dylan Schiemann — July 15, 2005

Leave a comment

You must be logged in to post a comment.