The unspoken rules of frontend development (and a checklist to follow them)

Nobody hands you a rulebook when you start as a frontend developer. The task description covers what to build. The design file covers how it should look. But the standards your team actually judges your work by? Those live in people's heads — until you get a long list of pull request comments and wonder what you missed.

I spent my first year as a frontend developer at a large consultant firm in Denmark learning these rules the hard way. My primary framework was Angular, but every point in this post applies regardless of what stack you work in.

Here is what I wish someone had told me from day one.

The 11 unspoken rules of frontend development

• Use a consistent coding style throughout the project.
• Optimize for performance and load time — and track your Core Web Vitals.
• Test on different devices and browsers.
• Write code that other developers can read and understand.
• Understand the underlying HTML and CSS — don't hide behind frameworks.
• Design and code with accessibility in mind.
• Use animation intentionally to improve user experience.
• Use version control effectively and collaborate well.
• Find clean solutions — not quick fixes.
• Use AI tools responsibly — own every line you ship.
• Welcome feedback and act on it.

These are the real acceptance criteria on any professional frontend team. Here is how to meet each one.

1. Consistent coding style

Inconsistent code slows down code reviews, creates merge conflicts, and signals to senior developers that you don't yet think in terms of the whole team.

How to do it:

• Pick an established style guide (for Angular: the official Angular Style Guide or John Papa's Angular Style Guide)
• Install ESLint and configure it to enforce the rules automatically
• Add Prettier for automatic formatting on save
• Document your team's conventions in the repository readme
• Enforce it through CI — not just individual discipline

The goal is that any developer on the team could write any file and it would look identical.

2. Performance and load time

Users leave if a page takes more than 3 seconds to load. Performance is not an optional polish step — it's a core requirement.

Practical techniques:

• Lazy-load Angular modules so only what's needed loads on each route
• Use Angular SSR (formerly Angular Universal) for server-side rendering to improve initial load
• Store static assets (images, fonts) on a CDN
• Cache API responses where appropriate
• Minimize the number of HTTP requests per page
• Compress and resize images before serving them
• Track your Core Web Vitals — LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift) are Google's performance benchmarks and affect both SEO and user experience
• Measure with Lighthouse or WebPageTest — not guesswork

3. Cross-device and cross-browser testing

A feature isn't done until it works everywhere your users are — not just in Chrome on your MacBook.

Testing approaches:

• Use BrowserStack or Sauce Labs for real device and browser testing without owning every device
• Write end-to-end tests with Playwright that run across multiple browsers in CI
• Test on real mobile hardware whenever possible — emulators miss edge cases
• Check on at least Chrome, Firefox, Safari, and Edge before marking a task complete

4. Readable, maintainable code

Code is read far more often than it is written. Optimise for the next developer, not for your current deadline.

Practices that help:

• Name variables, functions, and classes to describe their purpose clearly — no abbreviations or cryptic names
• Comment the why, not the what — if the code itself doesn't explain what it does, rename it
• Document the inputs, outputs, and side effects of every function
• Follow the SOLID principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
• Use TypeScript — it's effectively mandatory on professional teams now, and it makes code self-documenting in a way that comments never fully achieve
• Keep formatting consistent so diffs show logic changes, not whitespace noise

5. Know your HTML and CSS

Frameworks come and go. Developers who understand the platform underneath them adapt to anything. Developers who only know the framework hit walls constantly.

What this means in practice:

• Understand the CSS box model, flexbox, and grid at a deep level — not just how to copy snippets
• Know when to reach for a framework utility and when vanilla CSS is cleaner
• Understand how the browser renders HTML, and why semantic structure matters for both SEO and accessibility
• Be able to build a layout from scratch without a UI library when needed

6. Accessibility

Accessibility is not a nice-to-have. It's a legal requirement in many countries and a quality signal every serious team cares about.

Core practices:

• Use semantic HTML:
• Add descriptive alt text to every image
• Ensure sufficient colour contrast (Web Content Accessibility Guidelines — WCAG — minimum AA level)
• Make all interactive elements keyboard-navigable
• Test with a screen reader (VoiceOver on Mac, NVDA on Windows)
• Run automated checks with axe DevTools or Lighthouse's accessibility audit

The Web Content Accessibility Guidelines (WCAG) 2.2 AA is the current baseline standard to meet, released in October 2023.

7. Animation

Good animation makes a UI feel responsive and alive. Bad animation makes it feel slow and distracting. The difference is intent.

How to develop good animation instincts:

• Master CSS transitions and keyframe animations before reaching for a library — native CSS has caught up significantly and covers most use cases
• Use GSAP (GreenSock Animation Platform) for complex, timeline-based sequences
• Animate state changes (hover, focus, loading, error) — not decoration
• Respect prefers-reduced-motion for users who need it

8. Version control and collaboration

Git hygiene is invisible when it's good and painful when it's bad.

What good collaboration looks like:

• Write commit messages that explain why the change was made, not just what changed
• Keep pull requests small and focused — one logical change per PR
• Review your own pull request before requesting review from others
• Respond to review feedback promptly and without defensiveness
• Never commit directly to main

9. Clean solutions over quick fixes

A hack that works today becomes a bug someone else has to fix in six months. On a professional team, technical debt is visible — and attributed.

The discipline:

• Understand the root cause before writing any fix
• If you're working around a framework limitation, document it explicitly
• If a quick fix is genuinely the right call (time pressure, limited scope), leave a comment explaining why and create a follow-up ticket
• Refactor as you go — leave the code cleaner than you found it

10. Use AI tools — but own the output

AI coding assistants (GitHub Copilot, Cursor, Claude) are now a standard part of the frontend workflow. The unspoken rule isn't whether to use them — it's how.

What matters:

• Treat AI-generated code the same as any other code you didn't write yourself: read it, understand it, and test it before submitting
• Don't let autocomplete make architectural decisions — those still require judgement
• Use AI well for boilerplate, test generation, and first drafts of repetitive patterns
• The quality bar on your pull request doesn't change because AI helped you write it — if anything, reviewers will scrutinise it more carefully

AI accelerates output. It doesn't replace the responsibility to understand what you're shipping.

11. Openness to feedback

Pull request comments are not personal. They are how knowledge transfers between developers. The fastest way to improve is to treat every comment as free education.

In practice:

• Ask questions in code review, don't just click approve
• When you receive feedback, understand why before applying the fix
• When you give feedback, explain the reasoning — not just the correction
• Thank reviewers for thorough reviews

---

Frontend development checklist

Use this at your desk. It's split into three phases to catch issues before, during, and after a task.

Before starting

• Read the full task description and user acceptance criteria
• Review the design file and design system
• Check if a similar component already exists in the codebase
• Clarify ambiguities before writing a line of code

During development

• Follow the team's coding style and linter configuration
• Keep performance implications in mind (lazy loading, image sizes, request count)
• Write code that's readable without relying on comments to explain it
• Test in the browser as you build — not only at the end

Before submitting your pull request

• Test across Chrome, Firefox, Safari, and Edge
• Test on at least one mobile device
• Run the accessibility audit in Lighthouse
• Review your own diff as if you were a senior developer seeing it for the first time
• Check that all acceptance criteria are met

---

Frequently asked questions

What is the most important unspoken rule for junior frontend developers?

Write code for the next developer, not for yourself. Readable, well-structured code reduces review time, speeds up onboarding, and signals professional maturity faster than any other habit.

How do I improve as a frontend developer quickly?

Review pull request feedback seriously, read the code of experienced developers on your team, and build small side projects where you experiment with things you haven't mastered yet. Deliberate practice beats passive experience.

What tools do professional frontend developers use for code quality?

ESLint and Prettier for style enforcement, Playwright for end-to-end testing, Lighthouse for performance and accessibility auditing, and BrowserStack for cross-browser testing.

What is WCAG and why does it matter for frontend developers?

WCAG stands for Web Content Accessibility Guidelines, the international standard for web accessibility. The current version is WCAG 2.2 (released October 2023). Meeting AA level means your site is usable by people with visual, motor, auditory, and cognitive disabilities — and is a legal requirement in the EU, UK, and many other jurisdictions.

What are Core Web Vitals and why should frontend developers care?

Core Web Vitals are Google's three key performance metrics: LCP (Largest Contentful Paint — how fast the main content loads), INP (Interaction to Next Paint — how responsive the page is to input), and CLS (Cumulative Layout Shift — how stable the layout is). They directly affect search ranking and are the clearest signal of whether a page feels fast to real users.

Happy coding 👩🏽‍💻