Developing the style and templates/components in parallel for Adobe CQ5

In order to speed up development of a site within CQ5, it helps adopting the following process:

•  Devise templates and components for the site based on mockups
•  Implement a standard HTML for all templates and components
•  Develop the components necessary
•  Develop CSS/JS necessary to support the components

Using this approach, the front end team can develop the CSS/JS necessary for the site in parallel with the developers implementing the components and templates for CQ5. Instead of using a waterfall model where the front end team develops the basic HTML structure first and then provides the code to the CQ5 developers, this approach makes sure the CSS/JS works well within Adobe CQ.

To further minimize the risk of browser incompatibilities and to make sure the site will also look good on mobile devices from the start, it helps adopting a basic CSS/JS framework, commonly known as grid systems.

Some grid systems to consider are:

•  960gs (http://960.gs/)
•  Twitter bootstrap (http://twitter.github.com/bootstrap)

The grid systems have a well known html structure and features such as reflow that help on smaller screens. Developing your components with a grid system in mind will also make sure the developed components can be reused in the future with a different stylesheet and make your CQ5 projects faster to implement and easier to adopt to a new site style and new features provided by the grid system.

The Adobe CQ5.5 version uses 960gs for the default geometrixx site, however, choosing twitter bootstrap will provide you with more out of the box functionality commonly found on today’s website.

update: we released a bootstrap templating integration for Adobe CQ 5.5 today. See the following link for more information

Google Chrome JavaScript Speed Compared

By now everybody knows Google Chrome beta is available and we have all seen the claims about JavaScript speed. It’s one thing to read about it, it’s another to actually see the speed difference. So I figured I’ll write a little test program checking out how much faster Google Chrome and JavaScript in Google Chrome actually is. This test is by no means a complete test – the claim that JavaScript is faster should be across the board – therefore doing one test with some specific features should be faster otherwise the claim is not really true, now is it?

I’m an old Commodore C64/Amiga guy – so one thing I always liked back then were the copper bars. In short, the C64 and Amiga allows you to change the color of the screen background per line or even per a certain amount of pixels. The computers also had some vertical blank interrupt allowing you to run some code every time the monitor beam is at the top of the screen. People then wrote cool color bars floating around, nicely animated at 50Hz per second. I figured I can do a similar effect in the browser by using a div per raster line and altering the colors with an interval timer every 20ms.

The sample html page can be found here: http://www.headwire.com/javascript/chrome.html The image to the right is a screen shot of the copper bars running in Google Chrome.

sample copper bars

Speed test results running on a Dell Latitude D820 under Vista:

Browser	200 lines
Google Chrome	~97 frames/sec
Firefox 3	~70 frames/sec
IE7	~20 frames/sec

Update: the nightly minefield (firefox beta) gets about 80 frames/sec.

Observation: the test is of course not just a JavaScript speed test but also a test on how fast changes that are made to the DOM can be reflected on the screen. If not using DIV’s but an image to perform the same test (using the JavaScript BMP Library [not supported in IE7]) we see a 50% speed increase for Google Chrome vs Firefox3. Update: Minefield actually beats chrome on this test by about 10%

A couple of notes:

• There is a faster way to do this if the program does not have to run in IE. You can actually create an inline image with JavaScript with the JavaScript BMP Library (http://neil.fraser.name/software/bmp_lib/). The library allows you to convert an array of color information and a color pallet into an image. Update: bmp creation with minefield seems to be faster than with any other browser.
• I did not test with IE8 Beta on Vista since trying to run it forced me to apply the whole windows update and that used an awful lot of disk space (2+ GB)
• When running into limits (two may lines updated, computer getting slow and running the test in multiple browsers) Google Chrome was way more responsive than Firefox3
• There seemed to be no big difference in speed between Firefox 3 and the current beta with the updated JavaScript Engine (Shiretoko).

As always, would love to hear your comments on this one.