I have built a RIA on a single page. I am using Dojo 1.7.2. The page contains about 200 dijit/NumberSpinners and some TabContainers and TitlePanes. Of course this works perfect in all browsers, except Internet Explorer 8 which is used by the client’s company.
In all browsers the parsing of the whole page takes a few seconds, in IE8 it was 2 minutes, and I got it reduced to 40 seconds by using the following tips:
- Use custom build
- Create widgets programmatically instead of declaratively
- Parse widgets only once they are shown. (this does not speed up the parsing, it only makes the user wait more while using the application instead of before.)
- Substituting NumberSpinners for NumberTextBox (which reduced the parsing time by half!)
Any other tips? I could try reusing the NumberSpinners and throw them around when a div gets visible, but this requires my application to be rewritten quite substantially.
The situation you are facing is, that very very many nodes are created in the DOM, and programatically. IE has poor performance for this, being held back by the javascript engine. Yikes huh?!
Your goal is to define as much as possible beforehand as opposed to override this during runtime. By this i mean setting parameters in the data-dojo-props / construct arguments. This especially applies for stuff like onClick handlers etc. You’d achieve this by doing like such:
But; why did NumberSpinners > NumberTextBoxes reduce by 50%? This is why:
Template TextBox
Template Spinner
There is not much one could do with the TextBox template to optimize it, only entrypoint would be the ${type} parameter which is set using regular exp replacement via _getTypeAttr. in postMixInProps (before _TemplatedMixin runs and generates DOM) the value is overridden into ‘text’ even if anything else is specified. Allthough – not sure how this would implicate – one might want to take away the focusNode + FocusMixin, but i will not go into that.
There’s a little quirk handling in the dijit/form/MappedTextBox (which creates a hidden
<input>, containing the ‘true’ value see http://bugs.dojotoolkit.org/ticket/8660. This has put a regexp replace on ‘this.name’ to fix problems – leaving out the name attribute on your input field will take care of that (if possible use Id instead).Template ValidationTextBox
The main reason for using NumberTextBox would be the range limitation right? In order for that particular module to load, a number of mixins are done – but basically they are based on the ValidationTextBox. This offers a
.validatefunctionality and shows messages if needed. The above note on removing focusmixin will take the messaging out of business since they act on the onBlur events.If you were to use ValidationTextBox as opposed to NumberTextBox and implement the range checks by custom functionality i believe it would work wonders. A good deal of eval’d code is run ontop of validationtextbox to make it numbertextboxes – some of which probably is overhead in your case.
a sample override to the validation: