Using Web Components With Angular

By on September 14, 2017 9:30 am

Angular is an application framework favored by many in the JavaScript community. Angular provides a library for building encapsulated components, dependency injection, a templating language with data binding, an application router built on observables, and a command line interface that lowers the barrier to entry. While being slightly less flexible than some frameworks, Angular’s opinionated nature helps larger teams to code to an existing standard rather than developing their own. In addition, Angular makes it easy to separate display logic (components) from business logic (services and logic) so multiple teams can work on different aspects of the same application. To see a more complete analysis of frameworks, see our series on choosing a framework.

Introducing dojo/request

By on August 21, 2012 6:00 am

As Dojo moves toward its 2.0 release, our focus has been on giving developers tools that will help them be productive in any JavaScript environment. This means creating consistent APIs across all environments. One area that has been sorely lacking, in this regard, is Dojo’s IO functions. We’ve always provided developers with a way to make requests in the browser (dojo.xhr*,,, but the API has been less consistent than some of us would like (dojo.xhrGet,, etc.). Additionally, we’ve never provided a server-side implementation, and if we had, it would have been another module name and API call to remember.

With the release of Dojo 1.8, we have introduced the dojo/request API which provides consistent API calls between browsers, request methods, and environments:

require(["dojo/request"], function(request){
    var promise = request(url, options);
    request.get(url, options).then(...);, options).then(...);
    request.put(url, options).then(...);
    request.del(url, options).then(...);

Queued: Drag and Drop in the Queue

By on April 16, 2009 9:52 am

During the interaction design phase, we determined that Netflix’s current drag and drop reordering feature was well thought out — so we set out to create the same reordering behavior in Queued. As Revin mentioned before, we also wanted to keep Queued as light as possible; because of this, we decided early on to not use any of the Dijit infrastructure to create the queue listings. Not only that, but the Dojo Grid would not work for the queues because it doesn’t support drag and drop reordering of rows. This meant we would have to come up with something which would be flexible (yet fast) to render the queue.

In the user interface design phase, we decided that each of the lists in the “Your Queue” section would be based on HTML tables. In Queued, only the DVD queue and the Instant list can be reordered, so we’ll focus on the DVD queue.

New Features in Dojo Grid 1.2

By on October 22, 2008 11:10 am

The last article about the Dojo Grid focused on what has changed when creating a grid using Dojo 1.2. In this article we will be covering five new features of the Dojo 1.2 Grid: Dijit interoperability, selection modes, reorderable columns, header context menus, and column hiding. The examples in this article can be downloaded in a tarball (which includes the build profile I used) so you can play along from home!

Dojo 1.2 Grid

By on July 14, 2008 12:34 am
NOTE: This article is out of date.
Read about the new dgrid for something fresh!

With the release of Dojo 1.2 right around the corner, there’s an updated grid widget available. It offers new features and performance improvements over the existing grid including better Dojo data integration, simplified layout structures, and the ability to enable editing much more easily.

Simple Dojo Grids

By on November 6, 2007 10:16 am

Grid browser

We’re excited about the release of Dojo 1.0. In honor of the new release, I’m starting a series on one of the newest additions to the Dojo mix: the Dojo Grid.

When demonstrating Dojo, I prefer tying examples to real-world scenarios. Imagine for a moment that we work at a company that produces gaskets out of sheet material. Each of these gaskets has a part number, a minimum temperature rating, a maximum temperature rating, and maximum pressure rating. Each of these attributes needs to be a column so they can be displayed and sorted so customers can find the information they need in a timely manner. Let’s take a look at how the data looks:

Extending Dojo 0.9: Multipart Transfers

By on September 11, 2007 8:55 pm

The release of Dojo 0.9 on August 20th marks a return to our roots: fast and lean. As Alex mentioned in a previous post, the surface area of the API has been reduced. With this API refactor, things were bound to be left out, and rightly so. The “core” of Dojo needed to be lean so we cut out the fat. But cutting out the fat sometimes removes some useful functions that people use. Fortunately, Dojo 0.9 makes it easy to add features on to it with little hassle.

One feature that wasn’t ported to 0.9’s AJAX IO was multipart transfers. I stumbled across this casualty of the refactor while working on a side-project: a port of Eugene Lazutkin’s webui for OpenWRT from Dojo 0.3 to 0.9. webui is a configuration interface for OpenWRT that takes the approach of trying to do most CPU and RAM intensive operations in the browser rather than use the limited CPU and RAM of the router. For example, when you edit the rules for the router’s firewall, the firewall rules file is downloaded to the browser and dissected in JavaScript. This makes it very easy to add rules in the right places and delete the correct rule without tasking the router with this work. After you’ve modified the firewall rules to suit your needs, the file is re-assembled and uploaded to the router using a multipart transfer. Because of this functionality, multipart transfers are vital to this application.