Jorge Albaladejo

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:

Read the rest of this entry »

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.

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);		
  });
}

Read the rest of this entry »

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:

Read the rest of this entry »

As a web developer, I am normally more into the back-end stuff: PHP, MVC, performance, page generation time, queries optimization and such stuff. However, it is a good idea not to forget the big picture (which is something that I tend to, by the way): server-side performance and stability are critical, but the client-side interface (JS, DOM Events, etc) plays also a significant part when talking about loading time, server load and overall performance.

In these times where cloud computing has settled and means to stay, it is very likely that our web interface is going to use several toolkits, libraries, widgets, plugins from different frameworks (such as jQuery, Dojo, Mootools), which, if used out of a coherent system, will produce a lot of server calls to download the related resources. Not only this adds up to server load, but it also can increase total load time by several magnitudes, which, in turn, makes the user feel that the entire web application is slow and crappy.

Just a few details we should never forget when optimizing our web interfaces to avoid the effect above (and this goes more as a self-reminder than as a hint):

• Use the right headers so that your image, CSS and JS files are kept in browser’s cache.
• Make sure that gzip compression is active on the server.
• Minify the JS/CSS files before putting them in a production environment.
• Use sprites for GUI pictures.
• Use a dynamic loader that grabs the related resources on-demand and asynchronously.
• Combine JS/CSS files into modules.

There are, of course, many more things you can do to ensure that your application runs smoothly, but the ones above are relatively easy to apply, and produce results in the middle / short term.

Any suggestions? Comments are welcome.