Dojo + Koa

By on June 19, 2015 7:03 am

Dojo and its AMD loader provide outstanding tools for structuring a Web application on the client-side. However, the notion of “writing a JavaScript application” has widened in definition over the past few years with the increased popularity of Node.js. Though Dojo can be used in a Node.js environment with the AMD module pattern, other key frameworks have gained prominence in the server-side JavaScript space, including Express, Flatiron, Sails.js and the Dojo Foundation’s very own Persevere. These frameworks give structure and handle common tasks such as routing, template rendering, and content negotiation. Still, since most operations on a Node.js server are asynchronous, server-side JavaScript can be a complex, treacherous mess of callbacks. Enter Koa, a Node.js framework that attempts to save us from this callback hell by using ECMAScript 2015 Generators. Using Dojo on the client-side and Koa on the server-side makes for a robust, clean, and expressive application. In this post, we’ll explain what generators are and how to use Koa with Dojo for ultimate code cleanliness.

Multi-Platform Distribution with TypeScript

By on June 1, 2015 10:47 am

Over the past several years, JavaScript has grown to be relevant not only for rich browser applications, but also for server and console applications. Many types of JavaScript libraries can be useful on both ends of this spectrum. Dojo 2 is no exception, and one of our goals is therefore to make it as easily distributable and consumable across environments as possible.

Module Compilation in TypeScript Today

TypeScript can already help toward this goal by compiling to both the AMD and CommonJS module formats. For example, given the following simple TypeScript module:

export function myFunction() {
    // ...
}

Testing TypeScript with Intern

By on March 24, 2015 9:34 am

Intern

This post has been updated to cover Intern 3.4 and TypeScript 2.3

Intern is a popular JavaScript testing framework, because of its extensive, modular feature set. While Intern is primarily known for testing JavaScript applications, it is also an excellent option for authoring tests with TypeScript. And Intern’s support for source maps makes it easy to track issues back to your original TypeScript source files.

Memory Consumption: the Externality of Programming

By on March 17, 2015 11:35 am

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting. As developers, we wisely work for better performance by understanding performance characteristics, and verifying performance with tests. However, one aspect of performance can be particularly difficult to assess, and its effect can easily be underestimated. Memory consumption can have a large impact on performance, but in ways that can easily be missed and ignored.

From DOH to Intern: Updating Dojo core’s tests

By on February 18, 2015 10:11 am

Intern

One of the primary motivations for creating Intern was to make support for continuous integration testing much easier to achieve with JavaScript-based application development. We recently converted the vast majority of the unit tests in Dojo core from DOH to Intern, in order to streamline the process of regression testing patches for Dojo 1.x.

This was a very large amount of work, and we learned a number of interesting things along the way that should be useful to you in writing your own tests.

Patching Modern Dojo

By on January 28, 2015 2:41 pm

DojoFAQ

While it will not happen often, there may be times when you need to patch your Dojo source. Perhaps you discovered a bug and are waiting for the fix to be committed or released, or your application uses an older version of Dojo but you want to use features found in newer releases. Dojo’s AMD plugin loader makes it possible to apply patches without resorting to modifying the source files themselves, making it easier to upgrade your version of Dojo.

As an example, Dojo 1.10 introduced dojo/throttle into the core—along with the extension event dojo/on/throttle—for ensuring that a function is fired only once during the specified interval. However, if you are developing with an earlier version of Dojo (for example, 1.9.6), you will either need to upgrade to 1.10.x or provide a patch to use it with 1.9.6. In this post, we will create patches for these modules.

Dojo FAQ: How do I load multiple versions of Dojo on the same page using modern Dojo?

By on October 22, 2014 1:02 pm

DojoFAQ

The way modules are loaded changed with the introduction of modern Dojo (1.7+). Dojo now uses the AMD format for packaging and loading modules within an application. AMD avoids the use of globals, which limits the likelihood of unintended interactions between modules. By leveraging AMD and the flexible configuration provided by the Dojo loader, we can load different versions of the same package on a page without dangerous interactions.

Mocking data with Intern

By on July 14, 2014 11:43 am

When writing tests for an application, it’s prudent to add mock or stub data in order to allow code to be properly tested in isolation from other parts of the system. Within a normal Dojo application, there are typically three places where mocking will occur: I/O requests, stores, and module dependencies.

Testable code best practices

By on July 11, 2014 12:03 pm

Many of the best practices for writing testable code also conform to general code best practices. Code that is easily testable often also tends to be highly maintainable and resilient against changing business requirements. This blog post provides a brief overview of key criteria for writing highly testable code.

Dojo FAQ: Dynamically loading CSS

By on July 2, 2014 11:46 am

DojoFAQ

In large JavaScript applications, it can be beneficial to dynamically load CSS stylesheets. For example, if a certain JavaScript widget, such as a complex grid, uses a large standalone stylesheet for its display aesthetics, it would be optimal to only load this stylesheet if the widget is in use, rather than always including the CSS source on each application load.