Best Practices for AJAX development

It’s great to see developers starting to think seriously about what kind of best practices to use in javascript development. Developing with a loosy-goosy scripting language like JavaScript or ActionScript requires MORE code discipline, not less. Since the language doesn’t force you use best practices, you have to force yourself. Otherwise, someone will be stuck maintaining cruddy old code that nobody quite understands anymore. I’ve been there, and it’s no fun. Here are the highlights:

Seperate behavior from presentation: agreed. .js files are a good thing. It makes the code easier to read and debug, it lets designers and developer work on different files, and it leaves open the chance to compile your javascript ahead of time and make sure it’s at least syntactically valid (anybody doing that, by the way?).
Provide Progressive Enhancement: Basically he’s saying don’t rely on javascript, make sure you degrade gracefully. This is certainly a best practice, but it sure makes for a lot of extra work. For a corporate app or a break-through app (google maps, etc) I’m inclined to punt on this one. YMMV.

Alter the content as little as possible:
This is another good one. If you’re altering the html, preferably you should just change an ID or a class. The more you change, the more chance of mucking things up!
Document output, parameters, and dependencies Basically, comment your code. And build APIs that solve specific problems, rather than multi-purpose APIs that require a potential developer to wade through a lot of irrelevant stuff. Nothing new here for anyone who’s been coding for a while, but it’s still good to mention.
In short: good work, thinking and making! While a lot of this advice is “mom and apple pie” type stuff, it still bears repeating, given the kind of javascript that you see people writing out there…

3 thoughts on “Best Practices for AJAX development

  1. Austin Govella July 28, 2005 / 12:26 pm

    For more involved apps, I’m hoping the graceful degradation would give me something useuful. For banking, maybe just a list of transactions and a balance. For email, maybe just the inbox headers. For maps, I’d hope to at least see one map.
    Something. Plus a note saying I need js for the rest.

  2. jon July 28, 2005 / 1:12 pm

    There’s no doubt in my mind that supporting graceful degradation is important. I mean, if you’re google, or if you’re a bank, then the application absolutely has to work for absolutely everybody. And if you’re doing tweaks to an existing site (to reduce latency, for example) it doesn’t make sense to break the site for your current users just to do an optimization.
    On the other hand, in certain circumstances I’m comfortable just saying “this app doesn’t work without javascript”. It’s analogous to shipping a Flash application that depends on Flash player 6. If you don’t have the player, the app won’t work.
    The context I’m thinking of here is built it / flip it self-funded web 2.0 style companies. Shipping an application that only runs on a certain platform is something software companies do every day, and web applications don’t have to work on 100% of all browsers in order to be a business success (see oddpost, basecamp, etc). Being first-to-market can pay off big-time, and sometimes that has to be the priority.
    Love your blog, by the way.
    -Jonathan Boutelle

  3. Ryan Nichols July 28, 2005 / 1:41 pm

    I agree on that point. When your developing a web application, it’s no different to require javascript than it is Word requiring windows. (ok a little different but you get the point :))
    Depending on the business requirements then it probably IS a good idea to show a friendly page with perhaps some examples of the interface and an explanation of the JS requirement. Or in some cases a reduced dataset.
    But overall with a limited budget I personally wouldn’t spend to much money developing a WEB APP that also degrades.

Comments are closed.