
Stumbled upon an interesting document on Twitter.
The title indicates the WRT category (Nokia Web Runtime or Widget for S60), that is, the specific Nokia platform, but I think it will be interesting to read for many people, perhaps you will find something new for yourself. There are really useful tips, but there are also harmful ones, especially in the light of modern development __ all browsers_.
At first I thought of making it a topic-link, but under the cut, I’ll draw attention to some of the problems of this article. The article is worth reading, but in no case do not treat it as the ultimate truth.
Once again, these comments should be viewed from the light of "universal programming for all browsers." It is possible that in terms of development for Symbian article - extremely true
')
Offer your comments in the comments - maybe in the end it will result in a great article about optimization
I would have edited this article on the wiki myself, but “You don’t have sufficient privileges to view this page or perform this action.”
To begin with, the article reveals many really useful tips.
For example, the use of eval is best avoided, and when you receive and resize an element
, unnecessary reflow may appear (minimizing the dimensions or location of elements).
Avoid modifications while traversing
And the container that returns getElementsByTagName is really “live” and the following code will hang your browser:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Test</title> </head> <body> <div id="container"><em></em><em></em></div> </body> <script></script> </html>
var doc = document, ems = doc.getElementsByTagName('em'), cont = doc.getElementById('container'); for (var i = 0; i < ems.length; i++) { cont.appendChild(doc.createElement('em')); };
However, there are a number of drawbacks.
First, the error. Examples:
Avoid using eval or the Function constructor
addMethod(myObj, 'methodName', function () { 'this.localVar=foo'; });
Download scripts
script.onreadstatechange => script.onread y statechange
And the errors are not of the synthical plan, but of a logical one:
var elem = document.getElementById('elem').propertyOne = 'value of first property'; elem.propertyTwo = 'value of second property'; elem.propertyThree = 'value of third property'
Secondly, although some tips will really speed up your application - they do not make sense, because have a completely different program logic.
Simply put, do “B” instead of “A” because “B” is faster.
An example is
Don't use try-catch-finally inside performance-critical functions
Sometimes it may be necessary to handle exceptions inside the loop, sometimes outside. These two operations have a completely different basis and a different result.
Avoid for performance functions
Again - a different result.
var i in arr
for arrays is applicable in extremely rare situations. The most correct iteration over an array (used in frameworks):
for (var i = 0, len = arr.length; i < len; i++) if (i in arr) {
This will correctly pass an array that is not completely filled and corresponds to the behavior of the forEach method from the latest specifications:
var arr = ['zero','one','two']; arr[10] = 'ten'; arr.forEach(function (elem) { console.log(elem);
If you know the contents of the array and it doesn’t matter in which order it is traversed, you can use a reverse loop
function sum (arr) { var result = 0; for (var i = arr.length; i--;) { result += arr[i]; } return result; };
My old tests have shown that it is not only readable well, but also faster than a straight pass.
Try to keep script comments on a minimum / Avoid long variable names
First, in the latest versions of modern browsers there is a jit-compilation, which makes this tip inappropriate.
Secondly, in the working application the scripts are compressed and the comments are cut out. and during development such optimization does not make sense
Thirdly, comment as much and exactly as you need to properly understand this code. Whatever impact it has on performance is not important.
Store local references to out-of-scope variables
Caching document makes sense, but the example is bad, which in this case does not make sense, because Reading from the cache occurs only once.
Consider using a custom datasets for data exchange.
Bad advice. Try to avoid your own data formats as much as possible and the article shows an example of such horror:
that.contacts = o.responseText.split("\\c"); for (var n = 0, len = that.contacts.length, contactSplit; n < len; n++) { contactSplit = that.contacts[n].split("\\a"); that.contacts[n] = {}; that.contacts[n].n = contactSplit[0];
First, it
var contacts = JSON.parse(o.responseText);
lot longer to write than
var contacts = JSON.parse(o.responseText);
Secondly, JSON parsing in many browsers is built-in and it is likely that your “fast” format will work much slower than JSON. But maybe faster,
see the comments .
Thirdly, there are a lot of flaws during the support: the non-obvious contents of
o.responseText
, you have to write a parser and format compiler on the server and the client, third-party developers will be in Shock, etc.
The basic idea is that such optimization rarely makes sense. In most cases, it is worth avoiding it due to many shortcomings.
In general, read and think. Interesting and useful tips are there, but analyze everything and do not use it thoughtlessly. As always)