Have you ever written JavaScript that injects values into the middle of a string? Did you slice, substring, and RegExp your way to victory? You probably did. Unless great care is taken, this approach is fragile and produces code that is almost certainly difficult to read. Dojo provides help for this problem via an incredibly convenient utility for performing parametrized substitutions on a string, dojo.string.substitute.

Many developers with a background in Software Engineering are drawn to Dojo because of its ability to simulate classical type declaration and inheritance structures via dojo.declare. Specifying a ‘class’ via dojo.declare is straight-forward, but an extremely common mistake involves the accidental declaration of a ‘static field’ (i.e. a class variable) when intending to declare an instance variable.

The other day, I was working on a Dojo-based project and was paring down a JavaScript array using the ultra-slick dojo.filter function. As I was effortlessly discarding the unwanted array elements, I had the thought, “Man, I really could have used dojo.filter when I was trying to get rid of those Busch beers!”. The revelation at the handiness of dojo.filter made me realize that the Dojo array functions deserve a blog post of their own. And what better contrived data set than an array of beers?

When you use a JavaScript library, does this mean that your days of browser-specific issues are over? Should you just test your code in the latest version of Chrome and call it a day? Of course not. There still exists an entire class of programming errors that introduce bugs that only appear in certain browsers. Of these problems, none of them are more sinister than……..the Trailing Comma of Death.

We will explore how to ‘bind’ a widget property to a DOM node. That is, we will configure our widget to listen for changes in its properties and automatically update the relevant DOM nodes when a change occurs.

Enterprise Web Applications are full of common UI elements and functionality that are ripe to be encapsulated into a reusable widget. Lucky for you, Dojo makes this process easy. The resulting code is cohesive and modular, just the way we like it.

The typical beginning of an Enterprise Developer’s JavaScript education is involuntary in nature. In many cases an engineer with a strong background in Java, or other strongly-typed languages, is informed that their next project requires JavaScript. Like all forced actions, this will be a bumpy road. So bumpy in fact, that the Enterprise Developer will go through a grieving process as they leave behind their beloved strongly-typed language and plunge into the duck-typed world of JavaScript. This process of grief has four distinct stages.

We start this post with a quotation from our dear old friend, JavaScript Hater.

JavaScript?

Yeah, it’s great. I just love writing a big ol’ pile of Spaghetti Code.

Now, before we rush out and buy this T-shirt for him, let’s recognize that Hater has a point. There is no programming language that allows you to go from Zero to Incomprehensible quite like JavaScript (Ok fine, we’ll throw in Perl too). In academic terms, Hater is referring to a lack of cohesion…

Here’s the Enterprise Developer’s typical introduction to JavaScript:

• Developer is assigned a task that requires JavaScript. Developer already knows Java and decides that this is more than enough background to dig into JavaScript.
• Developer searches for a code snippet that performs the desired task.
• Developer finds code snippet and understands 60% of it. Developer does not care about the 40% that looks weird. Developer copies snippet and pastes it into their web page.
• Code snippet doesn’t work. Or worse, code snippet only works in Firefox.
• Developer hacks on snippet for an hour.
• Developer may or may not ultimately succeed. Either way, Developer dismisses JavaScript as a steaming pile of turds.

Sound familiar?