Skip to main content

Optimizing Dojo Loading for Bootstrap Widgets

Over the past year, one of our major efforts for our iPhora products was to switch from using Dojo Dijit widgets to only Bootstrap widgets.  One of the problems that we have seen with Dijit widgets is that they take a long time to load and are very heavy compared with JQuery based Bootstrap widgets. The advantage of JQuery-based Bootstrap widgets is that they are loaded all at once as a single file. This is great to minimize the loading speed.  However, it does not lend itself to easy maintenance by multiple developers.

With Dojo you load the individual widgets are needed using dojo.require. Unfortunately, this results in multiple HTTP request in order to load the individual widgets and support files. Even if we are not using Dijit widgets but you want to use dijit._Widget to creating your own widgets, Dojo loads a whole brunch of additional files like dijit._LayoutWidget.js and doubles the loading process.  That is because you need to load dijit.js in order to use dijits. So without any widgets on the page it requires you to load the following:


 
 
I highlighted in red the files that I did not need to load.

 

Note: I use buildRendering directing instead of using dijit._Templated.  I load dojo.string when I need it and do not use dojo.cache.js since I am not using dijit._Templated.

So out of frustration, I was determined to figure out how to get rid of these unneeded files.  When you require dijit._Widget  it automatically forces you to load dijit._base which loads many files that is specific to dijit widgets.  So I first strip this down from:


if(!dojo._hasResource["dijit._base"]){
dojo._hasResource["dijit._base"]=true;
dojo.provide("dijit._base");
dojo.require("dijit._base.focus");
dojo.require("dijit._base.manager");
dojo.require("dijit._base.place");
dojo.require("dijit._base.popup");
dojo.require("dijit._base.scroll");
dojo.require("dijit._base.sniff");
dojo.require("dijit._base.typematic");
dojo.require("dijit._base.wai");
dojo.require("dijit._base.window");
}
 
to
 
if(!dojo._hasResource["dijit._base"]){ dojo._hasResource["dijit._base"]=true; dojo.provide("dijit._base"); dojo.require("dijit._base.focus"); dojo.require("dijit._base.manager"); dojo.require("dijit._base.place"); dojo.require("dijit._base.typematic");
dojo.require("dijit._base.window");
}
 
which takes care of all the dijit._base files.  The rest of the highlighted files are load by dijit.js. So instead of loading dijit.js for the page I created by own loader js file that contains:

/* Copyrighted 2009-2013 Phora Group. All rights reserved.*/
if(!dojo._hasResource["dijit._base"]){
 dojo._hasResource["dijit._base"]=true;
 dojo.provide("dijit._base");
 dojo.require("dijit._base.focus");
 dojo.require("dijit._base.manager");
 dojo.require("dijit._base.place");
 dojo.require("dojo.uacss");
 dojo.require("dijit._base.typematic");
 dojo.require("dijit._base.window");
}
if(!dojo._hasResource["dijit.dijit"]){
 dojo._hasResource["dijit.dijit"]=true;
 dojo.provide("dijit.dijit");
 dojo.require("dijit._Widget");
 dojo.require('dojo.cookie');
 dojo.require('iphora._ipBase');
}

It first loads all the _base files that I need and then load dijit which contains the only thing I need, dijit._Widget.  As part of the process I have it also load dojo.cookie which I usually need and iphora._ipBase which has all the base iphora support methods for creating Bootstrap widgets.

This method eliminates the need to call dijit._base separately which normally creates another HTTP request that is not needed. When the call is made to load dijit._Widget, dijit._base is already loaded with the new file list definition so it uses this list instead of the one that is provided.

So as a result of this exercise the loading process requires less than half of the files.


 
 
 
 
 
 
 
 
 
 
 
 
What you need to load depends are what you are doing with Dojo.  So if you are interested in creating a faster loading process you should experiment.  Have fun.
 

Comments

Post a Comment

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select
Post a Comment
Read more

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a
Post a Comment
Read more

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo
Post a Comment
Read more