Tools we use

Here is a list of tools we primarily use including information on why we don’t use (sometimes popular) alternatives.

Generic Tools

Code formatter: prettier

We automated code formatting since it’s highly subjective and requires lots of time if done manually.

We use its default config and format all file types it supports, e.g. JS, (S)CSS, Markdown etc.

⚠️ Remember to set up your editor, so that it runs prettier whenever you save a file.

JavaScript Tools

Package Manager: yarn

yarn is more reliable than npm when it comes to installing packages. Additionally it’s supposed to be faster and more secure.

Bundler: parcel or rollup

Parcel has zero config and comes with a cachebusting feature for static projects. We are slowly migrating to it. Rollup uses ES modules as the default module format, has a minimal API and tree shaking for smaller file size. webpack configs tend to become quite large, so we avoid it.

⚠️ Try to use ES modules natively before adding a bundler.

Linter: eslint

Since formatting is already done by prettier we only enable rules that catch errors.

You can find our eslint configuration in our project template.

Task runner: yarn scripts

We try to keep our build processes as simple as possible. Usually some scripts using bash in a package.json are all we need. If the build process is more complex, we write specific node scripts.

We avoid gulp, grunt or other task runners, since getting more knowledge about bash, Make or node comes in handy in many situations.

Polyfills: polyfill.io

We prefer learning standardized APIs instead of third-party libraries, since this knowledge is much more likely to be valid longer than a library. Therefore when it comes to new browser and JS APIs we use them directly and add polyfills for older browsers.

polyfill.io makes this easy, since it allows us to polyfill specific features or serve them automatically with no effort from our side via user agent detection. This means it automatically serves fewer polyfills over time.

⚠️ Check caniuse.com before adding polyfills.

CSS Tools

Linter: stylelint and csslint

Although formatting is done by prettier there are still some linting rules we add to all projects to prevent bugs.

You can find our stylelint configuration in our project template.

To make sure that all projects follow our CSS architecture, we have our own linter, which is open source and free to use. 🙂

Normalize: normalize.css

Although modern browsers have gotten much better in having the same set of default browser styles there are still some differences. Therefore we use normalize.css to reset these differences and to prevent writing browser-specific CSS.

The project has been around for a long time, but is still actively maintained. Additionally it is used and tested by big websites like twitter, GitHub and medium.

CSS custom properties

We use native CSS custom properties and split up CSS files with normal imports. The additional requests are less of a problem with HTTP2.

Image Tools

Placeholder Images

Adding assets like images to a git repository increases its size way faster than code. So we only add assets where we have a good reason why they should not be hosted on a CDN.

For placeholder images we therefore recommend using a service like unsplash.com or placeholder.com.

Performance Optimisation

Most often assets like images make up the biggest amount of page load time, way before JS or CSS. Therefore it’s important to reduce their file size as much as possible without losing quality.

There are other file formats like WebP, but usually people still use JPG and PNG. We recommend using ImageAlpha and ImageOptim to achieve better file sizes for these formats without losing a lot of quality.

Note: You can configure ImageAlpha so that it automatically runs ImageOptim. Just make sure to install ImageOptim and then enable the setting in ImageAlpha.

(For SVGs we usually use SVGO via the command line, as a web app or Mac app.)