Skip to content

Entries tagged "javascript".

Slow Dojo initialisation

If you rely only on data passed by AJAX for page rendering your content will be invisible to search engines. That's it. According to this article preferred method to use AJAX is to start with classic refresh-per-click model that is visible to search engines then add Ajax scripting when applicable. This week I have such situation when pure AJAX app was refactored for Google purposes. I discovered that initialisation of Dojo (that takes 3 seconds and above ten AJAX calls for *.js files) isn't very good thing if occurs every click. Didn't Dojo play well with apps that refresh page every request? I found few interesting hints how this problem can be addressed and prepared custom Dojo build. It's working well and now initialisation of Dojo takes under one second (and it's acceptable now for end-user).

JSlint to help AJAX programming

Do you remember E_ALL setting in PHP? Or "use strict;" in Perl? Or strong declarations of function arguments in ANSI C? All those attempts are aimed at minimize probability of mistake during software development. By using stricter language simple programming errors could be easily detected during compilation (C) or during execution (interpreted languages). Java Script plays important role in web-based applications. It's the primary implementation tool for rich GUIs based on browsers (AJAX). Due to it's dynamic nature it accept broad range of programming constructs (including using of uninitialised variable). So it's not very safe to build large systems based on Java Script. JSLint will help you with elimination from Java Script errant constructs by defining strict subset of Java Script: JSLint defines a professional subset of JavaScript, a stricter language than that defined by Third Edition of the ECMAScript Programming Language Standard. The subset is related to recommendations found in Code Conventions for the JavaScript Programming Language. JSLint is written in JavaScript so it requires Java Script interpreter to run. Luckily we have Spidermonkey that is Mozilla's Java Script implementation written in C language. This implmentation is fast (at least with comparision to Rhino) and stable. The only problem is that Spidermonkey doesn't allow IO operations by default (for security reasons). I found an altered JSLint implementation suited for SpiderMonkey, but found it to hang up. The problem was with end-of-file detection algorithm:
while (blankcount < 10){

    if (line=="")
    if (line=="END") break;
        input += line;
        input += "\n";
I fixed it by checking for null instead of "":
while (true) {

    if (line == null)

    input += line;
    input += "\n";
And now it's working perfectly. Here's modified version. Enjoy!

AJAX programming IDE ;-)

QUnit - Unit Testing made easy for JavaScript

Are you test-infected? Learned already how to grow your server-side apps using unit testing and want to do the same with client (HTML) layer? Search no more! QUnit to the rescue!


QUnit is a JavaScript library that helps you with tests specification, run and diagnostics. Firstly, you have to include qunit library and your tests in an html file: <html> <head> <link rel="stylesheet" href="/resources/qunit.css"> </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="/resources/qunit.js"></script> <script src="/resources/tests.js"></script> </body> </html> Then you can start writing your tests, the simplest one, taken from documentation:

test( "hello test", function() { ok( 1 == "1", "Passed!" ); });
As you can see:
  • syntax for new tests definition is very minimal, just test(name, function)
  • qunit is shipped with basic assert like functions: ok(), equal(), ...
  • order of predicate and message is better than in JUnit :-)
The next step in QUnit knowledge is to master asynchronous tests. I've seen many nonsense "sleep()" function implementations (hogging CPU power for a loop), properly used setTimeout() is the answer here. asyncTest() helps you with creating such tests that are time-related, an example:
asyncTest("zapChannel() basic test", function() {
    equal(MediaPlayer.zapChannel(2), 0, "0 code means operation succeded")
    // Check after 2s if there's confirmation signal of stream visibility
    setTimeout(function () {
        console.log("zapChannel() - check proper event presence")
        var ev = MediaPlayer.getEvent()
        ok(ev, "event data set")
    }, 2000)
I've bolded important parts:
  • asyncTests() starts test that will include asycnhronous parts
  • setTimeout() the corrent way for sleep() implementation
  • start() tells QUnit to continue, without that test won't finish properly
As you can see if there's an exception inside getEvent() call the start() call won't be called at all. So I've prepared a wrapper for setTimeout() that allows to finish the test and continue properly to the end of test suite:
function delayTest(fn, milliseconds) {
    setTimeout(function () {
        try {
        catch (e) {
            msg = e + ": " + e.stack
            ok(0, msg)
    }, milliseconds)
If you use above call instead of setTimeout() your test suite will terminate properly even for exception inside tested method. And last, but not least: if you want to use ok() call in production code when qunit is not deployed you can use the following workaround:
/* allow ok() assertions even if qunit is not loaded */
if (!isFunction(ok)) {
    function ok(condition, msg) {
        if (!condition) {
Have a great TDD JavaScript development in new 2014!