Last Fall I gave an Ignite presentation at Refresh Events on “5 Tips for Better JavaScript Applications”. If you’re not familiar with the format, an Ignite presentation is 5 minutes, 20 slides, with 15 seconds per slide. That’s not much time, but I thought it would be fun to try to present complex technical material under such tight constraints.

Long story short, it took some good ‘old fashioned fast talking, but I like to think the presentation was a success. The slides are located on Slideshare, but viewing them on their own without my stumbling narration might not do you much good. So I thought I’d summarize them again here:

1. Embeddable JavaScript Templates

I really dislike mangling together strings in JavaScript to produce markup, so I’ve taken to using templating libraries instead. Think erb, Liquid – but in JavaScript. My favourite solution so far is JSON Template, which has the upside of being cross-platform, but there are plenty of other choices: Pure, EJS, and jTemplates are just a few worth looking at.

One problem with JavaScript templates is choosing where to store them. Storing templates as JavaScript strings isn’t really any better, and individual files (fetched each time) seems overkill. My trick is to embed templates directly into HTML by hiding them inside a <script type="text/html"/> tag. These tags are ignored by the browser (since text/html is an unsupported script type), so they can live happily in the page until you need to render them. Credit to John Resig who mentioned this technique on his blog.

2. Classical Inheritance Libraries

JavaScript is a prototype-based object-oriented language, but with some clever manipulation, it can also be made to support classical inheritance as well (think Java, Ruby, etc.). I like using classical inheritance in my apps because it’s a well-understood pattern that any of my server-side-inclined colleagues can follow, quickly.

There are a handful of libraries that will help you get started. I’ve used both Dean Edwards and John Resig’s solutions, but Google’s implementation, as part of the Closure library, is worth a look too.

3. The Debugger Keyword

Did you know you that the “debugger” keyword will automatically set a breakpoint in any active JavaScript debugger in your browser? I find it’s a real time saver; instead of hunting down code in your debugger, you can set breakpoints from your editor. It’s even more helpful when you’re debugging across multiple environments; all the major browser support it.

I threw this into my original presentation as a one-slide means of saving time, but it’s still a great tip, and to my surprise, not exactly common knowledge.

4. Custom Events

You can trigger your own events in JavaScript, and bind to them as well, just like you can regular UI events (i.e. onclick). It’s a helpful tool in reducing coupling. Instead of calling a function directly, you trigger an event, and then other parts of your application can bind to that event and act accordingly.

If you’re a plugin developer, this is an ideal way to expose hooks to your plugin. Instead of having to inherit some base class and override an existing method, try triggering events people can bind to instead.

5. Preserving the Browser’s Back Button

Preserving the back button is easier than it looks. The jist of it is this: give your various application states a unique URL prefixed with the pound sign (#), then implement a “router” that can restore to these states when the page is loaded or the URL changes. That last part where it gets tricky – and where a plugin like jQuery history will help you out.

Other browser history libraries worth checking out: ReallySimpleHistory and jQuery Address.