h3h.net

There’s nothing inherently wrong with the popularization of useful techniques in any field, but the process by which this takes place has profound implications for the overall comprehension of knowledge and the quality of the products produced in that field. The explosion of attention toward the web applications arena was inevitable and has produced numerous benefits throughout the web-based industry. The spark that ignited this explosion, however, lacked the structure and clarity necessary to bring the best possible benefits to the authors and integrators in the field. The spark in this case was almost undeniably the introduction of the term “Ajax”.

In the essay that defined the term, there is a description: “Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies.”

The problems that stem from the ambiguity of this “approach” or “way of thinking” are numerous. One of these problems comes from the fact that the “certain technologies” alluded to are not explicitly enumerated as criteria for a certain method fitting with the Ajax pattern. Further, the current idea of Ajax doesn’t contain any specific set of technologies; something that has been a central source of debate surrounding the buzzword. The result is that these problems translate directly into ambiguity when the term is used in a technical context.

For instance, if a product manager delivers a specification for a web application to a web developer with “Implement quote update mechanisms with Ajax”, the only thing the developer can safely infer is that the page shouldn’t reload. The important details about specific implementation are completely missing because the term has no specific technical meaning.

Another problem that is less obvious but probably more harmful is that the term makes the whole business of dynamic web applications seem like a huge, monolithic, insurmountable beast named Ajax which one has to use toolkits and libraries to wrestle and harness. The increased interest in the web application development field means that new developers will be trying to create new applications using existing technologies and methodologies, but if the field isn’t approachable or easily tackled, more developers will be turned off and we will all lose for not having another potentially useful web application. Unfortunately for everyone, all of the toolkits and most of the libraries available share large fundamental errors and misunderstandings about many of the technologies involved.

The two most prevalent issues with existing toolkits and libraries are lack of standardization and poor quality of code. The first problem is to be expected in any new field where competetive products emerge and are embraced to varying degrees, but in the end the developer suffers when the toolkit he or she used loses development support or popular support. There is a great amount of power to be derived from consistency in frameworks, especially those used to develop web applications that are maintained by a large team and over long periods of time.

The second and most troublesome problem found in toolkits and in the web application field in general is the poor quality of the JS code. The developers who set out to write toolkits and libraries are often the same developers who are trying to gain entry into the field and who are just learning JS. These developers most often lack experience and expertise with dynamic languages or JS specifically and end up writing poor quality code. Although the numbers are on the rise now that the web application field has been highlighted for over a year, the number of developers who have the neccessary experience and architectural knowledge to write high quality toolkits or libraries for mass consumption is still startlingly small.

In the end, of course, I have to propose an alternative to the term “Ajax” for technical contexts (saying nothing about marketing terms — they can use whatever flashy words they wish). I think it can be something just as verbally simple, but more descriptive, and something that doesn’t pretend to be anything that it isn’t: “asynch” (ay-sink) — short for asynchronous. This is usually what most of the hazy Ajax approaches are trying to describe anyway. As a fun exercise, try replacing every occurrence of “Ajax” with “trendy” in every “Web 2.0″ presentation or article you consume. The lack of change in meaning is just as funny as it is depressing.

Also, it’s “Ajax”, not “AJAX”.