Over the last few months of last year we have been crafting away and exploring many new exciting frameworks and technologies.  So many to mention…… but our core stack as of late has mostly consisted of node.js.  As people of node.js know the npm package manager that is bundled is a fantastic tool to resolve dependencies for the project in question.

With this in mind myself and Stu have been busy hard at work with a large client in the finance sector and looked to ‘resolve’ our client side dependencies in an equivalent manner.  We had a look around at some of the options and for our use case the same two kept cropping up.

Bower

The folks over at the Twitter Engineering team have been hard at work again and built Bower as a client-side package manager.  It allows you to resolve your dependencies via a component.json file and install the relevant git paths as required.  This approach is at a lower level than other alternatives it doesn’t limit you to any transports, ultimately you decide how you wish to deliver your packages client side.

The great thing is that you can just point to git paths and you are away without dependencies on other people to own and manage the updates of packages that exist.  From the experience we had working with Jam.js I suppose it might also be fair to say that it would have taken less “tinkering time” to get the transport with require.js working client side along side some out of date package versions we couldn’t update.

Jam.js

Jam.js is  a package manager with a different spin in that it will install packages from a core jam.js package repository, resolve dependencies and using AMD / require.js to configure transporting your packages to the client.  The configuration for the packages are defined and are stored within your standard package.json file.

There is a down side that is quite commonly raised with the fact you upload a package to a repository separated away from github.  Once a package is uploaded the owner is the only person in which they can update it (unless the owner adds other users).  There is an option to setup your own repository and have jam search the core repository in addition to the one you create, to me this is a big limitation in regards to package management.  

Package management should, in my opinion, be sourced from one place in that it is concise, self managing, effective to install and configured to deliver to the client in the best possible manner.  Jam.js for me meets three out of four in this criteria.

I have started a pull request to try and help with the update of packages via pull requests.  The idea is taken from github / git and allowing users to submit pull requests to repositories.  The initial implementation of this feature with a description and can be found at:  https://github.com/caolan/jam/issues/128

In Summary

We made the choice of Jam.js for out project as it suited our needs to have require.js be configured and setup up as the transport to the client (once we cracked some of the require.js path configuration).  All you need to do is quite naturally add your jam dependencies within your package.json and type on the command line jam install just like npm install and away you go.  

It is not to say we will never use Bower as it does it’s job well and the fact it is lower level may suit other projects where transport via AMD is not a preference.  We may also switch if we find the package management and the central package repository not being kept up to date by community, this is where Jam.js can and may fall down.

Having gone through the onerous task of selecting what type of laptop I wanted at Red Badger (13″ MacBook Pro with 16gb RAM and 512gb SSD) and waiting impatiently for it to be delivered, it was time to get it ready to use.

My previous personal Mac, a late 2010 11″ Air, has done sterling service – even just about managing when asked to run a couple of virtual machines concurrently alongside a Node.js environment. But it was starting to creak a bit and the poor thing’s SSD was chock full of all the random crap that had been installed to support various projects. So as well as the stuff I regularly use there were also leftover bits and pieces of Java, Python and who knows what else.

At Red Badger we’ve largely adopted Vagrant and Chef as a great way of provisioning development environments without imposing on the personal space of your own laptop. Clone a repo from Github, run ‘vagrant up’ on the project directory, the Vagrant script installs and configures a VM for you, ‘vagrant ssh’ and there you are with a fresh, clean dev environment that can be reconfigured, reloaded and chucked away as often as you like. Joe is going to be writing more about this process soon.

So I decided, I would challenge myself to install the bare minimum of tooling to get up and running, with all the stuff specific to our current project residing in a virtual machine. This should also, in theory, make a nice solid base for general front-end development to current practices. And hopefully leave 400gb -odd of disc space to fill up with bad music and animated cat gifs.

The clock was ticking…

1. Google Chrome – goes without saying really (3 mins)
2. Node.js – nice and easy these days with a pre-packaged installer available for Mac, Windows and Linux (5 mins)
3. Useful Node global modules – First trip into the terminal to ‘sudo npm install -g …’ for coffee-script, grunt, express, less, nodemon and jamjs. This is by no means an exhaustive list but gives me all the Node-based essentials to build and run projects. (5 mins)
4. Xcode Command Line Tools – Rather than the enormous heft of all of Xcode, the command line tools are a relatively slimline 122mb and give you the bits you need (as a web rather than OS developer) to compile the source code of stuff like wget. An Apple developer account is needed for this so I can’t give a direct link, unfortunately. (15 mins)
5. Git – Last time I did this I’m sure there was a fair amount of messing around but there is now an installer package for OS X (5 mins)
6. Virtual Box – This is where we start getting in to the real time saving stuff. Virtual Box is a free VM platform which can be scripted, essential for the next part (10 mins)
7. Vagrant – This is the key part, as explained in the introduction. Once Vagrant is up and running, a pre-configured dev environment can be there in just a few minutes (3 mins)
8. Github ssh key config – Back to the command line. To be able to clone our project from its Github repo I had to remember how to do this, and the documentation on the Github site doesn’t have the best signposting. (5 mins)
9. Clone repo and post-install tasks – Get the code down, then run ‘npm install’ and ‘jam install’ in the project directory to fetch server and client dependencies. Run ‘grunt && grunt watch’ to build CoffeeScript, Less and Jade source into application code and then watch for file changes. (2 mins)
10. Vagrant up – With the repo cloned and ready, the ‘vagrant up’ command downloads the specified VM image and then boots it and installs the relevant software. In this case, Node and MongoDB. At a touch over 300mb to download (albeit a one-off if you use the same image on subsequent projects) this is the longest part of the whole process (20 mins).
11. Vagrant ssh – Log into the new virtual machine, change to the /vagrant directory which mounts all your locally held app code, run ‘node app/app.js’. Hit Vagrant’s IP address in Chrome (see step 1) and you’re there (1 min).

So there we go. By my reckoning 74 mins from logging in to the laptop to being able to get back to productivity. And because the VM environment is identical to where I was on my old Mac I could literally carry on from my last Git commit. I did those steps above sequentially to time them, but at the same time was installing the Dropbox client for project assets and Sublime Text for something to code in.

Obviously on a new project you would have the added overhead of configuring and testing your Vagrant scripts, but this only has to be done once and then when your team scales everyone can get to parity in a few minutes rather than the hours it might once have taken.

Vagrant really is one of those tools you wish you’d known about (or that had existed) a long time ago and really feels like a step change for quick, painless and agile development. This is also the first project I’ve really used Grunt on, and its role in automation and making your coding life easier has already been widely celebrated. Hence the title of this post, because this feels like the first step in a general refresh of the way I do things and hopefully I’ll be writing more about this journey soon.

I’ve been always fascinated by 3D and 3D presentation on the web space, well, since the tragic VRML(http://en.wikipedia.org/wiki/VRML). During the time in the university, I poked around Direct3D and OpenGL a little bit and after then anything with 3D on its name attracted my attention but haven’t achieved anything serious thanks to my laziness.

And one day, there came a chance that I needed to do some, admittedly nothing fancy like what you can see on http://www.chromeexperiments.com/, 3D action in an actual project.

My project was a simple coin tossing in 3D and didn’t require complicated physics or lighting or anything that may come with many 3D Javascript libraries. 

During the search, I came across Sprite3D.js (https://github.com/boblemarin/Sprite3D.js/tree/v2) that gave me an idea to use CSS3 3D transform instead of canvas or WebGL.

Sprite3D.js is a very simple light-weight Javascript library that bridges between Javascript and CSS3 3D transform so the code is more readable. It doesn’t have physics engine or any prebuilt 3D primitive objects out of box except box or cube, and that was all I needed.

Surprisingly, I struggled to find any articles explaining how to draw a simple 3D object with code from scratch (that I could just copy and paste easily…), such as a closed cylinder for my coin in this case.

So I planned to use a shallow box as a base of the coin, texture the top and bottom face with the coin’s face and tail, and then place a reasonably smoothly segmented cylinder between the top and the bottom face to make the coin. 

What is underneath…

The image below shows the basic of how CSS3 3D space looks like.

If the centre of your screen is the origin of the 3D space, it’s positive x toward your right, positive y toward up, and positive z toward you. The camera’s position is represented by perspective.

Lower perspective usually produces dramatically exaggerated distance look so called perspective distortion like using wide angle lens, and higher perspective vice versa. 

It can be quite fiddly job to find the right perspective to work on different situations but normally between 700px and 1000px is acceptable. Sprite3D.js uses 800px as default.

A Box that is…

After the stage is set, I made a box to use it as the base of the coin.

http://jsfiddle.net/musshush/GdFJ6/

Easy!

Lots of triangles…

The next is to make a cylinder and this gets a bit trickier.

Let’s start with 8-facet cylinder so it’s easier to illustrate.

[gist id="4943805" file="draw-8-facet-cylinder-part.js"]

In short, to draw a polygon like above, we need “w” that is the width of each facets, angle “d” of the first facet to be used to find “p(x, y)”, and then duplicate the facet and rotate angle “d” until fill the full circle.

First, we need “d” that is the angle of the facet and convert it to radian to be used with Math.sin() and Math.cos().

And get “w”, width of the facet

And get the distance between “o” and “p” to get the position of the first facet

And then rotate it for each facets

http://jsfiddle.net/musshush/cRxML/

With 80-facet cylinder it looks a lot smoother.

http://jsfiddle.net/musshush/xXHrg/

And now texture the cylinder and make it a bit thinner so it looks more like a coin.

http://jsfiddle.net/musshush/VnU63/

Finally…

Now it’s the time to toss it and add a shadow layer for the finishing touch..

http://jsfiddle.net/musshush/4ELHK/

With a bit of randomness with Math.random() and an easing function, it’s possible to create a convincing animation without physics engine.

On a recent project we had a requirement to provide a number of game-like interactions which didn’t really fit, design-wise, into the rather boxy constraints of HTML elements. Probably as recently as a couple of years ago you would have automatically turned to Flash to create these interfaces, but with a need to make the games work on mobile and other devices where Flash support is either absent or a battery drain we looked around for alternatives.

In the post-Flash rich-UI space there are currently two main options – Scalable Vector Graphics (SVG) and Canvas. SVG has actually been around a fairly long time, but adoption on the web has been held back until recently by browser support. It’s the definition of vector (line-based) graphics in an XML document which are drawn to the screen, with the benefit that the drawing can be manipulated by altering the properties of each vector. Canvas, on the other hand, is a relative newcomer and thought of as part of the “HTML5″ family of technologies. It’s a bitmap (pixel-based) format so each update to a canvas object involves over-writing the pixels that were there before.

Both have their uses, and in fact we ultimately used both in the overall project in the places that suited their strengths. But for this particular one, a multiple choice quiz based on the relationships between people and objects, SVG seemed like a natural fit.

Using Raphäel

Based on past experience with it, I chose Raphäel as the SVG library to base the work on. While this was a great head start – Raphäel provides a nice API to work with the SVG DOM and appropriate fallbacks for older browsers – in previous uses I hadn’t done much in the way of interactivity and this is where things started to get complicated.

Binding Javascript event handlers to SVG elements works comparably to HTML, and this is fine when a click or touch on an element affects only itself. In the context of a game where multiple elements need to be changed, it becomes a headache to keep track of state and what everything is supposed to be doing.

In HTML this problem has been largely solved with the rise of Javascript MVC libraries, where the state of a page or application is held as a model in Javascript and bindings to the DOM are used to update the UI based on changing data or user input. This was exactly what we needed for our game, but on initial investigation it looked like there wasn’t really anything directly comparable for SVG.

At first the whole game area was created in SVG, but given this event/state issue and that there isn’t much sophistication in the SVG 1.0 spec for text handling – especially wrapping of strings in a container element – we switched to rendering the multiple choice selections with HTML. This is the only part the user directly interacts with, and as HTML it could be bound directly to the Knockout viewmodel we stored the game state in. Changes in the model could then fire the appropriate functions to update the state of the SVG object and sanity could be preserved.

This reduced a lot of complexity and made the UI easier to manage but it still feels like a compromise solution as the smoother styling and scaling effects available in SVG couldn’t be applied to the HTML parts of the game.

What else is out there

However Raphäel isn’t the only SVG library out there, and other options might get closer to what we really needed. Pablo is described as being a combination of Raphäel, jQuery and Underscore for SVG, and an initial look shows a nice API with some useful stuff like duplication, templating and DOM traversal. As is often the way of these things, Pablo popped on to our radar just as the project was finishing.

D3.js is a popular charting and data visualation library which is able to transform documents based on changing data. However there’s a higher level of complexity here and so in the constraints of the project there wasn’t time to investigate it fully.

Another really interesting looking SVG library is Bonsai which is used as the basis of a Flash to HTML5 conversion service. And on the other side of the modern-rich-UI party, Canvas Query is a new tool positioned as a jQuery-style wrapper for the Canvas element.

What else is needed

While there are plenty of sophisticated options for pure charting in SVG, which can also handle data entering and leaving the object, it feels to me as if there is a missing link in a nice handler for interactivity and application state.

Or perhaps the solution is in one of the tools listed above and I haven’t looked hard enough yet.

Either way, I’m going to look into this in more detail. Something that can act as a bridge between popular Javascript MVC libraries – the likes of Knockout, Backbone and Angular – and SVG rendering would be a useful tool, and if it doesn’t already exist it would be worth creating.

Like many of the developers in the world, when I heard about AngularJS for the first time I was very much fascinated by the idea and its seems-to-be easy implementation.

However, unfortunately, like some of the same developers in the world, my enthusiasm quickly faded out when the team decided to give it a go for a client project.

The first problem we encountered was lack of information of how to implement it for, yes, IE7, at that time. Some may argue that it is our own fault that we still work for this ancient beast but, if the client still want it in their pen what choice do we have? 

So we scoured the internet looking for the solution and tried a few options and finally made it work in the way we wanted it to.
After that we were all set to build a sort of wizard form with some chained lists that update themselves when the parent is updated.

Everything seemed to be working fine except some ups and downs we had while getting ourselves familiar to AngularJS, and finally we got our AngularJS powered wizard (form) to go. It felt great… so we ran it on IE7.
It worked! But the start up of the page was painfully slow. I could count some seconds before the page was fully initialised.

I still quite like the idea of AngularJS way of data binding directly on HTML. So I thought I may give it another go to see whether the IE7 problem we had was just my pure bad coding.
I knew on IE7 whatever I do the performance would be lower than the latest browsers but wanted to see how low it really is compared to other browsers including its own descendants IE8 and IE9.

The tests…

I found some interesting framework performance tests like this one from Paul Hammant’s blog  and Angular VS Knockout VS Ember on jsperf.com. The latter one gave me the idea to use jsperf.com to measure the performance between browsers.

I downloaded a simple todo list sample using AngularJS and RequireJS from todomvc.com (this is a very useful site if you want to see how all those different frameworks work to achieve one same thing) and modified it to use on jsperf.com. You can see my test page here and the modified todo list on my github repository.

I created three separate virtual machines with exactly the same system setting, one with IE7 on Windows XP, IE8 on Windows XP, and the last one with IE9, Chrome and Firefox on Windows7 as you cannot have IE9 on Windows XP. Safari is used in this test on Mac OSX.

And here is the result and… Safari did so amazingly well here but it wasn’t really a fair comparison as it was not running on the same virtual machine setting so I will ignore Safari on this table.

 The x-axis is the number of operations per second so the higher the better. And from top to bottom it’s Chrome, Firefox, IE7, IE8, IE9, and finally Safari, in the Alphabetical order.

I expected Google Chrome would top the table since AngularJS is from Google but it was Firefox that did the best.
Not so surprisingly, all IEs didn’t perform very well, but surprisingly even IE9 could do only a third of Chrome’s performance. Another surprise was that, for more intense tests like 30 cycles of pushing data(oh, yeah, so intense…) in one sample, IE7 actually outperformed IE8.

After the first test, I wanted to have a fair test between Chrome and Firefox against Safari so created another test only for these three browsers on Mac OSX.

Here is the second test, and the result is…

From top Chrome, Firefox, and Safari.

Chrome still couldn’t beat Safari in this performance test but did slightly better than Firefox. Firefox didn’t have much difference whether it’s on Windows or Mac OSX even when the virtual machine’s setting was a lot lower spec than the mac used.

To use or not to use…

As you can clearly see from the result, it can be quite fun using AngularJS if your project doesn’t have to support Internet Explorers, especially the older ones, but I wouldn’t recommend it if you’re thinking to use it for an adamant client that refuse to upgrade their systems up to date.

Hello, I’m Stephen. I’m a front-end web developer, focusing these days mainly on Javascript and Node but with a wide range of experience in most of the technologies that make stuff look good in a web browser.

I’ve been working with Red Badger as a freelance collaborator on and off for almost two years, in fact since it was just Stu, David and Cain at the Ravensbourne incubator programme, but we’ve finally decided to make it official and I’m going to be joining the team here permanently.

Switching back to a full time role after a stint freelancing has been a tough decision, but the strength of the team and the technologies in use here make it an exciting place to be. With a background in interface development I’ve had exposure at the integration stage to the various languages – PHP, C#, Java, and so on – that make the pages I build actually work, without really gaining a deep understanding of them. However now I can write server-side code in Javascript as well, with Node, it feels like I can really build on my existing skills to do new and interesting things.

With other developers in the team adopting Node from the other direction, from their excellent C# and infrastructure experience, it feels like we can bring the client and server parts of web development closer together – whether in shared code, better build processes or improved performance. On the recent BBC Connected Studios pilot project, Joe, David and I were all able to contribute not only ideas but also implementation across the whole application. There are still some problems to solve and the best ways of working will settle down over time, but as a company we want to contribute to the community and share what we learn so there’ll be more blogging on these subjects in the near future.

Now if you’ll excuse me, I need to go and get used to being an employee again… 

Unsurprisingly, there were several talks about the web and JavaScript at QCon. There is no doubt about the meteoric rise of JavaScript in the recent years, and it’s hard to imagine that this will not continue. Web browsers have been powered by JavaScript for years and more and more desktop applications are moving to the web. Node.js proved that JavaScript is as good as any other language for building a framework for web applications. Mobile web seems to be the next frontier and where progress seems to be among the fastest.

JavaScript Today and Tomorrow: Evolving the Ambient Language of the Ambient Computing Era

Allen Wirfs-Brock (Mozilla)

Download Slides

Allen is a Mozilla Research Fellow and was the project editor for the ECMAScript 5/5.1 standard.

Allen started off his talk by illustrating the two major eras in computing, the corporate computing era and the personal computing era. A major shift in computing happened in the late 70s and early 80s, where the shift to personal computers radically changed the nature of computing. Currently, we are undergoing another significant shift to what could be called the “ambient computing” era. Ambient computing has the characteristics of being device based rather than computers and being ubiquitous.

Every computing era had a dominant application platform. The dominant platform emerged as the winner through a combination of market demand, good enough technical foundation and superior business execution. The dominant platform for the corporate computing era was IBM mainframes. In the personal computing era, the dominant platform was the combination of Microsoft Windows and Intel PC (much lovingly called Wintel). In the emerging ambient computing era, it is becoming clear that the new application platform will be the web.

Each computing era also had a canonical programming language – COBOL/Fortran for mainframes and C/C++ for personal computing. The canonical language for the web and thus the ambient computing era appears to be JavaScript. Allen brought up the interesting question about what could replace JavaScript and how that could happen. JavaScript, even with it’s quirks is “good enough” and there doesn’t seem to be any apparent way that it would be replaced by anything else. As such, his claim that “JavaScript will be the next canonical language for the next 20 years” seems spot on.

After the ECMAScript 4 fiasco, TC-39, the committee responsible for deciding the future of JavaScript, is moving a lot faster and is more driven and organized to improve the language. There are a lot of improvements to the JavaScript language coming with ECMAScript Harmony, which represents ECMAScript post version 5. Some might be considered controversial, such as the inclusion of classes, and are ongoing current discussion. Considering the slow browser adoption rate, even ES5 is not yet mainstream and will not be for a couple of years more. This unfortunately seems to be one of the biggest bottlenecks in moving the new ambient computing platform forward.

The Future of the Mobile Web Platform

Tobie Langel (Facebook)

Tobie is currently the chair of the Core Mobile Web Platform Community Group which is dedicated to accelerating the adoption of the Mobile Web as a platform for developing mobile applications. Tobie and his team at Facebook put a lot of effort into analysing the most popular native applications and finding out what capabilities were missing in web applications to make them on par with native applications in terms of user experience.

Facebook recently launched ringmark, a test suite aimed to accelerate the adoption of HTML5 across mobile devices and provide a common bar for implementations of the mobile web standards. Ringmark provides a series of concentric rings, where each ring is a suite of tests for testing mobile web app capabilities. There are currently three rings, however the intention is to continue the project by adding more rings as the capabilities of mobile devices increase.

Ring 0 is designed as the intersection of the current state of iOS and Android and 30% of the top 100 native mobile applications can be implemented using ring 0 capabilities.

Ring 1 includes features such as image capture, indexDB and AppCache. Browsers implementing ring 1 should be able to cater to 90% of the most popular native applications, most of which actually don’t or need utilize advanced device capabilities such as 3D. Tobie highlighted that getting ubiquitous ring 1 support should be the short term goal for mobile browser vendors and developers to drive mobile web adoption.

Ring 2 will fill the gap with the final 10% of applications, with things like WebGL, Web Intents and permissions. Ring 2 is aimed to be a longer term goal.

Mobile Web should also be able to achieve beyond 100% of the native apps, with capabilities such as hyperlocal applications (e.g. an application tailored to a certain local event) and deep linking.

Lack of standards for mobile web applications when it comes discoverability or manifest files was also mentioned as one of the hurdles that mobile web needs to overcome. It will be exciting to see how fast we will be able to reach there.

The Future Is Integrated: A Coherent Vision For Web API Evolution

Alex Russell (Google)

Slides (Built with HTML5!)

Alex is a TC-39 representative for Google and is also a member of the Chrome team. One of Alex’s missions has been to drive the web platform forward. He is as frustrated as the rest of us developers with the current state of fragmented support and slow progress.

WebIDL and JavaScript have a cognitive dissonance problem. DOM was specified as an API for the browser programmers rather than the actual consumers of the API who are the JavaScript/web developers. It was also devised at a time where there were expectations that other languages than JavaScript would be consuming it, and artifacts of such an ideal still persist in the API. Moreover, DOM does not conform to normal JavaScript rules. The DOM types cannot be extended or constructured. It is not possible to do a new HTMLElement() whereas it would be very useful for many scenarios.

As web applications have increased in complexity, the disconnect between application data and the browser model has grown making web development painful. The developers have been trying to solve this using frameworks such as Backbone.js, however they are not perfect. Alex outlined two proposals to W3C that seek to make web development easier.

Shadow DOM is a way to create web components by a browser provided API. Modern browsers include native controls, such as the standard HTML form components. These built in controls are isolated from the rest of the page and are only accessible through whatever API they expose. There is currently no API to create third party components with the same strong encapsulation enjoyed by the native components.

The other proposal is Model-driven Views which reminded me a lot of how Knockout.js works. MDV provides a way to build data driven, dynamic web pages through data binding and templating via native browser support.

Also interesting, but didn’t get the chance to attend:

Mobile, HTML5 and the cross-platform promise

Maximiliano Firtman

Download Slides

Wrap Up

The various efforts around HTML 5, JavaScript and the mobile web all point to an improved developer experience. The question is how soon will this future will arrive? Combined with browser vendors pushing updates aggressively and consumers changing mobile phones every 1-2 years, it might not be as far as it seems. Listening to the talks also confirmed my opinion that native mobile apps are only a stopgap solution and the future lies in HTML 5+ and JavaScript as the platform that will power applications in the future.

Over the past couple of months, a small team at Red Badger has been working on a number of HTML5 prototypes for an interesting client. Speed of development and easy iteration have been essential so we’ve taken the opportunity to try out a new technology stack which has given what we were looking for and is exciting the whole business.

Maybe a demanding prototype schedule isn’t the ideal place to chuck away everything you’re used to and start afresh, but actually a lot of the front-end development has built on tools and themes we’ve worked with throughout 2011 and we’ve found that the speed and ease of using Node has more than compensated for the learning curve. So, what have we been using?

Server

Node – Underpinning everything we’ve been doing in our prototyping project; Node is fast, event-driven and built on Javascript. Its been fascinating for myself, as a primarily front end developer, and Stuart with an ASP.net background to see how our respective specialisms are converging on a single set of tooling. The module loading system, NPM, which is similar to Ruby’s Gem ecosystem, also makes it incredibly easy to pick up and play with the many extensions that are out there – and to create your own too.

Express – A development framework for Node, giving RESTful routing and content negotiation. After working with Open Rasta in .net MVC on a previous project, the ease of setting up applications using Express has been a delight.

Jade – With Express providing the application routing and view rendering, we next add Jade for templating. A HAML-style syntax, offering us simplicity and brevity but compiling to really well-formed HTML and easy to use with HTML5 data-* attributes for Knockout (which we’ll come to later). In fact having used Jade for a while now I’m not sure I want to go back to writing “proper” HTML.

Step / Async – Node’s asychronicity takes some getting used to after having worked with linear control flows for such a long time. Imagine AJAX callbacks as the fundamental way a language works – you can’t rely on other parts of your application providing data at the moment you need them, so you need to be able to create queues for parallel and serial execution. Step and Async are two modules we’ve tried out for this, both have their benefits but Async seems to be slightly in the lead for what we’re doing.

Now – The other great benefit of Node is its ability to serve real-time applications, and the Now module takes this to almost magical levels. Existing as a namespace on both the client and server simultaneously, you can call client methods from the server (and vice-versa) to push data instantly as a general or targetted broadcast. Seeing this in action has really convinced us that Node is something to get excited about, and has wowed the client too!

Client

Knockout – We used Knockout on other projects throughout 2011, but with Node’s inherent ability to supply real-time data its really coming to its own. It’s a Javascript library implementing the MVVM (Model-View-View Model) pattern, which should be familiar to Silverlight developers, and makes rich UIs a breeze to update. The new 2.0 version, released during the Christmas break, removes the reliance on jQuery for its default templating which really opens up its flexibility.

Underscore – Described a ‘utility-belt library’ for Javascript, Underscore is another tool that is compimentary to the likes of jQuery and adds a whole raft of functional programming methods to objects and arrays (among other things). It also runs as a Node module so we can make use of it on both client and server, great for code consistency.

Ender – In fact with Knockout and Underscore at work, it was beginning to feel like jQuery had been relegated to just a “ready” utility, DOM selection and effects. That’s a lot of weight for something we weren’t using very much so as an alternative we’re trying out Ender, which allows you to compile your own library from smaller modules – such as the lightweight DOM selector Qwery. And it all installs and builds in a similar approach to NPM.

LESS – A CSS pre-compiler, and another tool we used during 2011, but as a native Node module its integration is now much easier. If you’re developing in a Node environment you can use it to watch for LESS file changes and compile locally (we also use LESS.app on OS X), and then deploy the LESS and have the server startup create a complled and minifed version in production. Alongside Jade and Coffeescript its beginning to feel like compilation from more efficient syntaxes down to browser-readable files is becoming a key element to web development.

The whole picture

As well as this Javascript-oriented development we’ve also been trying out MongoDB and Redis for data storage as part of the stack, with equally encouraging results. And to make project compatibilty and pair programming between our Windows, Mac and Ubuntu users easier we’ve given JetBrains’ Webstorm (and PHPStorm) IDE a thorough test drive – given it has all that familiar Reshaper goodness from their Visual Studio tools its looking like a great combination so far.

It might seem that, with all these Javascript-heavy technologies in HTML5 documents, older browers won’t get a look in. As we’re prototyping on this project perhaps its not important, but actually support is pretty good. Every view Node creates is sent as rendered HTML, just like any other web server, and in fact due to its speed we’re finding that we can make sites less “AJAX-y” than we might otherwise – which of course is better overall for accessibility and discoverabilty. On the client side, Knockout is compatible back down to IE6 and even the ‘magic’ of Now is mobile compatible, with beta support for older IE versions. Of course we want to move away from those legacy browsers as much as any other developer, but if it’s a client requirement this stack can still provide it.

So as a result of these experiences we’re investigating using Node and its related technologies more widely at Red Badger during 2012, its already looking like its going to be an exciting year!