Frontend guidelines.md

Frontend guidelines

As frontend developers we are constantly adopting and discovering new ways of developing software. By doing this we are raising the bar of professional software development, creating a community and helping others along the way.

Consider these guidelines as a baseline, the starting point of your software.

General

• The project should have a vision/manifesto.
  • For instance: software craftsmanship manifesto, agile manifesto.
• The project should be written consistent.
  • For instance: EditorConfig, Prettier.
• The project should be reviewed, preferably in the form of a code review.
  • For instance: how to perform a good code review?
• The project should be stored in a versioning system.
• The project should be written according to a methodology.
  • For instance: progressive enhancement.
• The project should have a strategy how to keep it's dependencies up-to-date.
• The project should be tested.
  • For instance: Jest, Cypress, AXE.
• The project should have a code coverage/inspection tool.
  • For instance: Istanbul, Sonarqube.
• The project should have a state management system.
  • For instance: Redux, Apollo.
• The project applies PWA principles where possible.
  • For instance: PWA.
• The project should generate a style guide.
  • For instance: Storybook.

Coding

• Attempt to make use of the best-practice language features when possible.
• Strive for the best fit, therefore follow programming principles.
  • For instance: SOLID, DRY, Boy scout rule.
• Use proven community developed frameworks/libraries over custom builds.

Performance

• The project should be served in the best suitable (minified) format
  • For instance: Critical css, Mustard cut.
• The project should have a minimum score of X.
  • For instance: Lighthouse.
• The performance budget should never be exceeded.

HTML

• Write valid semantic accessible HTML.
  • For instance: W3C Unicorn validator, HTML5 doctor.
• Apply structured data.
  • For instance: Google intro guide.

(S)CSS

• The (s)css should pass the linting rules.
• The class names should be according to a naming convention.
  • For instance: BEM.

JS

• The Javascript should pass the linting rules.
  • For instance: EsLint, AirBnB.
• The Javascript documentation should follow a format.
  • For instance: JSDoc.
• The Javascript should be typed.
  • For instance: TypeScript.

Font

• Apply a font loading strategy.
  • For instance: Filamentgroup, Bram Stein.

Accessibility

• The project should be accessible for people with disabilities.
  • For instance: A11y, Alix.