Your Front End Checklist

This is my ongoing checklist for a good Front-End dev environment. Please tweet me with any tools I’ve missed.

It originated from the Pluralsight course “Building a JavaScript Development Environment” by Cory House. I use this as a refresher, and strongly recommend you check out the full course if you want a much deeper understanding.

The JavaScript ecosystem moves fast, so the categories are more important than the tools.

Editor Config

This is a brilliant way to maintain consistency between editors. This allows you to write rules like “tabs vs spaces” and “how many space?” You can then enforce these rules across a wide range of IDE’s with the editor config plugin.

Use a developer web server

Let’s you set up a simple web server for development. My favourite is browserSync. With browserSync I can develop my Hugo website and see changes on an ipad, mobile and desktop in real time.

Sharing your work with the client

You’re working for a client, and receive an email asking for progress. Wouldn’t it be great to send a link that shows your current progress LIVE!


Set up



Enforces code consistency in your project. Also enforces coding standards. Useful for restricting console.log / debugger in your production build. So many presets to choose from: Standard JS, Airbnb, XO.

Continuous Integration (CI)

Catches errors before they get into production (if you’re testing). Plays well with your version control system.

Can use multiple solutions at the same time to test various OS’s. I.e. TravisCI for Linux, Appveyor for Windows.

Hosted and self-hosted options.


Work on your Front-end without a finished backend. JSON server points at fake data, and supports updates and changes to the data! Keep API centralised and have an easy way to change between dev and production.

Good examples are:

Production improvements

These are improvements to consider for your deployed web page.


Shrink everything, html, css, js…

Smaller filesize == happier customers.

Dynamic HTML

Inject content into html as well as “production only” info.

Bundle Splitting

Keep the files that don’t change often separate from files that change often. Users can cache these library/vendor files. Reduces the amount they’ll need to download when accessing your updated site.

Bust Cache

You can allow people to save your assets for up to a year! But you may sometimes need to change a file, and 1 year is a long time to wait for changes. Cache busting to the rescue. Your files contain a hash in the name. If the contents change the hash changes. If the html page references a changed file, the hash won’t match the cached file, forcing the browser to grab the updated file.

Error logging

There are production grade products available for tracing errors and usage.