How and why we decided to make the switch to being a pure JavaScript agency 10 years ago.

At the start of 2010, an idea came into my consciousness; would it be possible to unify all of the technical teams at Clock under a single language? JavaScript was the obvious choice, but the idea seemed a lot crazier than it does today. JavaScript only ran in the browser and was not considered a 'proper' language by serious software engineers. If possible, the benefits could transform our business.

Clock has three technical teams: Technical Services, Software Engineering and Frontend Development. In 2010, each team worked together on projects but were isolated by their editors, tooling, and processes, due to the languages they used: Frontend worked in HTML, CSS, and JavaScript. Software Engineering in PHP and Technical Services mostly Bash, Ruby, and Python. The lines blurred, with some staff being more 'full-stack', but it wasn't the culture.

My responsibility is to define and lead the technical direction of the company. Excessive change is as dangerous as stagnation. Choices require careful due diligence to ensure they fit our development requirements and the business needs of our customers. I was confident that everyone using the same language was going to give substantial productivity gain as well as a distinction in the market; I just had to sell the vision into my teams. They are all smart people, and I don't expect them to do what I say without questioning it. I wanted to make them part of the decision, giving them a chance to feedback, gaining their insight, gauging their enthusiasm and allowing them to point out potential blockers I'd not considered. There were some valid concerns, but they bought into it with passion and could all see how big this could be for us.

Around this time, NoSQL was gaining popularity and seemed a good fit for our non-flat data. Postgres, our default choice of database for most projects had some scale and operational issues, so we were looking at other options. MongoDB was approaching version 2 with the promises of scale and stability and advocates such as The Guardian newspaper. It just so happened that MongoDB is queried using JavaScript and JSON, so it became the first step in the transformation. Using PHP and MongoDB, we put together a sign-up page for ShortList Media who were about to launch a new brand, Emerald Street, a daily lifestyle email for Women. Traffic and database I/O wasn't going to be massive, but it allowed us to perform successful load tests which gave us the confidence to proceed.

Our PHP stack had served us well. It could be horizontally scaled, but the number of Apache instances required to scale to a modest number of concurrent requests felt excessive. I/O in PHP blocks until the request completes, all the while consuming memory and load until the I/O operation returns. This limitation made it costly and more complicated for clients who wanted high peak traffic, such as that caused by TV and newspaper advertising. We believed there was a more elegant solution.

In late 2009 Ryan Dahl demoed Chrome's JS engine V8 wired-up to an event loop. He claimed it could handle vast concurrent I/O on a single process, precisely the problem we were trying to solve. After hearing this, building a Node.js web server and conducting benchmarks and load tests became the next milestone.

It was exciting to see JavaScript running in the terminal, seeing the numbers going up and up on a single process getting high concurrency without memory or load exploding made it clear that Node.js was going to be a game-changer for us.

After building a simple web service for a small client in pure Node.js and MongoDB we were hooked. We took the plunge and agreed to build an upcoming Sun Perks project, a customer loyalty project for The Sun, purely in Node.js.

A lack of a function library was an initial hurdle, but Isaac Z. Schlueter's new NPM soon arrived and brought a blossoming ecosystem and many of the essential modules we needed. There remained plenty of heavy lifting to do, anything we couldn't find on NPM we'd design and build to our exact requirements and release back to the community. Using modern software design patterns and functional JavaScript, we redefined our methods with a focus on single responsibility core functions, that could be composed together to build out features quickly and with low complexity.

We chose Mocha for testing, Express as a webserver and Jade and Stylus for HTML and CSS preprocessors. As the Product Owner, I took responsibility for features and overall software design. I also provided core elements, such as validation, caching, persistence, and application security. Software Engineering assisted and built out domain features and further core modules. Frontend established Jade and Stylus versions of our standard HTML and CSS and the build tooling. Configuration management, deployment, logging, load balancing and scale testing were the responsibility for Technical Services.

It was an exciting time of constant innovation, collaboration, and creativity, with new modules, interfaces and scripts exploding out of the teams, and all of it in JavaScript.

It took hard work laying the foundations for our future. The first projects required extra effort at our expense; it took late nights and weekends to get things built and working as expected. It was paramount that this initiative did not impact the client experience of Clock or their customers. Fortunately, we saw productivity gains very early on, some because it was new, and everyone was focused, and some because it was cleaner to work with and had faster workflows. The test ran faster than PHPUnit tests; dependency management was straightforward compared to PHP's PEAR/PECL. Frontend fell in love with Jade and Stylus, their code quality and productivity improved immediately. Bash scripts on servers, which were hard to maintain and impossible to test, started to be written in JavaScript with tests and if they were general-purpose enough, published as an NPM module.

The teams worked more closely together. Software Engineering took more ownership of the browser code and worked to skill-up Frontend to ensure the same standards of quality and testing applied to browser modules. Technical Services remained polyglots but skilled up in JavaScript to collaborate more with other teams, and everyone started sharing code and modules.

The three metrics we use as stability indicators: number of alerts, support tickets and incident reports, remained mostly static. One challenge we face even today with the long-running nature of Node.js is the appearance of memory leaks. They are rare and generally slow-growing, and while they are laborious and time-consuming to debug, good practices and awareness help prevent them. All in all, they are considered a fair trade-off for the many gains we made.

Once we fully adopted Node.js, opportunities arose to tell our story. Others wanted the assurance that Node.js was running in production. New marketing opportunities opened up. We sponsored and gave talks at LNUG, and I was asked to deliver a keynote at the Great British Node Conference;  invited onto panels at NodeStack Conf in San Franciso and to be a guest on the NodeUp podcast. Our sponsorship of the NodeUp podcast brought us one of our largest accounts, Riot Games, when they were looking for "UK's leading Node.js developers" to build products for them.

JavaScript brought the teams together; it allowed us to invent more effectively, increase performance and decreased complexity. It gave us new ways to market our services, established us as a leader in the field and brought about productivity gains, giving us more time to focus on delivering value and building great products for our customers.

Perhaps the most significant mark of success is the longevity it has had. Ten years have passed since the inception of the idea of a pure JavaScript agency, the world has just about caught up; Node.js has moved on considerably, but everything is still JavaScript at Clock, and it looks set to stay that way.

If you want to know some more of the benefits of Node.js, read here. And of course, if you want to discuss any projects and how we could help leverage Node.js in your organisation to achieve your goals, get in touch via email or by phone on 01923 261166.