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.

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.

This post has been updated to cover Intern 3.4 and TypeScript 2.3. Read our Intern 4 and TypeScript testing article for more recent information.

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience.

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.

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.

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.

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.

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.

In our recent post on dgrid and Dojo Nano, we showed a technique of using nested require statements in order to make use of optimized layers using the Dojo build system. As a refresher, a layer is Dojo’s terminology for a file that combines many JavaScript resources into a single file.

Want an easy way to keep up with SitePen efforts on Dojo, dgrid, AMD, JavaScript, and the open web? Then click the Keep In Touch button at the end of this blog and sign up now! To see what types of things you can expect, check out the July edition of the SitePen Insider! With the SitePen Insider, we provide a concise monthly recap of things that are new and noteworthy. It’s targeted at software engineers and technical managers.

Dojo 1.7 added full support for asynchronous module loading, defined with the widely adopted asynchronous module definition (AMD) format. The new module loader and module format offer faster module loading, better performance, and wide interoperability.

We have been providing JavaScript and Dojo support to freelancers, start-ups and Fortune 500 companies for nearly a decade. As we intently watch enterprise organizations everywhere begin to roll out AMD (read about why AMD matters) and the associated code improvements, we are thrilled with the industry’s direction toward toolkit interoperability! Why? Because! Our masterful engineering team, consisting of influential members of various open source communities, positions SitePen perfectly to offer full-on, front-end web development support to the world! Getting right to the point, (The Official Point!), we are pleased to announce the expansion of SitePen Support to officially include more than fifteen popular open-source JavaScript toolkits! Now supporting the following JavaScript toolkits: Dojo Persevere packages dgrid Curl.js CometD Twine jQuery Backbone underscore RequireJS PhoneGap/Cordova MooTools jQueryUI Wire Socket.IO Express In addition to toolkits, we will continue to support your custom JavaScript source code, as well as key underlying technologies and formats, including JSON, HTML5, WebSockets, SVG/Canvas, Mobile Web, Server-Side JavaScript, AMD, Node.js and many more.

You may have seen our recent blog entitled “AMD: The Definitive Source” which exhaustively explained Asynchronous Module Definition. AMD is a topic with significant technical nuances but the purpose of THIS article is to explain the value of AMD for your business.

As web applications continue to grow more advanced and more heavily rely on JavaScript, there has been a growing movement towards using modules to organize code and dependencies. Modules give us a way to make clearly distinguished components and interfaces that can easily be loaded and connected to dependencies.