Richard Hemmer's Bookmarks tagged webservices →  View Popular

What Every Software Project Needs to Know About Ajax

1.  The Browser Was Never Meant For Ajax.  About a week into your first Ajax serious application you'll discover that Ajax pushes the browser nearly beyond its limits and there are definite lower engineering tolerances to get used to. The fact is, without powerful 3rd party development tools, designing clean Javascript software of any size requires some genuine discipline and effort.  So too does Ajax debugging applications in multiple browsers (a real headache), and doing any serious background processing or threading can require heroic measures, particularly if you're mixing in other components that use the rather limited number of simultaneous timers available.  The good news: Simple Ajax -- sprinkling in a little DHTML -- is much less daunting than Ajax In The Large.  But be warned and be prepared to scale up your level of development and testing effort significantly with each doubling or trebling of your application size.
2. You Won't Need As Many Web Services As You Think.  I used to think that going the Ajax route required the development of a bunch of new Web services in order to feed the application data and provide a backing store.  In reality, I'm finding a great many projects are quite happy to scrape HTML and/or use plain old HTTP POSTs to existing service endpoints that have no formal Web service structure.  This is further turning the tide towards Ajax by making it very, very easy to "dip your toe" into Ajax development and reuse almost any preexisting HTTP service on the back end instead of SOAP or REST/WOA.  While this can encourage poor architectural choices, it does make very incremental conversion to Ajax almost effortless and turns out to be a natural thing to do, though it can certainly lead to headaches later.
3. Ajax Is More Involved Than Traditional Web Design and Development.  The loss of HTML user interface conventions, the almost limitless potential for hidden or latent functionality, the programmatic creation of page elements instead of declarative, and other intrinsic aspects of the Ajax approach throw out much of what we know about Web design and development.  Web designers must much more deeply understand the capabilities of the DOM, Javascript, CSS, and how the browser renders graphics, layouts, and elements.  Developers find testing both difficult and tedious.  Though tooling is continuing to improve across the board, it will take years for the industry to develop best practices, lore, patterns, and shared knowledge to make Web application development straightforward.  Huge kudos to folks like Yahoo!'s Bill Scott for trying to fix many of these problems -- particularly the loss of GUI standards -- by actually moving the state of the art considerably forward with things like the Yahoo! UI Design Patterns library.  The bottom line: Ajax development, at least for now, usually takes quite a bit longer than traditional Web development and requires a higher level of skill.
4. Ajax Tooling and Components Are Still Emerging and There Is No Clear Leader Today.  Though Dojo is getting one heck of a running start, the race is very far from over.  For instance, the Dojo framework itself is still just at version 0.3.  And close at its heels are an amazing range of tools, frameworks, and component libraries.  Though OpenAjax will make this mosaic of products play nicer, most developers will get deep experience with two or three of them and stick with them. For now, I would say deeply committing to a particular product is usually not the best idea.  Innovation, competition, and market leadership is likely going to bounce around for a while.  In the meantime, be sure to check out script.aculo.us, Prototype, Google Web Toolkit, Yahoo! UI Library, JackBe, Zapatec, Bindows, Nexaweb, General Interface, Backbase, ActiveWidgets, and last but not least http://atlas.asp.net/default.aspx?tabid=4