We are maintaining a TOC for our JS-discussions here.

Development Tools

Firebug is the most important development tool for us, without comparison. Everyone is familiar with this time-tested tool.

You will rarely need more than Firebug, although there are some valid alternatives now, in 2010. Chrome, Safari and Opera (Dragonfly) have all internal tools for debugging (and more). None of us have used those tools extensively, so we don’t know more than what we have heard from third parties, which is mostly positive. If you need to spot errors in IE, Microsoft Script Debugger is your best hope. IE8 ships with this integrated as default. No-one in our team reported ever making use of the Firebug Light for IE.

When it comes to JavaScript editors, we find that no text editor seems to differ significantly from the rest. Most editors provide color-formatting, some provide API-reference with autocompletion and some editors like vim and TextMate can be configured for auto-validation through JSLint.

Coding Standard

Our coding standard for JavaScript builds on our own internal PHP Coding standard as far as it fits, which in turn builds on the publicly available Zend Framework Coding standard.

We have boiled our standard down to this shortlist.

• Follow the Zend Framework Coding standard
• Use an underscore in front of private objects. (i.e. var _private = 0;) Private objects and methods can be defined as «trusted» with everything else foreign and error-prone. This can make your core more stable and rigid without having to overdo it with data-testing and integrity validation.

It is possible to achieve a private scope in JavaScript, but it comes at a cost in complexity, and we have decided against it. Our decision is based on experience and advice given in “Pro Javascript Design Patterns“.

/**
 * Rationale and short description of ClassName.
 */
var objectName = {
    myFunction: function(whatToDo)
    {
        if (typeof whatToDo === 'string' && whatTodo.length > 0) {
            objectName._doWhatYouGottaDo(whatToDo);
        }
    },
    _doWhatYouGottaDo: function(whatToDo) {
      // As this is a private function, I trust the type and data validity of the argument
      alert(whatToDo);
   }
};

The above is a minimal example, which in no way covers all the rules accurately.

Guidelines

Global scope. Put as little garbage as possible in the global scope. Use well-named objects as namespaces and if needed sub-namespaces. Know the results of using or skipping “var” when creating objects.

Use closures, with care! Closures are necessary in JavaScript, but as not all languages have them, they will to an inexperienced JS-programmer look too much like Magic(TM), which isn’t too good. Use good judgement when to use them, and  remember good inline commenting to make the magic more transparent.

Don’t use the “new” operator. When setting up prototype inheritance it has to be used, but there are no other cases where it should be used. In most cases it’s not only slow, but the alternatives are often easier to understand, require less code and are more powerfull. Because of this, we have decided to conform on code without new. As examples, new Array and new Object should be written as [] and {}.

Prototype inheritance contains power for object oriented code. We will return with more guidelines when our experience grow. We must admit not to have used this elaborately. A serious liability of PrototypeJS (the framework we used) is that it overrides prototype (the language feature) from JavaScript.

Few anonymous functions. As a rule of thumb, we say: name functions. This has to do with testability and readability of your code. The exception is if you need a “one-liner” to use just once, in which case anonymous functions are OK. You would normally not test these kind of functions.

Lint your code! Lint is a code quality tool, and it will hurt your feelings. But  that pain is just Douglas Crockford stabbing the parts of you responsible for writing bad JavaScript. You end up stronger in the end.

Recommended research material

JavaScript requires effort on your behalf. You need to do the homework if you want to be a powerful and successful JavaScript developer. For starters we recommend these resources:

• Closures : Working with closures and Explaining JavaScript scope and closures.
• Douglas Crockford: “JavaScript – The Good Parts” (video)
• Douglas Crockford: “JavaScript – The Good Parts” (amazon)
  

We have decided to address JavaScript with more care. We’d like to give it the time and focus it deserves. Not to be mistaken, we are probably in the top 5% of businesses going deep into JavaScript on our enterprise software, but we still feel we can go further — especially in the fields of quality assurance and scaling.

Lo and behold, we give you;

Monday School Notes from JavaScript session #1

Table of Content

We have decided to divide the subject of JavaScript into the following sections:

• Development Tools
• Coding standard
• Guidelines
• Frameworks, or the lack thereof (when to use what)
• Testing
• Debugging
• Patterns
• Document Object Model (DOM)
• Productivity tips
• Compatibility issues
• Recommended reading/watching

We’ll be covering these topics in the weeks to come, and we well be returning with links on the TOC. If you will join us in this, please follow this blog on RSS or follow the company or the author on twitter. If you digg it, then digg it.

With Query Cache, the result set from SELECT queries are cached with the query command itself as key. Meaning that if a SELECT query initially executes in ten seconds, consecutive times the _exact_ (including whitespace, case and more. The query must be an identical string.) same query is executed, the server gets an hit in Query Cache and returns the cached data in milliseconds, normally giving performance boosts between a few and many orders of magnitude. QC is a global server setting and has three modes; ON, OFF and DEMAND. Setting QC to OFF disables it, with it to ON makes the server look for a cached result for all SELECT queries while setting it to DEMAND will have the server only do a QC lookup if the query has SQL_CACHE after the SELECT command. It’s recommended to put this MySQL-only extension in a comment to keep with compatibility with SQL standards. (SELECT /*SQL_CACHE*/ * FROM brille) A QC miss will add up to about 20% overhead compared to the same query executed directly without QC lookup. QC is guaranteed to deliver fresh data as all QC on a table is invalidated when a INSERT, DELETE or UPDATE command is executed on it. This means that for a table with frequent writes, QC on reads will probably decrease performance. On tables with a high number of both reads and writes, setting QC to DEMAND and not use it on queries hitting that table might be a good idea. When actively using query cache on tables with dates it’s also important to write reusable and cacheable queries. Any use of NOW() or equivalent non-deterministic functions will render query cache unused even within the same second, so date and time should be calculated outside of MySQL. When doing so, first analyze the need for an exact query. If you can get away with < 1 minute accuracy, don’t add date( ‘Y-m-d H:i:s’ ) but date( ‘Y-m-d H:i:00′ ) so any identical queries within the same minute will get the cached result. Subselects will not use QC. On high performance applications, QC should be kept in mind when designing the database and queries. Below are two examples where performance characteristics could be radically different:

First table structure:

CREATE TABLE `users` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`username` varchar(16) collate utf8_danish_ci NOT NULL,
`password` text collate utf8_danish_ci NOT NULL,
`salt` text collate utf8_danish_ci NOT NULL,
`last_time_visited` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY  (`id`),
UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_danish_ci;

Second table structure:

CREATE TABLE `users` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`username` varchar(16) collate utf8_danish_ci NOT NULL,
`password` text collate utf8_danish_ci NOT NULL,
`salt` text collate utf8_danish_ci NOT NULL,
PRIMARY KEY  (`id`),
UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_danish_ci;
CREATE TABLE `user_visited` (
`id` int(10) UNSIGNED NOT NULL,
`last_time_visited` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY  (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_danish_ci;

If the first table was used on a high traffic forum, every time a user loads a page the QC would be invalidated as last_time_visited had to be updated. By denormalization and having two tables where one is often read and the other is often written to, QC on the first table would be kept until a user changed password/username or a new user is registered which is probably less frequent than pageloads.

But the way the SELECT query is created is also important. Lets say you normaly just need the basic information about a user, but every time you visit the users profile, last_time_visited is needed:

First set of queries:
Normal display of user:

SELECT /*SQL_CACHE*/ id, username FROM users WHERE id = 1;

Display of users profile:

SELECT /*SQL_CACHE*/ u.id, u.username, uv.last_time_visited FROM users AS u LEFT JOIN user_visited AS uv ON ( u.id = uv.id ) WHERE u.id = 1;

Second set of queries:
Normal display of user:

SELECT /*SQL_CACHE*/ id, username FROM users WHERE id = 1;

Display of users profile:

SELECT /*SQL_CACHE*/ id, username FROM users WHERE id = 1;
SELECT last_time_visited FROM user_visited WHERE id = 1;

In the first set, two different queries are used to fetch the same information, the username. This means the second query won’t be able to use the QC of the first and more frequent query. Also, the often-read table is joined with the often-written which means INSERT, DELETE and UPDATE queries on _both_ tables will clear cache for this query. In the second set of queries, the same query is used two times, increasing the chance of QC hit. And instead of joining the two tables in one query, a second and separate query is executed on the second table, here without the SQL_CACHE keyword. Two queries increases overhead, but the gain in higher cache hit (The first query can even get a hit in a Memcache-lookup) can easily outweigh this.

Disadvantages of Pair Programming

Don’t four hands produce more code than two?

If you are a carpenter, you can hit more nails with four hands than with two. If you are a brick-layer you can lay more bricks with four hands than with two. If you are a developer you can write more production code with four hands than with two. Or wait. This is based on the assumption that the bottleneck in software development is a mechanical one ; the speed of which you can type on the keyboard. My 10 years as a developer and 5 years as a program manager tells me otherwise. The bottlenecks in somewhat innovative projects (non-repetitive) rarely or never include typing speed. Bottlenecks do include hesitation (doubting your own solution), introducing bugs and having to go back to fix it, suboptimal design that deserves a refactoring, lack of needed knowledge for the task, loss of focus and so on.

A small disclaimer before I go on : We have not been experimenting with Pair Programming for more than a few months, and my above observations are based on observing teams develop from a managerial point of view and from reflecting upon my own coding habits as a team member.

Benefits of Pair Programming

Amplify learning

The speed of learning in pair programming is overwhelming. Once you enter a topic one party has more experience in, you are in for a ride. I have never experienced learning at such a pace as when this occurs.

Prevent bugs

Bugs are cheapest when they are prevented  from being introduced with measures that does not put restraints on your risk-taking and innovation. Pairing keeps you innovating, and will still help you spot errors more frequently. You will be more critical of your own code, and you will have someone constantly looking for possible improvements in your code, such as stopping a bug in the making, or having an idea for an even better test.

Continuous improvement

Pair programming is a dialogue between two people trying to simultaneously program, and understand how to program better.

Articulating ideas

Pair programming forces you to put words to your thoughts. This will through constant practice improve your skills in articulating your ideas.

Share frustrations

The responsibility on one single programmer can be huge at times. It is relieving to carry the load together. A teams strength and robustness is greater than the sum of strengths.

Avoid hesitation

When exhausted for ideas or new angles, it can lead to hesitation to implement what you suspect is a sub-optimal solution. The union of ideas and angles between the two developers makes this a rarer incident, and the resulting discussions will usually help remove the knots causing hesitation.

Distributed resources

From a managers point of view, a migration of people between project modules, and even between projects, becomes vastly easier. This is a dream come true. Nobody is the sole “owner” of code anymore, and developers can move more freely between code sections and projects, simplifying the complex task of resource scheduling. Starting out on unfamiliar code means that you should be pair programming with someone with a lot of domain knowledge in the start.

How to do pair programming

Pair programming is two people using one keyboard to write code. Here are some important best-practices to go along with that description.

1. Choose a suitable partner for pair programming the given task during the daily scrum.
2. Sit side by side with only one keyboard and one mouse. Both should have a good view of the monitor.
3. It must be easy to slide the keyboard from person to person. Switch roles from typer to observer every so often.
4. Discuss and have a good time.

So, these are my reflections on the subject so far. I will be sure to update you (RSS) on any changes of opiniton as we continue to improve our development practices.

We’d like to share with you what we believe have proven to bring us from encoding hell and into UTF-8-heaven. (Writing this makes me feel like the first day of an AA-meeting; “Yes, I have had problems with encoding”. Please be welcomed to Encoders Anonymous).

Can all your applications send, receive, process and display this?

بما في ذلك الكلمات المستخدمة في صفحات التيكت والويكي.

Or this?
繁體中文, 許功蓋會育

Or even this?
Българският език работи ли

Yes? Well, then you don’t have much of a problem with Iñtërnâtiônàlizætiøn, do you? Having such ingenious programming skills you can now move on to other endeavours. I bid you adieu. The rest of us will pick at this very one in the meantime.

The Mother Of All UTF-8 Checklists.

We have come to realize that we should maintain such a list, and you are now being presented with the current state of it. I’ll present a section for each and every layer of our application technologies (LAMP).

Operating system

Use a proper operating system for server purposes. *nix, except-OS X (1) that is.

Mysql

Sadly enough, mysql ships with a “latin1″ default encoding set up. This is a no-go in the “Defaults Matter”-department, and more a sad realization to the state of encoding, than a visionary attempt to try to change things for the better. Sharpen up, mysql, don’t go all Microsoft on us, here.

Check your mysql status and configuration with :

mysql> status;
 Server characterset:	latin1 # se my.cnf changes below to fix
 Db     characterset:	utf8   # all well and good
 Client characterset:	latin1 # to fix : SET NAMES utf8
 Conn.  characterset:	latin1 # same as above
 
mysql> show variables;
 character_set_client            | utf8
 character_set_connection        | utf8
 character_set_database          | utf8
 character_set_filesystem        | binary
 character_set_results           | utf8
 character_set_server            | utf8
 character_set_system            | utf8

There are four levels on which you can determine character set type in mysql, and if able, you should start at the top, the server-level.

Add these options to my.cnf :

[mysqld]
character-set-server = utf8
collation-server = utf8_generic_ci
 
[client]
default-character-set = utf8

If you have no access to change the server config, you can have a go at the lower levels, the next one being the database. If you were unable to change the server config, use these types of statements for creating databases.

CREATE DATABASE $db CHARACTER SET utf8 COLLATE utf8_generic_ci;

If you already have a database up and running, you have to drop it and recreate it to change to UTF-8. If this is not an option, all is still not lost. You can have a go at lower levels as well.

Table and column-level (use in this order) :

ALTER TABLE $table COLLATE utf8_generic_ci;
ALTER TABLE $table CHANGE `$field_name` `$field_name` $field_type
  CHARACTER SET utf8 COLLATE utf8_generic_ci;
ALTER TABLE {$table} CONVERT TO CHARACTER SET utf8 COLLATE utf8_generic_ci

The collation attribute is used for mysql to know how to sort the characters in relation to one another, and not for encoding specifically. A small warning should be issued here, as well. You never know if convert statements, as the one above, will translate everything correctly. Use with caution on production sensitive data.

This is how you’ll find out what your system is currently running on table level

SELECT table_name FROM information_schema.TABLES
   WHERE TABLE_COLLATION IS NOT NULL AND table_schema = '$db'
   AND TABLE_COLLATION NOT LIKE 'utf8%'

And this is how you’ll find out on column level

SELECT COLUMN_NAME, COLUMN_TYPE FROM information_schema.COLUMNS
   WHERE CHARACTER_SET_NAME IS NOT NULL
   AND TABLE_SCHEMA = '{$db}' AND TABLE_NAME = '$table_name'
   AND ( CHARACTER_SET_NAME != 'utf8' OR COLLATION_NAME NOT LIKE 'utf8%' )

This might seem like a lot of detail just for encoding issues (2), and only on the level of the database. Well, it is. However, being suckers for automation, we have automated these procedures in setup-tests for our in-house framework.

PHP

For starters, let’s not have all our efforts recently made in mysql be in vain. Let’s speak to mysql in the same international way.

mysql_query('SET NAMES utf8'); // When in Rome ..

And we should be sure it’s transported the right way from there on out to the browser.

header("Content-Type: text/html;charset=UTF-8");

You’ll even have to modify php-defaults to get things running smoothly (as we’ve already discussed). This is done by setting the mbstring.func_overload value to 7.

NB: You should not have to use utf8_decode() and utf8_encode(), if the data is properly encoded as UTF-8 everywhere else. If you find yourself using those functions, you are in hell. Run through every step of this checklist to avoid future complexity. (3)

HTML

Insert this in your head-sections to ensure that it is rendered correctly in the user’s web-browser.

Apache

In your .htaccess or apache-config, set these values to ensure that all Javascript and CSS files are served as UTF-8.

AddCharset UTF-8 .js
AddCharset UTF-8 .css

Editor

You are presumably writing code, and this should also be UTF-8. Ensure that your editor is all set up for saving files that way.

Conclusion

Go through the checklist as provided, and you should be all set to conquer the world with your applications. Now, all you do is sit tight and hope that all this adds up to something. God speed.

Please provide feedback if any of our advice does not bring you to where you want to be, or if by any chance your application implodes when doing these measures.

We have a policy of automating and making defaults of all such issues as those mentioned here, and we’ll surely keep adding more defaults to our framework as challenges emerge.

Have you got any sad or perhaps even inspiring stories on the path to UTF-8-excellence?

Notes

For background purposes, it can be nice to know that most of our encoding challenges has existed only in legacy applications. Some of our systems has been developed for Norwegian purposes, and then upgraded for international use. If you start a new project today, and follow the steps above, you should not run into any problems.

1. OS X is excluded because even if you might think that UTF-8 is UTF-8, there are different versions being used. You got UTF-8 NFD form used by OS X and UTF-8 NFC form used by almost everyone else. A file created on OS X named pål.txt and transfered over e.g. FTP to a GNU/Linux system won’t have its name listed the same way there before a run through convmv. http://unicode.org/reports/tr15/
2. This is another whacky way of converting your database:

   mysqldump -u  -p  > dump.sql
   sed -r 's/latin1/utf8/g' dump.sql > utf8.sql
   iconv -f iso-8859-1 -t UTF-8//TRANSLIT utf8.sql > dump.utf8.sql
   create database  default character set utf8 collate utf8_general_ci;
   (rm utf8.sql dump.sql)

3. If you are receiving non-UTF-8 data from external data-providers which encodes in other encodings than UTF-8, you might find that you’ll benefit from utf8_encode(), but I’d recommend that you use it only once, and at once you touch those data.

Figuring out how to solve this problem in a standardised way posed some problems, so various software vendors went with their own solutions to begin with.

Laying the Foundations

Before dwelling deeper into the solutions created it is important to define the terminology that I will use (as it differs between various sources). Some basic knowledge about how encoding works will also be supplied to create the basis for the rest of this blog entry.

A character set, or more specifically, a coded character set is a set of character symbols, each of which has a unique numerical ID, which is called the character’s code point. The computer representation of the code points is decided by the character encoding.

An example of a character set is the 128-character ASCII character set which mainly consist of the letters, numbers and basic punctuation used in the English language. Another common character set is the ISO-8859-1, or Latin 1, character set which extended the ASCII set to also contain extra characters used in various European languages (e.g the accented characters used in French). The most comprehensive character set in use today is the Universal Character Set (UCS) with over 1.1 million code points, as such it contains all characters our current languages need.

Every HTML document uses the UCS – or more accurately the ISO 10646 character set, which is a less involved standard describing the same set of characters. Older browsers and less powerful devices might not support the complete character set, but that doesn’t change the fact a HTML
document can contain any character found in the UCS.

However, between each document the character encoding might change. It is the variable character encodings which is the root of all the problems web developers experience in regards to erroneous character display. The problems are often caused by a missing definition of the encoding used on the page (which causes the browser to guess), or usage of different encodings for various parts of the page.

The Problem

As the web evolved the standard usage of the ISO-8859-1 encoding started to show some problems. People wanted to use characters not supported.

The first solution to this was to use character entities, or character numerical references. Instead of typing the literal character you would type something like &mdash; (—) or &#x05d0;(א). The problem with this approach was when submitting data through a form. If the user typed an א the browser would convert it to the numerical reference (&#x05d0;) before submitting the data, since the encoding didn’t have proper support for the character. But then the application had no way of differentiating between a user who typed the א-character and one who typed the entity code.

The Solution

The solution found for this problem was to start using the UTF-8 character set. UTF-8 is an extension of the old ASCII encoding and it has support for all kinds of characters, so the encoding never needs to use entities to display information. The application has full control over the kind of information it receives, and the users has access to all characters they need.

UTF-8 manages to support this wide range of characters by using more than one byte of storage for those characters that require it. Most characters used on an English page will still only use one byte (as ISO does), but when using characters that doesn’t fit into that small amount it expands by using up to four bytes in total for a single character. There are other UTF encodings available as well. They have a base usage of two (UTF-16) or four bytes(UTF-32), but are not compatible with the ASCII standard so they should not be used unless strictly necessary.

In Code We Trust

Creating a UTF-8 application in PHP isn’t without problems though. Converting an old non-UTF application is even more error prone as PHP has no good and error-free tool for conversion between the various encodings, as I cover at the end of this entry.

The first step in making a web application use UTF-8 is to tell the browser which encoding to expect and thereby how it should encode data submitted through forms. This is done by either using a <meta> tag in the page’s <head>-section:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

Or by defining the Content-Type in the header:

<?php header("Content-Type: text/html;charset=UTF-8"); ?>

The header sent will always override the meta tag, so to be on the safe side you should always send an appropriate header. If you forget it a default header might be sent from Apache which can be different from your desired header. To be on the safe side doing both is advisable, though the <meta> tag will only be used when the content is viewed offline. When the browser knows that content is being sent as UTF-8 it will automatically send content back using the same encoding, so that part doesn’t require any extra work.

Once that is done the biggest problem when creating a UTF-8 application remains. Most of the string related functions in PHP (e.g strlen) doesn’t work any more. Those functions assumes that each character in a string is encoded using ISO-8859 and takes exactly one byte of storage. When characters in a UTF-8 string uses more than one byte the calculations return the wrong result. An example is strlen("Iñtërnâtiônàlizætiøn") which would return 27. From manually counting we see that the result is off by 7. The difference comes from the 7 characters that need two bytes to be stored using UTF-8.

If you’re aware of this problem to begin with you can avoid many of the problems by coding around the use of these functions. It is possible to do so, but requires extra work and attention from the programmer. Luckily PHP supplies us with a more elegant solution – the mbstring extension.

The mbstring extension supplies PHP with multi byte versions of the standard string functions, e.g mb_strlen which is an extension of the standard strlen function. So prefixing the previously erroneous string functions with mb_ should solve most of those problems encountered.

A more elegant solution exists though, you can override the standard function names to invoke the multi byte versions. This is done by setting the mbstring.func_overload value to 7 in php.ini. The mbstring.func_overload can be set to other values as well if you only want to overload a subset of the string functions.

The encoding must also be set in the text editor and in any databases used. Most modern code editors have this option, so as long as one is aware of the problem it should not be any problem to fix it. Setting the encoding on the database level is usually no problem, but the approach varies between the different systems.

Legacy Code

All is well and nice when we’re creating a new application. We can start storing and handling text as UTF-8 from the very beginning. But what if we have and old application that now needs to support foreign characters?

Unfortunately there is no easy solution for this. If all your previous content is in English it should be safe to simply add the appropriate headers, since the basic characters are the same in all common encodings.

Conversion of characters not commonly used in English is trickier. PHP’s iconv library can be used for most conversions, but there is no guarantee that the converted content is completely correct. On forums and mailing lists you can also find a lot of hand crafted functions for conversion between various encodings – which might, or might not, work. In the end the only fool proof way to convert content is to rewrite the required sections by hand, or at least double check the changes done by an automated process like iconv.

Further reading, and sources used from this entry:

• A tutorial on character code issues
• Internationalization (I18N)

home.php:

session_start();
...
$url = "http://url/admin.php?PHPSESSID=".session_id();
$fp = fopen($url, 'r');
$content = fread($fp); // will hang here!
...

The problem lies in the fact that PHP opens the session file in a exclusive mode, which denies other threads to open the same file. In another words, admin.php will wait for home.php to release the lock on the session file and this will eventually lead to a timeout for the request. But fortunately there is a solution. To solve this you must close the session file before making the request.

home.php:

session_start();
...
session_write_close(); // close the session file so admin.php can access it
$url = "http://url/admin.php?PHPSESSID=".session_id();
$fp = fopen($url, 'r');
$content = fread($fp);
session_start(); // start the session again
...

I hope this will save you some headache!

Consider the following example:

<a id="mylink" href="#">Click me, please!</a>

function myFunction() {
	updateStatusMessage('Working..');
	someCpuIntensiveCode();
	updateStatusMessage('Done!');
}
 
$('mylink').observe('click', myFunction);

The function updateStatusMessage() is suppose to update an element on the page as soon as the user clicks on the link, which will indicate that something is happening. But since your javascript code compete with the UI-thread, the browser probably doesn’t do the update until the function has finished. The solution is to delay the code that prevents the browser to update using the function setTimeout() and give the browser a chance to refresh the UI before the cpu intensive code executes.

Here’s the trick:

function myFunction() {
	updateStatusMessage('Working..');
	setTimeout(function() {
		someCpuIntensiveCode();
		updateStatusMessage('Done!');
	}, 10);
}

You may have to tweak the timeout in order to see any effect.

Now wrap it up so we can reuse the code for other operations too:

function heavyFunction(func, timeout) {
	timeout = timeout || 10;
	updateStatusMessage('Working..');
	setTimeout(function() {
		func();
		updateStatusMessage('Done!');
	}, timeout);
}
 
function myFunction() {
	heavyFunction(someCpuIntensiveCode);
}
 
function myOtherFunction() {
	heavyFunction(function() {
		moreCPUIntensiveCode(arg1, arg2);
	});
}

Click here for a working example!

For more information about this topic, take a look at the excellent screencast High-performance JavaScript: Why Everything You’ve Been Taught Is Wrong which gave me some light in the dark.