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.
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. Intern is a popular JavaScript testing framework, because of its extensive, modular feature set.
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.
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. This blog post provides a brief overview of key criteria for writing highly testable code.
In large JavaScript applications, it can be beneficial to dynamically load CSS stylesheets.
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
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.
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.
So what is AMD? 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.