Front-End manifesto.md

Front-End manifesto

"Well-crafted software over comprehensive documentation" software craftsmanship manifesto.

Therefore this manifesto is as short as possible. See it as an baseline, definiton of done, or the standards of the project.

To help ourself as developers, try to automate the process as far as possible. By using for instance task runners, git hooks and linters.

General

• To write consistent coding styles between different editors and IDEs use the EditorConfig.
• The code should be reviewed, preferably in the form of a code review.
  • Further reading: how to perform a good code review?.
• The code should be stored in a version control system.
• The code should be written according to the progressive enhancement methodology.
• Always try to make use of the best-practice language features when possible.
• Be a profesional and strive for the best fit, therefore follow programming principles like SOLID, DRY, boy scout rule.
• Serve the files in best minified format.

Performance

• The website should have a minimum score of 85 in the Google PageSpeed Insights tests.
• The website should have a minimum score of X in the webpagetest tests.
• The (performance) budget should never be exceeded.

HTML

• Write valid semantic HTML.
  • Further reading: W3C Unicorn validator, html5 doctor.
• Apply ARIA when needed.
  • Further reading: Gist Wouter Kroes, Alix.
• Apply structured data when needed.
  • Further reading: Google intro guide, Structured Data.

(S)CSS

• The classnames should be according to a naming convention.
  • Further reading: BEM.
• Use Normalize to makes browsers render all elements more consistently and in line with modern standards.
• The SCSS should pass the Stylelint linting rules.

JS

• Indicate a difference between publics and privates, by prefixing a private with a _.
• The JavaScript should pass the unit tests.
  • Further reading: Mochajs, Sinonjs.
• The JavaScript should pass, the static code analysis tests.
  • Further reading: SonarQube.
• The JavaScript should pass the Eslint linting rules.
• Use JSDoc as the preferred documentation format.
• Only use a framework when this truly adds value. When a present framework is not longer needed, refactor it out

Font

• Apply a font loading strategy.
  • Further reading: Filamentgroup, Bram Stein.

nice