Despite various steps that the WaveMaker team has taken to optimize performance, it is nearly impossible for us to anticipate all of the needs of all possible applications. Take for example, the dojo build layers we use which group javascript classes into libraries, minify and gzip them, and only load the libraries that are currently required for the pages you are showing.
These libraries are designed so that you don’t have to load the entire framework, only the parts of the framework you actually use. Why is this a problem?
1. Why it Matters
- Perhaps you come from a background such as java where you just type in import java.io.*; and don’t worry about the performance
- Perhaps it hasn’t occurred to you that every type of widget you use represents a class library that we need to load from the server
- Perhaps you’ve done all of your testing on localhost where the bandwidth available for loading libraries is far greater than you get from a deployment server.
Every library is loaded over the network. Loading a library this way is conceptually the same as in java, but every library loaded is a human noticeable delay in starting your application. The build layers available in WaveMaker 6.4 are as follows:
- Main library: 127K
- Charts: 56K
- Grids: 139K
- Editors (Except Text editor which is in the main library): 42K
- Forms: 6.4K
- Menus: 10K
Note that the main build library is reduced in size to 1/7th of its original size by minifying it and gzipping it.
2. Loading too many resources:
Lets say you use a Date editor and that is the only editor in the first page of your application. You have to load the entire editors library from the server, consuming bandwidth, download time, compilation time. In other words, there is a cost to downloading this library, and perhaps we are overpaying if we only needed a single editor from the entire library.
3. Loading widgets that aren’t in a build layer
Lets say you use a few widgets that we (in our attempt to guess what the typical first page would have) didn’t think you’d be using and so left out of the core library and didn’t have a suitable minified build file to package it in. For example, lets say you use an IFrame widget. This is not part of our main build layer (i.e. it is not something that most applications are expected require access to in order to display their first page). It also isn’t part of any other library of widgets (what widget is an IFrame most commonly used with such that you should load that widget any time you load the iframe?). So when you put an IFrame widget in a page, you are loading a class file across the network that has not been minified and has not been gzipped. Especially if such a widget is on your main page, this will impact performance.
What to do about this?
While it is not practical at this time to use dojo build tools to create a custom layer, you can gather the class files you require into a single file, run them through google closure to minify them, gzip the resulting file, and load that with your main page. Doing this means that with a single request, you can get a minified and gzipped iFrame class and a minified Date Editor class instead of loading an unminified IFrame widget and the entire editors package.
For a writeup on the process used to do this, see
Performance Docs
Moving forwards
For WaveMaker 6.5, there will be very few widgets that aren’t in a build layer; and the individual layers will be smaller, containing a more precisely defined set of widgets so that it may take a few requests to get all of your classes loaded, but you will get a set of classes better optimized to cover your main page and less extra fat downloaded.
Please feel free to post questions and suggestions (preferably here rather than on the wiki page)
Michael Kantor
SMTS; VMware
We are closing in on the first drop of WaveMaker 6.5 so I thought I’d provide information about some of the infrastructural changes we’re making in WM 6.5. Some of you may have noticed that our source code is now on 
