Observing Intersection Observers

By on September 5, 2017 9:51 am


As developing for the web has matured and JavaScript engines have become faster, one area remains a significant bottleneck – rendering. It’s because of this that so many of the recent development efforts have been focused around rendering, with virtual DOM being one of the more popular examples. In Dojo 2, being aware of these new APIs and approaches has been a priority. But working with a new API has its challenges and the Intersection Observer API is no different.

We break it all down over at David Walsh Blog.

Check it out!

Microservices and SPAs

By on February 20, 2017 10:32 am

The techniques involved in creating modern web applications are continually evolving. It can be difficult to separate out the ones that are truly improving how web applications are developed from those experiments that, while often interesting, are ultimately not worth investing in. From this sea of ideas a couple of trends have risen to the top and are radically changing how web applications are developed. These techniques are microservice-based architectures on the server and single page applications (SPAs) on the client. While an initial review of these two techniques doesn’t reveal any relation, a deeper analysis shows that these two trends are actually great partners and can be combined to enable powerful, yet maintainable, applications to be created.

Generating and Viewing Custom Dojo API Documentation

By on January 18, 2013 12:30 am

When developing a JavaScript framework that others will consume, it’s hugely beneficial to provide clean, organized API documentation to accompany your codebase. With the August release of Dojo 1.8, we saw a brand new, extensible documentation parser, which is used to generate output for Dojo’s API viewer. Generating documentation for any project and serving up a custom API viewer is easy, and this post will show you exactly how to do it.

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*, dojo.io.iframe, dojo.io.script), but the API has been less consistent than some of us would like (dojo.xhrGet, dojo.io.script.get, 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);
    promise.then(
        function(data){
        },
        function(error){
        }
    );
    promise.response.then(
        function(response){
        },
        function(error){
        }
    );
    request.get(url, options).then(...);
    request.post(url, options).then(...);
    request.put(url, options).then(...);
    request.del(url, options).then(...);
});

Creating and Enhancing Dojo Classes

By on July 1, 2010 12:02 am

Creating and Enhancing Dojo Classes

Like all top-notch JavaScript toolkits, Dojo tries to make its classes as flexible as possible, knowing that users of the toolkit may have different ideas about how a given class or class method should work. Luckily, Dojo provides you a number of methods by which you can subclass or modify existing classes. Let’s examine a few ways you can make Dojo classes exactly the way you like.

Hacking Safari’s Inspector

By on August 13, 2009 12:05 am

Recently the long-anticipated Safari 4.0 was released. The earlier WebKit was already fast, but this version performs just insanely well. Reloading a page on your local host takes milliseconds as I showed in my last post. Even more importantly, Safari 4.0 comes with a new inspector which includes all the functionality of Firebug, although it’s still not quite as good as Firebug. It doesn’t have the error handling ability, especially for the in-memory Dojo JavaScript files that are initiated with XHR eval. I still use Firefox primarily for development, but I find myself using Safari more and more often, as I just can’t resist the almost instantaneous refreshing of the page.

Stocker: Advanced Dojo Made Easy

By on April 1, 2009 4:41 pm

SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.

Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.

Stocker

Queued and AIR Issues, Part I

By on April 1, 2009 12:04 am

During the course of developing Queued, we ran across a number of challenges developing with AIR that we needed to solve. Some were very difficult to get around, while others were the result of our team needing to think outside the web-based paradigm. In this post, I’ll talk about four issues we ran across that ended up shaping part of the Queued codebase.

Queued: API Challenges

By on March 26, 2009 12:06 am

SitePen’s new Queued application works very well with the Netflix API, but the smoothness of this functionality was the result of a lot of research, and trial and error. In fact, this experience led me to propose that future project timelines should budget extra time when working with an unfamiliar API—and even more time when that API is brand new and untested. Netflix released one of the more exciting APIs in recent months and SitePen began to work with it right away. The Netflix team did great work on their API and they were also very helpful with us when we had questions or there was a bug on their end. I can imagine the challenges of setting up a (Netflix) REST API with an existing system and a large and complex library of items was not simple. Integration with the Netflix API presented its own set of challenges to us.