General Standards

This section contains the guidelines and best practices for front-end web development at Epsilon.

  • Front-end code should be valid and compliant with W3C and WCAG standards, as well as Epsilon's standards outlined in this document
    • No deprecated or non-standard code
    • No console errors
    • All front-end code should be tested across supported browsers and operating systems, and with assistive technology, e.g.: screen readers
  • Front-end code should maintain a separation of concerns
    • Semantic HyperText Markup Language (HTML) for structure
    • Cascading Style Sheets (CSS) for presentation
    • JavaScript (JS) for behavior and interaction
  • Front-end code should be as simple, as clear, and as clean as possible
    • Clever code does not mean good code; readability is critical
    • All code in any codebase should look like a single person typed it, even when many people are contributing to it. Conventions for whitespace, indentation, nesting, capitalization, quote styles, etc. should be established at the start of a project or during major cleanup/refactoring efforts, and enforced by automation, e.g.: code editor settings, linters, etc. Please refer to the various sections of these standards for more information about language-specific formatting
    • Maintain an organized and logical structure in the file system
    • Leave the code a little better than you found it
    • Address tech debt
    • Delete legacy files and dead code
    • Delete commented out code
    • Avoid code comments. Code never lies; comments do. Writing self-explanatory code is a better use of time
    • Use automated code quality tools, e.g.: linters, browser extensions, etc., to provide real-time feedback, automate code quality control, reduce the amount of human code review needed, and enforce best practices and coding standards
    • Configure editor’s formatting settings to align with front-end code standards and linter rules in order to avoid common code inconsistencies and dirty diffs
    • Configure editor to “show invisibles” in order to make white space changes more visible

Accessibility

Accessibility is not a feature — it is a requirement. All new or updated code must conform to WCAG 2.0 (AA). Wherever possible, code should conform to WCAG 2.1 (AAA).

Responsive

Responsive means the layout is flexible, fluid, and device agnostic, and the content reflows and adapts to almost any screen.

Since screen dimensions and width in CSS pixels vary widely between devices, and how people interact with the web across screens continues to evolve rapidly, content should not rely on a particular device type, screen size, viewport width, resolution, orientation, etc. to render well. Instead of thinking about specific devices and dimensions, think about sizes conceptually, e.g.: small, medium, large, extra-large, and focus on creating flexible, fluid, device-agnostic layouts that adapt to almost any screen.

  • Use a responsive layout grid and media queries
  • Take a device-agnostic approach to responsive
  • Start with the smallest breakpoint and work upwards
  • Never hide content
  • Avoid setting fixed dimensions
  • Test on real hardware

Third-Party Libraries

The selection of third-party libraries should be carefully considered and verified with the project team as the appropriate solution to a given problem. "Adding another plug-in" is not always the best solution.

In general, third-party libraries should be open source, lightweight libraries with no dependencies. The feature set should be understood and appropriate. For Angular apps, third-party libraries should be built using TypeScript. Whenever possible, the same third-party library should be used across the product suite to keep the UX consistent and speed up development.

Adding multiple front-end frameworks, e.g.: Bootstrap and Material UI, in the same application is not recommended. Having multiple frameworks that solve the same problem exponentially increases the size of the application and introduces inconsistent interactions, animations, styles, etc. that are difficult to reconcile and maintain.