40. Runaway Script Timer Limits
• Internet Explorer: 5 million statements
• Firefox: 10 seconds
• Safari: 5 seconds
• Chrome: Unknown, hooks into normal crash
control mechanism
• Opera: none
41. How Long Is Too Long?
“0.1 second [100ms] is about the limit for
having the user feel that the system is reacting
instantaneously, meaning that no special
feedback is necessary except to display the
result.”
- Jakob Nielsen
42. Translation:
No single JavaScript job should
execute for more than 100ms to
ensure a responsive UI
46. JavaScript Timers
• Created using setTimeout()
• Schedules a new JavaScript execution job for
some time in the future
• When the delay is up, the job is added to the
UI queue
– Note: This does not guarantee execution
after the delay, just that the job is added
to the UI queue and will be executed when
appropriate
47. JavaScript Timers
• For complex processing, split up into timed
functionality
• Use timers to delay some processing for later
48. function timedProcessArray(items, process, callback){
//create a clone of the original
var todo = items.concat();
setTimeout(function(){
var start = +new Date();
do {
process(todo.shift());
} while (todo.length > 0 &&
(+new Date() - start < 50));
if (todo.length > 0){
setTimeout(arguments.callee, 25);
} else {
callback(items);
}
}, 25);
}
59. Web Workers
• Asynchronous JavaScript execution
• Execution happens in a separate process
– Not on the UI thread = no UI delays
• Data-driven API
– Data is serialized when sending data into
or out of Worker
– No access to DOM, BOM
– Completely separate execution
environment
60. //in page
var worker = new Worker("process.js");
worker.onmessage = function(event){
useData(event.data);
};
worker.postMessage(values);
//in process.js
self.onmessage = function(event){
var items = event.data;
for (var i=0,len=items.length; i < len; i++){
process(items[i]);
}
self.postMessage(items);
};
74. A repaint occurs when a visual change doesn't
require recalculation of layout
Changes to visibility, colors (text/background), background images, etc.
76. A reflow occurs when a visual change
requires a change in layout
Initial page load ▪ browser resize ▪ DOM structure change ▪ layout style change
layout information retrieved
82. Off-Document Operations
• Fast because there's no repaint/reflow
• Techniques:
– Remove element from the document, make
changes, insert back into document
– Set element's display to “none”, make
changes, set display back to default
– Build up DOM changes on a
DocumentFragment then apply all at once
83. DocumentFragment
• A document-like object
• Not visually represented
• Considered to be owned by the document from
which it was created
• When passed to appendChild(), appends all
of its children rather than itself
91. What to do?
• Minimize access to layout information
– offsetTop, offsetLeft, offsetWidth, offsetHeight
– scrollTop, scrollLeft, scrollWidth, scrollHeight
– clientTop, clientLeft, clientWidth, clientHeight
– Most computed styles
• If a value is used more than once, store in
local variable
99. Avoid Slow JavaScript
• Don't allow JavaScript to execute for more
than 50ms
• Break up long JavaScript processes using:
– Timers
– Web Workers
100. Avoid Long UI Updates
• Be careful of repaint and reflow
• Perform complex DOM operations off-
document
– Remove elements and re-add them
– Use DocumentFragment objects
• Group style changes together
• Avoid accidental reflow
Over the past couple of years, we've seen JavaScript development earn recognition as a true discipline. The idea that you should architect your code, use patterns and good programming practices has really elevated the role of the front end engineer. In my opinion, part of this elevation has been the adoption of what has traditionally been considered back end methodologies. We now focus on performance and algorithms, there's unit testing for JavaScript, and so much more. One of the areas that I've seen a much slower than adoption that I'd like is in the area of error handling. How many people have an error handling strategy for their backend? How many have dashboards that display problems with uptime and performance? How many have anything similar for the front end? Typically, the front end has been this black hole of information. You may get a few customer reports here and there, but you have no information about what's going on, how often it's occurring, or how many people have been affected.
So what have we talked about? Maintainable JavaScript is made up of four components. First is Code Conventions that describe the format of the code you’re writing. Second is Loose Coupling – keeping HTML, JavaScript, and CSS on separate layers and keeping application logic out of event handlers. Third is Programming Practices that ensure your code is readable and easily debugged. Fourth is creating a Build Process