Complete English Guide for Frontend Developers

Why English Matters for Frontend Developers

Frontend development sits at a unique intersection of technical engineering and design — and both fields have their own English vocabulary. A frontend developer must be able to read a Figma comment from a designer, translate a vague "it doesn't look right" into a precise CSS problem statement, discuss Core Web Vitals scores with a product manager, write accessible HTML that includes the right ARIA attribute descriptions, and review a colleague's component API documentation for clarity. Each of these tasks requires a different kind of English fluency.

Frontend engineering is also uniquely visible. The work a frontend developer produces is seen directly by end users, meaning that written content within the product — error messages, empty state copy, ARIA labels, button text — carries real business weight. The ability to write clear, user-friendly English for UI copy is a practical frontend skill, not an extra.

Additionally, frontend has one of the richest ecosystems of English-language resources — MDN Web Docs, CSS-Tricks, Smashing Magazine, the React and Vue documentation, W3C specifications, and WCAG guidelines are all written in English and are the primary references for professional frontend developers worldwide. Reading and understanding technical English at the level of these resources is a daily requirement for staying current.

The sections below cover the specific registers and vocabulary you need as a frontend developer: the naming conventions of CSS architecture, the language of component APIs and Storybook documentation, the precise vocabulary of web accessibility, the data-driven language of performance optimisation, and the collaborative English of design-to-development handoff.

Section 1: CSS & JavaScript Naming Convention English

CSS and JavaScript naming is not just a technical concern — the names you choose communicate meaning to every developer who reads your code. Discussing naming conventions in English requires vocabulary for both the technical patterns and the reasoning behind them.

BEM and CSS Architecture Vocabulary

BEM (Block Element Modifier) is the most widely discussed CSS naming methodology in English. The vocabulary: a "block" is a standalone component (e.g., .card), an "element" is a part of a block (e.g., .card__title), and a "modifier" is a variant or state (e.g., .card--featured). In code reviews, you might write: "I'd suggest using BEM naming here — the current flat class names make it hard to understand component boundaries." or "This modifier name is ambiguous — .btn--primary is clearer than .btn--blue because it expresses intent, not appearance."

Other CSS architecture vocabulary includes "specificity" (how the browser resolves conflicting styles — described as "high specificity" or "low specificity"), "cascade" (the C in CSS — styles flow from parent to child), "utility classes" (single-purpose classes like Tailwind's mt-4), "design tokens" (named values for colours, spacing, and typography shared between design and code), and "CSS custom properties" (CSS variables).

JavaScript and Component Naming

Component naming discussions use vocabulary like "descriptive vs. generic names," "PascalCase for components," "camelCase for variables and functions," "kebab-case for file names," and "SCREAMING_SNAKE_CASE for constants." When reviewing naming in a PR: "I'd rename this to UserProfileCard — the current name Card is too generic for this use case." / "This prop name handleClick is a bit redundant — since event handlers are conventionally prefixed with on, onClick would be more idiomatic." / "The file name utils.js is a catch-all — consider splitting by domain: dateUtils.js, stringUtils.js."

Section 2: Component Documentation Language

Documenting UI components — whether in Storybook, a README, or a design system wiki — requires a specific kind of technical writing. The audience is other developers who need to understand the component's API, its expected behaviour, and its edge cases. Component documentation is often the first touchpoint a developer has with your work, which makes clarity doubly important.

Writing Component Descriptions

A component description should answer: what is this component for? When should you use it? What props does it accept? What accessibility features does it include? What are its visual variants? Good descriptions use the imperative mood for instruction and the present tense for description: "Use Button for all interactive actions. Prefer Link for navigation." "Renders a clickable button element. Supports three visual variants: primary, secondary, and ghost." "Accepts an optional icon prop to render a leading icon — icon should be a React element."

Prop Documentation Conventions

Each prop description should include: the prop name, its TypeScript type, whether it is required or optional, its default value if optional, and a clear description of what it controls. "disabled: boolean — optional, defaults to false. When true, the button is not interactive and is rendered with reduced opacity." / "variant: 'primary' | 'secondary' | 'ghost' — required. Controls the visual appearance of the button." Notice the pattern: short, active, specific. Never just restate the prop name.

Storybook and Design System Language

Storybook documentation uses terms like "story" (a single rendered instance of a component), "controls" (the interactive props panel), "args" (the props passed to a story), "decorators" (wrappers applied to stories), "add-ons," and "canvas" vs. "docs" views. Design system language includes "component library," "token," "variant," "density" (compact vs. comfortable spacing), "pattern" (a reusable UI solution), and "composition" (building complex UIs from simple components).

Section 3: Accessibility (a11y) Communication

Web accessibility is a technical and ethical requirement, and its English vocabulary is dense with acronyms and specialised terms. Being able to discuss accessibility clearly — in code reviews, design reviews, and bug reports — is a marker of professional frontend maturity. It also matters for compliance: WCAG (Web Content Accessibility Guidelines) documentation is written in English and is the global standard.

WCAG and Accessibility Standards Language

WCAG defines accessibility requirements at three levels: A (minimum), AA (mid-range, the typical legal requirement), and AAA (highest). Requirements are described as "success criteria." When discussing compliance: "This component doesn't meet WCAG 2.1 AA — the colour contrast ratio between the text and background is 3.2:1, but AA requires at least 4.5:1 for normal text." / "We need to add a visible focus indicator — the current styles remove the default outline without providing an alternative, which fails WCAG 2.4.7 Focus Visible."

ARIA Attribute Language

ARIA (Accessible Rich Internet Applications) attributes have specific vocabulary: "role" defines what an element is ("This div needs role='button' since it's not a native <button> element."), "aria-label" provides an accessible name ("Add aria-label='Close dialog' to the X button — the icon alone has no text content."), "aria-describedby" links an element to a description, and "aria-live" announces dynamic content changes to screen readers. Common review phrasing: "This interactive element is missing an accessible name — add aria-label or include visible text content." / "The error message should use aria-live='polite' so screen readers announce it when it appears."

Accessibility in Design Reviews

When reviewing designs for accessibility, use precise vocabulary: "The touch target is 32x32px — WCAG 2.5.5 recommends a minimum of 44x44px." / "This modal doesn't trap focus — users can tab out of the modal and interact with the page behind it." / "There's no keyboard-accessible alternative to the drag-and-drop interface." / "The tooltip only appears on hover — keyboard users won't be able to access it." These observations translate design decisions into concrete technical accessibility requirements.

Section 4: Performance & Core Web Vitals Language

Web performance is a discipline with a rich quantitative vocabulary. When discussing performance with teammates, product managers, or stakeholders, you need to speak precisely about metrics, thresholds, and their user impact. Core Web Vitals are Google's standardised performance metrics and have become the industry vocabulary for performance discussions.

Core Web Vitals Vocabulary

The three Core Web Vitals are: LCP (Largest Contentful Paint — measures perceived load speed, the time until the largest visible element appears), FID/INP (First Input Delay / Interaction to Next Paint — measures interactivity and responsiveness to user input), and CLS (Cumulative Layout Shift — measures visual stability, how much the page unexpectedly shifts while loading). Each has a "good," "needs improvement," and "poor" threshold. "Our LCP is currently 4.2 seconds — we're in the 'poor' range. The target is under 2.5 seconds for a 'good' score." / "The CLS score of 0.28 is causing visible layout shifts on slow connections — we need to reserve space for images that load asynchronously."

Performance Optimization Language

Discussing optimisation requires vocabulary for both diagnosis and solution. Common diagnosis vocabulary: "render-blocking resource" (a script or stylesheet that prevents the page from rendering), "critical rendering path" (the steps the browser must complete before displaying content), "JavaScript bundle size" (the total size of JS files downloaded), "tree shaking" (removing unused code from bundles), "code splitting" (dividing a bundle into smaller chunks loaded on demand), and "cache hit rate" (the proportion of requests served from cache). Solution vocabulary: "lazy loading" (deferring the loading of off-screen resources), "preloading" (hinting the browser to fetch critical resources early), "minification," "compression," and "CDN delivery."

Practical discussion patterns: "The performance audit shows we have a 380kb JavaScript bundle — a significant portion is a date library we're only using for one formatting function. We should either import only that function or replace it with a smaller alternative." / "The hero image is not preloaded, which is contributing to the poor LCP — adding a <link rel='preload'> should improve it significantly."

Section 5: Design Handoff & Collaboration English

Frontend developers work more closely with designers than any other engineering role. The design-to-development handoff process generates a specific kind of communication — asking clarifying questions about designs, flagging technical feasibility concerns, negotiating implementation trade-offs, and giving feedback on design proposals from a developer's perspective.

Asking Clarifying Questions About Designs

Good clarifying questions are specific and reference the design directly: "In the mobile view, what should happen when the table has more than 5 columns? The current design doesn't seem to account for overflow." / "What is the empty state for this list — if there are no results, should we show a message or hide the component entirely?" / "The spacing between these cards appears to be 24px in the desktop design — is this a fixed value or should it adjust with the viewport?" These questions use precise vocabulary (viewport, overflow, empty state, spacing) and reference specific numbers from the design.

Flagging Technical Feasibility

When a design requires an unusual or expensive technical implementation, the convention is to raise this early and offer alternatives: "This parallax scrolling effect is achievable, but it will hurt performance on mobile devices — scroll-linked animations trigger style recalculations on every frame. Would a simpler fade-in animation achieve a similar feel?" / "The proposed multi-level dropdown is technically complex and has accessibility challenges. Could we explore a mega-menu pattern instead? It's more conventional and already has accessible patterns documented in ARIA Authoring Practices." Always frame feasibility concerns as alternatives rather than hard blocks — "we could try X instead" rather than "this isn't possible."

Design Token and Handoff Vocabulary

Modern design handoff uses Figma, Zeplin, or similar tools that produce design specifications. Vocabulary: "design spec" (the detailed documentation of a design including dimensions, spacing, and colours), "redline" (annotations showing exact measurements), "responsive breakpoint" (the viewport width at which the layout changes), "auto layout" (Figma's flexible layout system, analogous to CSS flexbox), "component instance" (a reuse of a master component).

Section 6: Browser Compatibility Language

Browser compatibility is a perennial frontend concern and generates specific vocabulary for discussing support matrices, polyfills, progressive enhancement, and graceful degradation. Communicating about browser support clearly — especially to product managers and stakeholders who may not understand the technical details — is a key frontend skill.

Support Matrix and Browser Support Vocabulary

A "browser support matrix" or "browser support policy" defines which browsers and versions the application officially supports. Vocabulary: "evergreen browsers" (browsers that auto-update — Chrome, Firefox, Edge), "legacy browsers" (older versions, typically IE11 or older Safari), "baseline" (the set of web features now broadly available across all major browsers — a relatively new W3C concept), "graceful degradation" (building for modern browsers first and ensuring older browsers still get a functional, if less rich, experience), and "progressive enhancement" (building a base functional experience first and adding enhancements for capable browsers).

When discussing browser support in code reviews or planning: "This CSS container query is not yet supported in Safari 15 — if we need to support Safari 15, we'll need a fallback." / "I've checked Can I Use — the aspect-ratio property has 97% global support, so we can safely use it without a fallback." / "We could use the native CSS :has() selector here, but it's only in our officially supported browsers since last quarter — worth checking with the team before relying on it."

Polyfill and Transpilation Language

A "polyfill" is code that provides functionality that a browser doesn't natively support. "Transpilation" (done by Babel or TypeScript) converts modern JavaScript to a version compatible with older environments. "Bundling" combines multiple files into one. You "target" specific browser versions in your build configuration. "Vendor prefixes" (-webkit-, -moz-) are legacy mechanisms for experimental CSS features.

Section 7: Frontend Interview English

Frontend interviews at modern tech companies typically include a JavaScript/TypeScript coding round, a CSS/HTML knowledge test, a system design round (often focused on UI architecture or design system design), and behavioural questions. Each requires slightly different English strategies.

Explaining JavaScript Concepts

Common JavaScript interview questions require you to explain complex concepts in plain English. Key formulations: "Closure is a function that retains access to the variables of its outer scope even after the outer function has returned. Concretely, if I write..." / "The event loop processes the call stack first, then the microtask queue, then the macrotask queue. In practice, this means..." / "I'd describe the difference between null and undefined as..." Use the pattern: define the concept in one sentence, then give a concrete example.

CSS Specificity and Layout Explanations

Interviewers often ask you to explain CSS specificity, the box model, or flexbox vs. grid. Use the structure: explanation + example + when to use. "CSS specificity determines which rule wins when two selectors target the same element. It's calculated as a four-part value — inline styles win over IDs, which win over classes, which win over element selectors. In practice, I try to keep specificity low by avoiding IDs and deeply nested selectors."

Most Useful Vocabulary & Phrases for Frontend Developers

Recommended Learning Path for Frontend Developers

1. 1

   CSS & Frontend Vocabulary

   Build your foundation with the core vocabulary of CSS layout, the box model, specificity, and modern CSS features.

2. 2

   Code Review exercises

   Learn to give and receive constructive feedback on frontend code, including naming, structure, and accessibility issues.

3. 3

   Accessibility Language exercises

   WCAG vocabulary, ARIA attribute language, and how to articulate accessibility requirements in design and code reviews.

4. 4

   Technical Writing exercises

   Component documentation, API descriptions, and the conventions of clear technical writing.

5. 5

   Product Design Language

   The vocabulary for design collaboration, design system discussions, and design review meetings.

6. 6

   Performance Profiling Language

   Core Web Vitals vocabulary and the language for discussing and reporting on web performance.

7. 7

   Frontend Interview Questions

   Practice answering the most common frontend interview questions — JavaScript concepts, CSS challenges, and UI architecture.

8. 8

   Remote & Async Communication

   Written communication for distributed frontend teams — standup updates, design feedback, and async handoff messages.

Exercise Sets for Frontend Developers

Practise the vocabulary and communication patterns covered in this guide with these focused exercise sets: