Christian Heilmann

Author Archive

Being humbled talking about JavaScript – and more to come at @media Ajax

Wednesday, August 22nd, 2007

I am currently in [tag]Hongkong[/tag] training colleagues from Asia on how we do things in Europe. Or so I thought. I came here with [tag]Douglas Crockford[/tag] and [tag]Nate Koechley[/tag] to show what we’ve done in the US and the UK to make life easier for developers to create web sites and applications.

When we asked around for each team to show us what they work on and what things they needed input on we were in for a big surprise. It is pretty amazing what kind of implementations you see around Asian web sites and how naturally the developers here used the recommended technologies without ever asking or telling us about it. I can’t wait to bring back the findings the teams here documented to share with the folks back home.

That said, I am also learning about problems us latin font users don’t get and only come up when you use Mandarin or Korean. All in all this is a great experience, both in terms of sharing information and realizing how much of your work for the web standards movement gets used without you ever being the wiser. For example I found a translated PDF of one of my articles I didn’t know before.

Talking about being humbled talking about JavaScript, things are happening on the [tag]@mediaAjax[/tag] web site. The sessions are mostly defined and the already impressive list of speakers got some more interesting additions. Specifically the [tag]Ajaxian[/tag] folk [tag]Dion Almaer[/tag] & [tag]Ben Galbraith[/tag] and [tag]Alex Russell[/tag] of [tag]Dojo[/tag] join well-known JS speakers and scarcely seen people on the European speaker circuit. If you want to talk JS and Ajax, I am quite sure there is hardly any better summit to go to this year.

Again with the Module Pattern – reveal something to the world

Wednesday, August 22nd, 2007

Not too long ago I was raving about the beauty of the Module Pattern in JavaScript and the annoyance I felt with it when it comes to repetition of long namespaces when calling or reading public methods and properties from other public methods and properties.

To recap, the “classic” Module Pattern means you define a variable as an anonymous function that gets immediately called with (). You define private functions and variables and return your public variables and functions as properties and methods of an anonymous object:

var classicModulePattern = function(){
  var privateVar = 1;
  function privateFunction(){
    alert('private');
  }
  return {
    publicVar:2,
    publicFunction:function(){
      classicModulePattern.anotherPublicFunction();   
    },
    anotherPublicFunction:function(){
      privateFunction();
    }
  }
}();
classicModulePattern.publicFunction();

The beef I had with that is that you need to repeat the name of the main object when you want to call one public method from another or access public variables. The other bit I was annoyed about is having to switch to object literal notation for the things you want to make public.

Inspired by the comments on the blog post on the YUI about the module pattern and pubstandards, I started advocating using a named object called pub to append methods and properties to before returning it. That way you can call public methods via the pub.methodName shortcut notation instead of repeating the main name:

var namedObjectModulePattern = function(){
  var pub = {};
  var privateVar = 1;
  function privateFunction(){
    alert('private');
  };
  pub.publicVar = 2;
  pub.publicFunction = function(){
  pub.anotherPublicFunction();    
  };
  pub.anotherPublicFunction = function(){
    privateFunction();
  };
  return pub;
}();
namedObjectModulePattern.publicFunction();

During a Q&A session in a training in Hongkong yesterday I showed this to Douglas Crockford and asked him what he thinks of it. He didn’t mind the idea, but considered even the pub object redundant.

There is another option which I am hereby calling the Revealing Module Pattern. In this permutation you simply define all your functions and variables in the private scope and return an anonymous object at the end of the module with pointers to the private variables and functions you want to reveal as public:

var revealingModulePattern = function(){
  var privateVar = 1;
  function privateFunction(){
    alert('private');
  };
  var publicVar = 2;
  function publicFunction(){
    anotherPublicFunction();    
  };
  function anotherPublicFunction(){
    privateFunction();
  };
  // reveal all things private by assigning public pointers
  return {
    publicFunction:publicFunction,
    publicVar:publicVar,
    anotherPublicFunction:anotherPublicFunction
  }
}();
revealingModulePattern.publicFunction();

This keeps the syntax of the whole script consistent and makes it obvious at the end which of the functions and variables can be accessed publicly. The other benefit is that you can reveal private functions with other, more specific names if you wanted to.

var revealingModulePattern = function(){
  var privateVar = 1;
  function privateFunction(){
    alert('private');
  };
  var publicVar = 2;
  function publicFunction(){
    anotherPublicFunction();    
  };
  function anotherPublicFunction(){
    privateFunction();
  };
  // reveal all things private by assigning public pointers
  return {
    init:publicFunction,
    count:publicVar,
    increase:anotherPublicFunction
  }
}();
revealingModulePattern.init();

You can even return values as the public properties by calling the functions in the anonymous object:

var revealingModulePattern = function(){
  var privateVar = 1;
  function privateFunction(){
    alert('private');
  };
  var publicVar = 2;
  function publicFunction(){
    anotherPublicFunction();    
  };
  function anotherPublicFunction(){
    privateFunction();
  };
  function getCurrentState(){
    return 2;
  };
  // reveal all things private by assigning public pointers
  return {
    init:publicFunction,
    count:publicVar,
    increase:anotherPublicFunction,
    current:getCurrentState()
  }
}();
alert(revealingModulePattern.current) 
// => 2
revealingModulePattern.init();

Of course the example names here are far from what I would use in a real script, but it shows the power of this pattern.

The endless talk about code syntax standards and an idea to get there quicker

Tuesday, August 14th, 2007

As the readers of this blog know, I am currently working in a new team that defines the code standards, best practices and methodologies to follow for the European web development in our company. We’re trying to achieve that using a mixture of commonly regarded best practices and findings in different projects after analyzing their outcome.

There are several things that are a no-brainer, like web standards compliance, unobtrusive scripting, namespacing and so on and so forth. Where it starts to get tricky is defining code syntax standards to follow. Tabs or Spaces? Curly braces on the same line or on the next? Spaces around equal signs or not? Many a religious debate and many a working hour has been held and wasted over these.

A big portion of the endless debate is because code syntax means personal style and people are ready to defend their solution to the issue to the bitter end. A lot of times the solution does not get justified by arguments either but gets sold as “this is how I always did it”.

However, there are several arguments that speak for following a certain code syntax:

  • Code can be easily handed over to other developers
  • Version control works without false positives (a tab changed to a space is a change, but it really isn’t, now is it?)

Now, what can be done about this dilemma? Either you find a concensus and make it mandatory, or you try another option:

  • You define a standardized way of coding
  • You make sure that people create valid code
  • You also make sure that the code can be minified (all whitespace removed) as that should be done with live code to save on file size anyway.
  • You collect the different desired syntax styles
  • You offer plugins for the different editing tools in place (notepad++, dreamweaver, eclipse, textmate…) that can convert the code between the different styles by minifying and re-styling (code beautification).
  • You make it mandatory for developers to run the beautifier that creates the standard syntax before submitting the code to the version control.

It is a bit of work up-front, but it means that:

  • People can code the way they want to
  • Code will be ready to be minified for the live system
  • Developers who buy into the agreed standard won’t have to do anything extra.
  • Other developers have tools at their disposal for quick conversion

What are your thoughts? Worth persuing and sharing the plugins?

[tags]standards,standardization,code,syntax,teamwork,codesyntax,versioncontrol,methodology,workflow[/tags]

Flirting with the Flash Community

Thursday, August 9th, 2007

It doesn’t happen often that you get invited to speak at a conference about a technology you never programmed yourself. However, I will give a talk at the Flashforum Konferenz Cologne this September. I got a bit daring and came up with a topic that I couldn’t believe they signed off called Emancipated JavaScript and the Coming Out of the Flash community.

What this means is that I will try to spark a bit more enthusiasm in the Flash community to go out there and give other developers a run for their money when it comes to creating Mashups and talk about their technology as a good option when it comes to creating online applications with rich user interfaces.

While I have worked with Flash developers in the past, I always came across a certain mistrust in the technology from the business side. For example a financial application we developed didn’t get the Flex interface we prototyped because of “Flash being Active-X” and got replaced by an inaccessible obtrusive 3MB big JavaScript solution.

Working closely and loosely with amazingly talented Flash developers like Steven Webster, Ian McBurnie, Aral Balkan and Niqui Merret made me aware that there is the same “big thing to happen” feeling and enthusiasm that shook the JavaScript community some years ago.

JavaScript developers discarded the stigmata of the “move stuff around, require certain browser settings and pop things up” days of DHTML and embraced Dom Scripting and later on Ajax taking over the web application world by storm. By now having JavaScript as an interest on your CV does not get you a confused shake of the head but is actually sought after by headhunters.

There are a lot of parallels in the misunderstandings of JavaScript as a technology in the past and those that keep Flash from being a mainstream developer technology and I will try to show them and offer options to set these straight.

Currently hot technologies like maps and online video show a lot of potential but can become even better with proper Flex or Flash applications. Flash already does help JavaScript and HTML based applications like the flickr uploader to work around JS restrictions. In terms of accessibility, Flash applications can be a lot better than Ajax apps which simulate rich interfaces by using HTML and CSS and dynamically changing the latter.

While people woo the webdeveloper world with JavaScript and Canvas effects that are quite common inside Flash and nothing new you don’t see many Flash apps being featured on web development news blogs and mailing lists. Yes, Flash is not a web standard, but I personally think it is time we realise that we miss out a lot of fun and options that we just cannot achieve with JS and HTML, or simply simulate badly.

Let’s see how it goes. :)

[tags]flash,conference,talk,presentation,evangelism,domscripting,javascript,flashforumkonferenz[/tags]

Automating the generation of CSS sprites

Thursday, August 9th, 2007

CSS Sprites are a very good idea indeed. Instead of having lots of small images that all need to get loaded (HTTP and possibly DNS request) you use one large image and use background-position to only show the one you need. This makes your pages faster and gives users the impression that it is available much faster as the images don’t pop up one after the other.

The only problem is that creating background images that contain the others can be quite annoying in Photoshop or Gimp or Fireworks or whatever you want to use, which is why I lately find that people create automated tools for that. The first I encountered is pzImageCombine which is a standalone app.

Today I also got ab email about csssprites.com which is an online service that allows you to upload several pictures and creates the combined image and an example HTML file for you. Props to my colleague from oversees, Stoyan Stefanov for that one.

[tags]CSS,sprites,csssprites,image slicing,optimization,speed,rendering,css,webdevtrick[/tags]