The build system that is part of the Dojo Toolkit is an incredibly powerful tool. Making sure that your custom build is always up-to-date in your web application can be time consuming and error prone if done manually. This post will demonstrate how to quickly add custom Dojo builds into any web application that uses Apache Ant.
Posted in Dojo, Performance | 6 Comments
The Dojo Toolkit has been around for over four years, and has undergone significant changes, both big and small, in becoming a great JavaScript toolkit. This article debunks myth and outdated assumptions (both fair and false) applied to Dojo over its four plus years of development.
Posted in Dojo, JavaScript, Open Source, Performance, ajax, thoughts | 45 Comments
So your cool new app is perfect, but you want it to lock the user out when the browser hasn’t had focus after 15 minutes? Well that’s easy you think, I’ll just connect to the document’s blur and focus events and be good to go. You quickly add a little bit of code to your Dojo widget:
dojo.connect(dojo.doc, "onblur", this, "onWindowBlur");
dojo.connect(dojo.doc, "onfocus", this, "onWindowFocus");
That should do it you’d think. Launch your app with Firefox and everything is great, easy enough. The same is true with Safari. After reluctantly firing up your Virtual Machine to test Internet Explorer 6, much to your dismay, onfocus events are immediately followed by onfocusout events. You feel the harsh reality that IE6 is going to suck away a bit more of your life.
Tags: events, focus, ie6
Posted in Dojo, Performance, ajax, browsers | 7 Comments
A typical server-side web framework today includes three main components: a URL dispatching to some controller object scheme, a template engine, and a data mapping facility. Currently in Dojo, you’ll find that the latter two items already exist. dojox.dtl provides the first one, and dojo.data provides the second.
We provide SitePen Support customers with a custom-built user interface for managing their support account. When we started working on this customer interface, we opted to make the entire user interface driven by JavaScript. The server-side provides data and data manipulation functionality via JSON-RPC, but does not dynamically serve up pages as a typical web app would.
Tags: django, reinhardt
Posted in Dojo, JavaScript, Performance, ajax | 9 Comments
An HTTP Proxy server relays requests between the HTTP client (e.g. your browser) and the server—whether it be out on the web, intranet or localhost. When it’s under your control, the proxy is a great place to inspect and debug client-server interactions over HTTP, log and report, tune and tamper with the requests the client makes, and the responses the server(s) produce. In this article I’ll show how to use Charles (one such proxy tool) to help solve a range of common web, and especially RIA, development problems.
Tags: charles, proxying
Posted in JavaScript, Performance, ajax, debugging | 1 Comment
A common issue encountered when developing web applications with the Dojo Toolkit is a startup lag caused by the dynamic loading of modules and resources, further aggravated by a flash of unstyled content before the template system kicks in and sets up your widgets. This is especially true when using numerous Dijit components, and even more apparent when not using a custom build (such as loading your files from the Google or the AOL CDN). While it is typically recommended to use a custom build, it isn’t always practical, or even necessary. Perceived speed is speed, and we should do something about it.
Dojo is a very flexible toolkit, and can bend and otherwise be manipulated to handle any use case. Personally, I am a fan of the progressive use case: where JavaScript is used to enhance an otherwise perfectly working collection of clean markup and good styles. Sometimes though, especially in the case of intranet applications or “admin panel” type web interfaces, you will find yourself using many layout widgets and form components. Delivering content quickly in this case is essential, and hiding any ugliness resulting from template substitution is a vital aspect to delivering the best possible user experience. Today, I’m going to go over a common technique to provide at least the perception of perfectly designed full-page layout applications.
Posted in Dojo, JavaScript, Performance, ajax | 12 Comments
In the middle of May, we were given a mission: create a speedy, offline API documentation viewer and a graphical Dojo build tool. Here we are at the beginning of July, and the result is the Dojo Toolbox 1.0. This article is a first look at this new application.
Adobe® AIR™ has received a good deal of press attention over the past few months, and with good reason. It provides a way for web application developers to use the skills they already have to create cross-platform desktop applications. Starting with Dojo 1.1, Dojo has included support for AIR out-of-the-box. This made AIR an ideal target environment for the Dojo Toolbox.
Tags: air, dojo toolbox, dojotoolbox
Posted in Dojo, JavaScript, News, Open Source, Performance, ajax | 24 Comments
Some sites can defer most, if not all, of their JavaScript-driven progressive enhancements until well after the page has loaded. Even so-called “lightweight” libraries like JQuery are far too heavy for some environments…not because they (like Dojo) pull in all the code needed to use them, but because they do it all up-front. Often the best time to pay the expense of loading, parsing, and executing JavaScript code is when the user takes an action that needs the enhancement to run. Dojo already gives you the best tools available anywhere to defer loading modules until you actually use them; other than those provided by dojo.js itself…but what about dojo.js? What if even the small size of Dojo is too big for your page? This need to load as fast as possible and defer work is never greater than in mobile applications. The best-performing thing to do is always to hand-write all the code you’ll need and never use more script than that…but there are complications. Not being able to share your code between developers (let alone between pages) can be a huge disadvantage. The code is also likely to be slow, buggy, and unmaintainable. There’s a real reason why toolkits like Dojo are so incredibly popular: they make much of this pain go away at the cost of initial download size. Why would anyone want to invite the pain back?
So we need some middle ground: a common, expected API surface area combined with a trivial initial footprint to ensure that pages load as fast as possible. How small could we make such a thing? Turns out, 6K.
Tags: 6k, Dojo, dojo light, dojo lite, dojo mini
Posted in Dojo, Performance, ajax | 13 Comments
I was doing some research on script loading speed tests. Each script load required the page to be refreshed, making it difficult to log the time to Firebug and get an average. It was certainly too much trouble to write some PHP scripts and connect to a database; and possibly even worse would be having to pull out a pencil and paper and write the times down. I’m not even sure I have a pencil.
The obvious solution was to write the data to a cookie. I also thought the solution was universal enough to blog about so others could use it too.
Tags: podo, testing, timer
Posted in Dojo, Performance, ajax, debugging | No Comments
In the last post on string performance, we did an analysis of string performance that spanned all of the major browsers, with the goal of optimizing the performance of the dojox.string.Builder. While we were able to create significant improvements in performance—particularly with Firefox—the performance under Internet Explorer was still pretty poor compared to native methods.
The goal for this article was to bring Builder’s performance down to comparable native operations—and we were able to do with through a combination of a slight change in code with using different ways of calling the append method.
Tags: ie6, ie7, internet explorer, string
Posted in Dojo, JavaScript, Performance, browsers | 11 Comments