Frontend

Framework Choice

React and Next.js. Stay close to framework defaults. Use what the framework offers out of the box.

• Only add external state management when the framework has no solution. When you do, pick the simplest option.
• Prefer popular, well-documented frameworks — accidental complexity is already solved, and AI tools produce better output with established patterns.

Tailwind Over CSS-in-JS

Use Tailwind CSS. Moved away from styled-components.

• Tailwind gives opinionated defaults that prevent drift. Built-in theming, responsive prefixes, small bundle size.
• Styled-components offer flexibility but require building your own design system from scratch. As teams grow, consistency matters more than flexibility.

Component Structure

• Each component lives in its own folder with PascalCase naming.
• Co-locate tests in the same folder — makes missing tests obvious.
• Small presentational sub-components go in a styles file.
• Complex sub-components get their own /components subfolder.
• Use barrel exports via index.ts at every level.
• Use TypeScript path aliases for cleaner imports.

When building custom components, study existing libraries first. Look at naming conventions, props conventions, and implementation patterns from popular projects. Learning-by-reference produces better APIs than designing from scratch.

Unified Stack

TypeScript across the entire stack — frontend, backend, mobile. One language reduces context switching, enables shared helpers and validations, simplifies hiring, and allows code review across projects.

The unified stack is not about JavaScript being the best for everything. It is about reducing friction between teams.

Evolution

• Feb 2026 — rewritten in rule-oriented format from Tailwind, React components, and frontend stack articles.