Tools we use
Here is a list of tools we primarily use including information on why we don’t use (sometimes popular) alternatives.
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.
Continous Integration: travis
We use travis for continuous integration. It lints the code, runs tests, builds it for production and deploys it to production/staging servers.
yarn is more reliable than
npm when it comes to installing the same packages. Additionally it’s supposed to be faster and more secure.
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.
The standard for transpiling the latest EcmaScript version to a version, which more browsers support.
⚠️Try using new features first and check ES compatibility tables before adding transpilation.
Since formatting is already done by
prettier we only enable rules that catch errors.
You can find our
eslint configuration in our project template.
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.
grunt or other task runners, since getting more knowledge about
node comes in handy in many situations.
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.
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.
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 currently test removing Sass from our build process to make development faster and more reliable. (no source maps or build step)
This means we replace Sass variables with native CSS custom properties and split up CSS files with normal imports. The additional requests are less of a problem with HTTP2. Mixins can be replaced by classes.
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.
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.