Category Archives: Client-side

About JavaScript workers and webwork.js

Following the recent publication of theĀ webwork.js library by @kolodny, I felt curious about the relative performance of web workers compared to regular sequential JavaScript. With this code snippet you can try by yourself – just inject the JS library in your web app:

?View Code JAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
var now = 0;
var testLength = 1000000;
var batches = 10;
var fooArray = [];
var i = 0;
var j = 0;
 
var worker = webwork(function(data){
var fooArray = [];
var testLength = data[0];
var batches = data[1];
 
for (j=0; j<testLength/batches; j++){
fooArray.push(j);
}
 
return fooArray;
});
 
// First test, good-old sequential JavaScript
now = new Date().getTime();
for (i=0; i<testLength; i++){
fooArray[i] = i;
}
console.log('It took %@ milliseconds to run without web workers'.fmt((new Date().getTime()) - now))
 
// second test, paralelized with web workers
now = new Date().getTime();
fooArray = [];
for (i = 0; i < batches; i++) {
worker([testLength, batches], function (err, result) {
if (err) return console.log("goodWorker Errored with " + err.message);
fooArray = fooArray.concat(result);
 
if (fooArray.length == testLength) {
console.log('It took %@ milliseconds to run with web workers'.fmt((new Date().getTime()) - now));
}
});
}

The results, splitting a batch of one million array inserts into ten parallel workers, is quite amazing:

It took 1039 milliseconds to run without web workers
It took 391 milliseconds to run with web workers

So in this simple example, using web workers increased processing speed around three times. Yet another reason to consider them in heavyweight client-side processing tasks!

Comodoro, a Task & Project Manager for Micro-Companies

I am proudly announcing Comodoro Alpha 0.1.0, a task and project manager meant to simplify work management in micro-companies (start-up’s, freelancers, individuals…).

Comodoro lets you take full control of your work in progress, by providing a detailed insight of your ongoing tasks and increasing your awareness of the status and health of your projects. All from a single interface, at a glance.

It is a mash-up of several Agile methodologies and strongly inspired on the Visual Management principles. It brings Project Management to multi-micro-project environments where many things happen in parallel and resources are limited.

Check it out, it is open and free to use: www.comodoroapp.com!

Internet Explorer limits nested @import CSS statements

I have been lately working on a collection of home-made widgets based on Dojo. This architecture has been designed to reuse elements and so there are widgets inside widgets, the code is arranged and structured, CSS is imported in a waterfall model, and everything should be fine and working properly.

Until Internet Explorer.

Let’s not talk about its mystic JavaScript errors, DOM random model interpretations and box model hacks. I had heard about the 32 @import CSS statements limit before (here, here and here), but what we were experiencing was different: beyond a given number of nested CSS imports, it seemed like stylesheets stopped being loaded. This was a big WTF the first time we spotted the problem, and blindly fixed it by adding twice the deeper @import sentences into the higher level CSS files. After all, it worked then.

But after a bad night of guilty conscience that issue came back to me, and I decided to do some tests on the issue so that some light be thrown on this dark matter. This was the plan: a simple HTML file with a number of divs (with a border and height definitions to make them visible by default), and a set of CSS files that where imported in waterfall mode, each one of them assigning the background color of one div according to its nesting level. The rupture point would be spotted where div’s started to look blank. Something like this:

Continue reading Internet Explorer limits nested @import CSS statements

Workaround to dynamically load CSS resources

I have been struggling for a while to find a way to dynamically load CSS resources in a coherent and reliable manner. As I am working with dojo on my current project, I started with using its event connectors for a classical approach: creating a DOM link element with the desired CSS resource and adding it to the document’s header programmatically.

?View Code JAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function getCSS(filename){
  var fileref = document.createElement('script');
 
  fileref.setAttribute("type", "text/javascript");
  fileref.setAttribute("src", filename);
 
  var handleLoad = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' loaded');				
    dojo.disconnect(handleLoad);		
  });
 
  var handleError = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' failed loading');				
    dojo.disconnect(handleError);		
  });
}

Continue reading Workaround to dynamically load CSS resources

Why iframes in rich web applications are evil

I write this post claiming to heavens that you (as a web developer figuring out whether to use or not iframes) will read and follow my advice. Not only for me, nor for you, but for a better world.

Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.

And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app:

Continue reading Why iframes in rich web applications are evil