Well, call me pedantic for even discussing this and seeing this as relevant. But everybody knows that adhering coding styles make programming in a team way more pleasant and it is just way more efficient to just code and not to style! Which includes not having to think about how to style the code, though I realize that a lot of programmers have a problem adapting to coding styles.
We at uxebu basically defined that we are applying the coding guide lines of the project that we possibly contribute stuff back to. This means our JavaScript code applies the dojo coding style guide and our python stuff (we use internally) applies the django coding style guide.

But let’s look at the for-loop now.

The default

The most common usage of a for loop is the following.

1
2
3
4

for (var i=0; i<nodes.length; i++){
    var node = nodes[i];
    // whatever
}

Nothing spectacular here. But let’s take it apart a bit. There are two things that are commonly known that can be optimized.

1. The comparison “i<nodes.length” in line 1 evaluates the length of nodes on every iteration, if the nodes array is not modified while looping over it or the change to it is not relevant, this can be optimized.
2. Also the declaration of the variable “node” in line 2 is done multiple times, so this is just a small unnecessary thing to do.

So let’s optimize the things we just found out.

Version 2

1
2
3
4
5
6

var node;
var len=nodes.length;
for (var i=0; i<len; i++){
    node = nodes[i];
    // whatever
}

Another step on our way was to optimize the variable declarations and reducing their count from three down to one. In some code you can then see the following.

Version 3

1
2
3
4
5

var node, i=0, len=nodes.length;
for (; i<len; i++){
    node = nodes[i];
    // whatever
}

Actually we have already skipped a tiny step in between, very often you can see multiple var-statements as opposed to the already “squeezed” one-liner in line 1 above. The way of writing it as seen here, is reasonable if there are a couple other variables to be declared, you just need one var-statement. This will basically reduce the code size, if your minifier doesn’t already do that for you. As stated here it seems to be specified to be irrelevant to performance. So event the argument under 2. against the first version (see above) is not very strong.
Just a small side-note: the one line var-statement evaluates in declaration order, so something like this will work!

var arr = [1,2,3], len = arr.length, x = len-1;

The “len” and also “x” variables contain the proper content as you are expecting. The comma-separated var-statement evaluates the assignment expression by expression and steps on to the next assignment. Therefore “len” and “x” will have the proper values 3 and 2.
But let’s go back to our for-loop.

Version 4

If the var-statement is outside the for-loop and especially if other variables (outside of the scope of the for-loop) are declared there the source code get’s blury and harder to read. For example:

var someVar = whatever, anotherVar = [1,4,5], node, i=0, len=nodes.length;

The first two variable declarations (someVar and anotherVar) have nothing to do with the for-loop context, but the others do, so this blurs the source code and is prone to errors. Also if you separate this source code onto multiple lines like so:

var someVar = whatever, anotherVar = [1,4,5],
    node, i=0, len=nodes.length;

it is still a possible point of failure. I for example, forgot the comma on line 1 which made this source code

var someVar = whatever, anotherVar = [1,4,5]
    node, i=0, len=nodes.length;

still work. But and this is a big but, the code get’s a different meaning now! First, line 1 will work, since the semicolon at the end of the line is not mandatory. And second (if not declared inside this scope before) the variables on line 2 are now defined in global scope. And that can really cause a hard to find bug!
Another good reason for not doing this, is that extending the code may lead to developers adding code in between the var-declaration and the for-loop, for whatever reason. Then the variable declarations for the for-loop “drift away” and loose their context even a bit more. And the source code becomes harder to understand.

So we rather put all the variable declarations into the for-loop’s var-statement. Like so:

1
2
3
4
5

var someVar = whatever, anotherVar = [1,4,5]; // This is outside the for-loop and also looks like it.
for (var i=0, len=nodes.length, node; i<len; i++){
    node = nodes[i];
    // whatever
}

Now we have a pretty compact and well context-focused syntax for declaring variables needed within a for-loop. This code is nicely readable and has no impact on performance, even if in most cases good and maintainable code is worth more than the fastest code, but that’s a use case based decision! We are taking this as a standard for uxebu code.

What do you think? Let us know if you see potential for optimization.

dojo.beer(2)

In the evening of 5th December we’ve had our start for the dojo.beer(2) event in a nice bar in Munich, where about 10 Dojo enthusiasts attended to prepare for the official event the next day. During the evening Wolfram placed the bet, that more than 30 people will attend during the official dojo.beer(2) event. I lost that bet, because 32 people attended and I was really excited (still am), that so many people were interested in Dojo.

The next day we welcomed all attendees with a typical Bavarian Weisswurst. After the first meet and greet Wolfram collected Dojo topics people could talk about and everyone voted on those, followed by Nikolai, who gave a great overview of the most important Dojo components.
Then it was time for our special guests Dylan Schiemann and Pete Higgins who joined us via video chat and we talked about the current status of Dojo (just before that moment Dojo Version 1.2.3 was released) and what is planned for the future. Afterwards it was my job to explain the Dojo build system and how you can optimize a Dojo driven website (slides below). My talk was followed by Wolfram, who explained several Dojo features and later dived into the functional programming capabilities of Dojo (for further info, see the post of Shane O’Sullivan and for deeper insight a blog entry by Eugene Latzutkin). Nikolai then introduced Dojos new user documentation and gave a short preview of the new Dojo website. The last lecture was given by Norman Wenk (acomo), who demonstrated the Dojo widget system and explained the pitfalls, when creating your own. After a full day of Dojoness we went to a bar and ended with several dojo.beer(s).

dojo.beer(2) from Tobias von Klipstein on Vimeo.

Thanks to everyone who attended this event and I hope everyone enjoined it. I would particularly like to thank Mayflower who donated their office for that event and also like to note, that we wouldn’t had this amazing event without their support. Many Many Thanks!!!

More info about that event:

http://search.twitter.com/search?q=dojo.beer
http://your-bear.blogspot.com/2008/12/djbeer-in-munich.html
http://blog.thinkphp.de/archives/375-dojo.beer2.html
http://higginsforpresident.net/2008/12/back-in-business/

Webmontag Munich

On Monday, 8th December 2008, Wolfram and I went to the Webmontag event in Munich where Mihai Corlan, Platform Evangelist of Adobe, gave a good insight into technologies like Flex, Air and Zend AMF. Afterwards I’ve got the possibility to give an overview of Dojo, where I showed how Dojo evolved during the last year. At the end I showed some videos about Wavemaker, IBM’s Project Zero and the nice training application of Sitepen called Sensei to give an impression what you can reach with the Dojo Toolkit today.

I really enjoyed the round-table discussion about open source, the open web and how companies like Adobe fit in. Thanks to the Munich PHP-UG, Flex-UG and of course Raju Bitter, who altogether organized this nice event.

A Sidenote:

Mihai showed some interesting slides about a comparison James Ward made with his Census application. He shows the speed improvements of AMF in favour of JSON communication when transferring 5000 rows and more. This is a very special use case, I rather see the latest usability and interaction patterns stearing into the direction of loading just the data on demand that are really required. In most cases this big number of data is also hard for users to grasp. There is charting and some visual presentations that might require this load of data, but the optimization on the server will probably serve a better user experience here. An interesting read is Jared Jurkiewicz blog article about comparing these numbers with Dojo today, as the comparison of James Ward was made in April 2007.

Besides holding talks, which occupies at least most of my brain time until I am done, we are really looking forward to getting to know better the AJAX Community here in Germany and we hope for a lot of input and to share ideas with like minded people. If there will be so much brain capital as there was in Boston for the Ajax Experience two weeks ago, we will need at least the rest of the year to digest it all. But hey, that is what we are out for. We want your input and we want to give input.

May be we will even try to have a gathering of some of the most interesting and most interested AJAX people that are coming to the conference in order to shoot a dojo.cast(), may be some kind of “conference edition”. Actually, that is just an idea I made up right this second while writing this, but I guess Nikolai and Pete won’t be too opposed to it.

Feel free to mail us or drop a comment if you like to meet up – no matter if dojo, ajax, javascript or whatever related.

Uxebu is the company of the three web enthusistasts: Nikolai Onken (from Amsterdam, Holland), Tobias von Klipstein (Augsburg, Germany) and Wolfram Kriesing (Munich, Germany). We are specialized in providing you with knowledge and support for JavaScript and CSS tasks. For our customers we offer lessons about client side web development (AJAX, JavaScript, CSS, …). We provide customer support and help you to find out what is possible with those technologies, architect, implement and optimize your projects.

Since we met via the javascript toolkit dojo we are very much focusing on using it and are most efficient with it. But we know that there is not only dojo out there and we provide profound knowledge in JavaScript and CSS, we will support you with whatever toolkit or self-made solution you are using.
We focus on making your app fast!

Let us introduce ourselves so you know who you can work with.

Nikolai Onken – lives in Amsterdam and has a musician background. He is the one who is doing most of work on the dojo themes, he is our CSS God! He is the founder (together with Pete Higgins) of dojocampus.org (a great resource for dojo know how), an active dojo committer since beginning of 2008 and a driving force behind the european dojo community.

Tobias von Klipstein – from Augsburg, Germany (not far from Munich) has been freelancing already for more than eight years now in various areas and programming languages. After doing a lot of PHP and Java he does Python now and has found his place as an active member in the german django community. He is our linux expert and has made great dojo contributions.

Wolfram Kriesing – lives in Munich (Germany) and is already for eleven years in the IT business. From working with big MySQL databases to very early JavaScript applications back in 1999 he has a wide range of experience. He has been an active open source contributor for a while, working on projects like PEAR and has also become a dojo commiter in the year 2008.

Uxebu is in the process of being founded, paper work is still in the loop, but everything will be set very soon.
We are looking forward to work with you. You can contact us as contact [at] uxebu punto com.