# Frontend Guidelines By **bendc** ยท Articles A concise, opinionated HTML/CSS/JS style reference for developers who want clear rules over framework churn, illustrated with bad/good code pairs throughout. - Source: https://github.com/bendc/frontend-guidelines - Repository: https://github.com/bendc/frontend-guidelines - Tags: html, css, javascript, best-practices, open-source, style-guide, accessibility, frontend - Pricing: free - Upvotes: 0 ## Features - Concise HTML, CSS, and JavaScript best-practice rules - Each rule shown with a bad-versus-good code example - HTML guidance on semantics, accessibility, and performance - CSS guidance on flow, specificity, layout, and animation - JavaScript guidance on purity, native methods, and readability - Adoptable as a team baseline or onboarding reference --- ## Why it matters Clarity and expressiveness beat micro-optimization: that is the central claim of Frontend Guidelines, and the document states it outright in the JavaScript performance section, calling it the one rule worth memorizing above all others. Most frontend style references bury their philosophy in prose. This one leads with the rule, then proves it with code. ## The big picture Frontend Guidelines, by Benjamin De Cock, is a single-page reference covering HTML, CSS, and JavaScript. Each section is a flat list of named rules, each rule followed by a bad/good code pair. There is no build system to install, no framework to learn, and no prerequisite tooling. The last commit history on GitHub places the document in the mid-2010s, though its principles predate and outlast the framework churn of that era. ## How it works The HTML section covers five areas: semantics (use native elements correctly, or stay neutral rather than misuse them), brevity (drop XHTML habits), accessibility (alt text, real buttons, form labels, no color-only signals), character encoding, and render performance (never block page rendering with a script placed before content). The CSS section spans 14 rules, from box model consistency and selector specificity to a firm stance on animations: only `opacity` and `transform`, and prefer transitions. The JavaScript section opens with its core rule, readability over speed, and then builds outward: pure functions, native methods, rest parameters over `arguments`, spread over `apply`, and array.prototype methods over imperative loops. ## Yes, but The guide predates utility-first CSS workflows like Tailwind, where a global `* { box-sizing: border-box; }` and heavy use of inline class composition are the norm rather than an antipattern. Its CSS specificity and selector rules assume a class-based or BEM-style architecture. Teams running a strict design system with generated utility classes will find several CSS rules in direct tension with their stack. Brad Frost's companion Frontend Guidelines Questionnaire, named in the README, is the right tool for translating these principles into team-specific decisions: it surfaces the methodology questions (BEM, SMACSS, preprocessors, frameworks) that this document deliberately sidesteps. ## The bottom line Read this if you want a fast, unambiguous baseline for a new project or a new team member. Skip it if your stack is already governed by a mature design system or utility-first framework with its own conventions. The concrete next step: open the document at github.com/bendc/frontend-guidelines, then open Brad Frost's Questionnaire alongside it to decide which rules to adopt, adapt, or override for your specific context. ## FAQ ### What is Frontend Guidelines? Frontend Guidelines is a single-page reference document by Benjamin De Cock that collects opinionated best practices for HTML, CSS, and JavaScript. It is hosted on GitHub and has accumulated over 9,100 stars. Every rule is illustrated with a bad/good code pair rather than prose explanation, making it immediately scannable and usable in code review. ### How do I use it? Read the document at github.com/bendc/frontend-guidelines and treat it as a checklist, not a framework. For team adoption, Brad Frost's Frontend Guidelines Questionnaire (github.com/bradfrost/frontend-guidelines-questionnaire) is named as the companion tool: it asks the methodology questions (BEM vs. SMACSS, preprocessors, frameworks) that this document deliberately leaves open. There is nothing to install; the value is in reading and discussing the rules with your team. ### Is it free and open source? The repository is publicly hosted on GitHub and freely readable. The README does not include a license declaration in the source material provided, so the precise license terms are not confirmed here. Treat it as a public reference document and consult the repository directly to verify reuse rights before incorporating it into commercial tooling or documentation. ### What is Frontend Guidelines best for? It is best for teams starting a greenfield project who need an unambiguous baseline fast, and for onboarding new frontend contributors who need shared vocabulary. The bad/good code pair format makes it especially useful as a code review reference, giving reviewers a concrete citation rather than a subjective opinion. It is least useful for teams already governed by a mature design system or utility-first CSS framework with its own conventions, where several of its CSS rules will conflict with the stack. ### How does it compare to a full front-end style guide? Frontend Guidelines is a rules document, not a style guide in the component library sense. Nielsen Norman Group defines front-end style guides (in their article 'Front-End Style Guides: Definition, Requirements, Component Checklist') as modular collections of live UI components with code snippets, like Salesforce's Lightning Design System. Frontend Guidelines makes no attempt to catalog UI components; it sets authoring conventions at the language level. The two are complementary: adopt Frontend Guidelines for code discipline, then build or adopt a component library for design consistency. ### What are the document's limitations? The guide was authored in the mid-2010s and does not address utility-first CSS workflows (Tailwind), modern CSS features like container queries or cascade layers, or contemporary JavaScript patterns like async/await. Its CSS rules assume a selector-based, class-driven architecture, which can conflict directly with utility-first or generated-class systems. Teams on those stacks should use Brad Frost's Questionnaire to document where and why they deviate rather than applying these rules wholesale. --- [View on Analog](https://analoghq.ai/bendc/articles/frontend-guidelines)