A year in front-end development

The world of front-end development moves quickly, so I’m going to reflect in the big changes I’ve made to my workflow in 2017.

Yarn & Artifactory

I now exclusively use Yarn for dependency management and script running, with Artifactory for managing private Node modules. Fortunately we already have a paid-for Artifactory at the BBC, but using it is much simpler than NPM’s organisation feature, especially at scale. Artifactory integrates with our X.509-based certificate system which means that it just works with our existing identity system, as opposed to NPM’s system which is far too messy for account management, especially at scale and when you have multiple CI servers and environments, etc.

Yarn’s workflow also “just works” as you’d expect it to, as opposed to the mess that was NPM shrinkwrap. The new package-lock.json might make life simpler, but I don’t see any reason to go back.

Good bye Browserify, hello Webpack

We moved from Browserify to Webpack. It’s significantly improved our dev workflow and build times, but has an unfortunate effect of giving our code a bit of a Webpack specific flavour to it… Overloading the concept of ES6 imports to import things like SCSS and other assets has a bit of a vendor lock-in feel to it. The way the final CSS gets rendered by Webpack also feels far from optimal, and a side-effect of trying to shove CSS into a JS-first build chain.

Because of this, I’m far from convinced that Webpack will be the favoured solution in a number of years time, and instead will be replaced by something that considers both CSS and JS as equal first class citizens.

All in on CSP & SRI

My boilerplate project now includes content security policies and support for sub-resource integrities out of the box. This has required surprisingly little maintenance, but was amazingly tricky to set up. For our dev environment, we want hot module reloading for React modules and live reloading for CSS. The classic answer to this seems to be to disable SRI/CSP on the local server, but this can just make it easy to accidentally introduce issues that’ll only get first caught on the testing environment. Getting a setup right and switching between the strict and more relaxed policies was fiddly, and it’d be nice to get this to happen automatically. Currently it seems that hot module reloading, SRI, CSP, etc, all requires wiring up lots of modules yourself, or using purely static site generation which isn’t compatible with our use case of implementing our single-sign on server-side.


It feels like we’re going “all-in” on Facebook tech, but we’ve also switched our test runner to Jest as opposed to Karma + Jasmine. It’s brought some significant workflow improvements, although file watching doesn’t work inside a VM! We use Vagrant to manage “sandbox” instances which minimise the differences between the server and local development environments and this is a major pain point for us. I also haven’t managed to figure out a good environment that allows for “watching” ESLint/Flow/tests all at once in the terminal (other than relying on our IDEs to do it).

What’s not changed?

  • React & Redux is still my weapon of choice for UI work.

All in all, 2017 felt like yet another step forward in maturity for web front-end. The only major disruption for us was in build tooling with the move to Webpack, and sadly it feels like this isn’t the stable solution for all time (the situation for styling and non-asset loading feels too “hacky”),

If you’d like to see a project using my preferred tooling, you can have a look at my perpetual side-project: https://github.com/ManchesterIO/manchester.io.

A technologist wanting to share knowledge and iterate towards a better world.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store