Published: 21 January 2016 From an environment where client-side development was conducted entirely in Notepad by a team of one, we are now in an industry of teams and scrums seeking greater and greater speed and efficiency whilst improving reliability, and minimizing the chance for human error.

Whilst server-side developers have long had a development stack created by giants of the IT industry (or limited open-source options outside of that), client-side development has a host of solutions for all problems (some real and some that should never exist) created by individuals – each with their own idea of the ‘best’ way of doing things.

Choosing which tools work for you in these circumstances is becoming increasingly difficult - not helped by a bickering (collective noun) of front-end developers claiming that you're “not a proper developer” unless you have: a build system, a package manager, the trendiest IDE, a VCS, an SSH deployment network, custom CSS resets (or a normalizer), a CSS framework, a JS HTML parser, a JS framework, a primary JS library, an animation library, a CSS pre-processor, a JS task runner, a linter, a rack of polyfillers etc.

I used to feel that three of these tools were actually necessary for a developer who knew vaguely what they were doing, and the others were there to fix problems caused by the first three. With time though, I have come to a different conclusion – that ultimately in an environment where speed and efficiency are everything, each tool has the capacity to improve the development workflow.

This on its own is fantastic, but I think it’s important to recognize a growing trend in client-side developers – generally speaking, two things are being ignored: pragmatism (in that the time taken for installation, configuration, and training for tools can outweigh the time saved in their use); and more importantly; the user experience suffers as a result of their use.

This is largely due to overuse (or misuse) of tools – often, I think as a result of peer pressure. There are no respected centers of learning for client-side development, for the simple fact that a course would be obsolete by the time a student completed it. As a result, the go-to place for advice and approval is most often an online source populated entirely by members of the same industry, who do delight in a spot of one-upmanship.

Either way, misuse of tools is the root cause of sites which load the same stylesheet three times as a result of a poorly executed JavaScript-HTML template approach. It is the cause of a full megabyte of JavaScript being loaded on a single page site with not one line of JavaScript actually being used. And it is the cause of endless forum posts asking questions about CoffeeScript when they should be asking what the DOM is.

I am not saying for a second that polyfillers are useless, or that there is no place for a linter. But if the site we are building has little more JavaScript than a listener or two, and it is not intended to support older* browsers, why should we complicate the build with these additions?

So how do you create a consistent, pragmatic client-side stack? I don’t believe that using all of the tools available is the answer, and using only raw HTML, CSS and JavaScript with FTP as the delivery mechanism is sufficient for only the smallest of projects. But you can’t change the tools for every project, as that creates endless confusion for any developer entering the workflow – especially in a company with any more than a few concurrent projects. So what is the answer?

Ultimately I think you’re damned if you do and damned if you don’t. There certainly is no ‘one size fits all’ solution. I do believe that every tool deserves due consideration, just don’t be too quick to leap on each one as the solution to all of your problems – initially, at least, they’ll cause more than they solve. And besides – there’ll be another 20 along next week.

Perran Mitchell

Senior Client-Side Developer


Page Name: {% PageName %}

Page Template: {% PageTemplate %}

CampaignID: {% AgentReferrer.ID %}

CampaignName: {% AgentReferrer.Name %}

CampaignPhone: {% AgentReferrer.Phone %}

Item Location: {% PageLocation %}

Search Session Exists: False