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.
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.