Why We Don’t Use Block Libraries at Equalize Digital 🔗 **Source:** [Why We Don’t Use Block Libraries at Equalize Digital](https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/) > [!note]+ Document Notes > tags: [WordPress, accessibility, web-development] > author: Amber Hinds > source: amberhinds.com > reference: [https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/] > date created: 2026-01-18 10:00 > > # 🏷️ Title: Why We Don’t Use Block Libraries at Equalize Digital > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: Amber Hinds explains why Equalize Digital avoids third-party block libraries/page builders and prefers core and custom/ACF blocks. - Why it matters: Block libraries can introduce long-term risk: breaking changes, abandoned projects, accessibility issues, performance bloat, and redesign lock-in. - Key stakeholders: Agencies, enterprise WordPress teams, small-business implementers, plugin authors, clients with legal/compliance requirements. - Risks and tradeoffs: Faster initial builds vs. long-term maintenance, accessibility, performance, security, and redesign flexibility. - Bottom line: For enterprise/mission-critical sites, custom/core blocks provide more control and stability; block libraries remain fine for low-risk, low-budget sites. ## 📖 Main Content - The article begins with a question about why Equalize Digital doesn’t rebuild its site with an accessible library like Kadence. Hinds clarifies they “use and love core blocks” but avoid block libraries. - She cites her own site, rebuilt on Twenty Twenty‑Four with only core blocks, eliminating “thousands of accessibility issues” and improving performance while keeping the site visually identical even with all plugins disabled. - Historically, her agency used block libraries and some page builders to build sub‑$20k sites quickly. Over time, painful experiences with multiple libraries—renames, changed CSS class names, altered stylesheet load order, and abandonment with security issues—eroded trust in vendor-controlled foundational components. - She emphasizes that when a block library controls core layout and interactive elements across a site, deprecations or abandonment can effectively force a rebuild “even if you didn’t change the theme.” - Equalize Digital’s work shifted toward higher-budget enterprise-style projects (government, higher ed, healthcare, publishers). In this context, every plugin adds risk: accessibility, security, performance, and UX decisions outside the team’s control. Those risks compound at scale. - The team’s strategy: use core blocks wherever possible; if something is missing (e.g., tabs), build custom or ACF blocks rather than pulling in a block library. - She distinguishes between types of plugins: complex, mission‑critical functionality such as forms, e‑commerce, payments, CRMs, and API integrations should usually be handled by mature third‑party plugins with dedicated teams and continuous updates. This is very different from relying on a visual block library for foundational layout/UI. - Hinds notes that if a custom tab block needs minor styling changes, that’s “trivial work” compared with the complexity of maintaining something like Stripe API compatibility—so block libraries don’t justify the same risk profile as serious application plugins. - For small, non‑mission‑critical sites (restaurants, salons, churches, small nonprofits), off‑the‑shelf themes, block libraries, and page builders are “just fine” and often ideal, especially where budgets are tiny and the builder may not be a developer. - Equalize Digital treats its own website like an enterprise property: careful about updates, no autoupdates, scrutiny over every plugin, high expectations for uptime, polish, and performance because it’s a sales channel. - She dislikes “surprise” features or breaking updates from block libraries and accepts slower initial builds with custom blocks in exchange for fewer maintenance surprises, less to test, and more peace of mind. ### 🗒️ Notes - Hinds frames the discussion around a public question on social media: if accessible block libraries exist, why custom? She uses this as a springboard into broader plugin governance and risk management. - She has firsthand evidence that moving from a premium theme to a core theme and blocks can immediately reduce accessibility issues and improve performance, and that using only core blocks allows the site to function even with plugins disabled. - Early in the block editor era, her agency relied on free block libraries to speed delivery of visually rich sites for smaller clients. - She recounts four failure modes with different libraries: - Acquisition and deprecation, forcing migration to a renamed product with changed class names. - Class name changes breaking all custom styling. - Stylesheet load-order changes that override theme styles. - Abandonment and removal from the repo due to security issues, with no viable removal path because the blocks were too widespread. - These experiences led to a loss of trust in third-party vendors controlling structural/UI layers of a site. - As project sizes and stakes grew, Equalize Digital raised the bar for plugins: they now consider legal compliance, security, accessibility, conversion, and long‑term maintainability. - The article distinguishes architectural roles: - Foundational presentation and layout blocks should be stable and under close control (core/custom). - Mission-critical application logic (forms, e‑commerce, payments, CRMs) is often better handled by specialized plugins with strong maintenance. - She warns that block libraries, like page builders, can create deep vendor lock‑in for content; a future redesign may require touching “hundreds or more pages.” - She recommends: - Only core blocks in blog posts. - Prefer core container blocks (columns, grids) over third-party containers. - She acknowledges that block libraries serve a valuable role for non‑enterprise, low‑budget contexts where some downtime or layout issues are acceptable tradeoffs. - Equalize Digital opts out of that tradeoff because their site must continually convey trust and high polish to enterprise buyers. - She accepts slower greenfield development (writing custom blocks) as a net win, because there’s less to retest for each update and fewer unknowns. ## 📚 References - WordPress block editor (Gutenberg): https://wordpress.org/documentation/article/wordpress-block-editor/ - Twenty Twenty‑Four theme: https://wordpress.org/themes/twentytwentyfour/ - Advanced Custom Fields (ACF): https://www.advancedcustomfields.com/ - Kadence Blocks: https://www.kadencewp.com/kadence-blocks/ - Elementor: https://elementor.com/ - WCAG 2.2 guidelines: https://www.w3.org/TR/WCAG22/ ## 🗣️ Paraphrase - Paragraph A paraphrase: Equalize Digital intentionally avoids relying on third‑party block libraries for core site structure, instead favoring WordPress core blocks and custom/ACF blocks to avoid breaking changes, vendor abandonment, and loss of accessibility and performance control—especially on enterprise-style projects. - Paragraph B paraphrase: Block libraries remain valuable tools for low‑budget, low‑risk sites where speed and ease of use matter more than long‑term maintainability, but for mission‑critical websites that must be performant, compliant, and stable, the safer pattern is to buy specialized plugins only for complex, business-critical features and build foundational blocks in-house. ## 📰 Newsletter In this week’s WordPress accessibility and architecture spotlight, Amber Hinds walks through why Equalize Digital has stepped away from block libraries and page builders for core site structure. By rebuilding on Twenty Twenty‑Four and core blocks, she eliminated thousands of accessibility issues and gained dramatic performance wins—with fewer plugin‑update surprises. If you’re building enterprise or compliance‑sensitive sites, consider tightening your stack: core + custom blocks for layout, and carefully vetted plugins only for truly complex functionality (forms, e‑commerce, CRMs, payments). For small local businesses and non‑critical projects, high‑quality libraries like Kadence remain a practical and cost‑effective option—but understand the future maintenance bill before you commit your content to them. ## ✅ Action Items #### DevRel - Document and share best practices for “core + custom blocks only” architectures targeted at agencies doing enterprise work. - Create demo repos and tutorials showing how to replace common library patterns (tabs, accordions, grids) with accessible custom blocks. - Build example CI pipelines that highlight plugin risk evaluation (accessibility, performance, security baselines). - Publish case studies comparing long‑term maintenance costs of block libraries vs. custom blocks. #### OSPO - Define policy around where third‑party block libraries are acceptable vs. prohibited in organization‑owned WordPress instances. - Require license and maintenance review for mission‑critical plugins; discourage libraries that control foundational layout. - Integrate plugin scanning for known vulnerabilities and accessibility regressions into standard review cadence. - Maintain an approved plugin catalog differentiating structural blocks vs. application‑level plugins. #### Community - Provide maintainers with templates for documenting breaking changes (CSS class names, markup, load order) and deprecation plans. - Offer contributors clear onboarding paths to help harden accessibility and backward compatibility in popular block libraries. - Encourage sponsors to fund work on long‑term maintenance, security, and accessibility audits for widely used libraries. - Coordinate incident response drills around major plugin deprecations or removals, sharing playbooks across agencies. #### WordPress - Core: Continue expanding core block coverage (tabs/accordions/layout patterns) to reduce pressure to adopt third‑party block libraries. - Core Performance: Measure performance impact of block libraries vs. core/custom-only patterns; surface metrics in Site Health. - Core AI: Ensure any AI-assisted pattern generation favors core blocks and accessible, stable structures. - **Core Program Team:** Align block roadmap with real-world enterprise needs (accessibility, long-term stability, migration paths). - Mobile: Improve editing experiences for core blocks so mobile content managers don’t need page builders to stay productive. - Playground: Provide lab setups for testing plugin update scenarios and visual regressions when block libraries change. - Community: Include sessions at meetups/WordCamps on plugin governance, long‑term maintenance, and architectural risk. - Training: Publish lessons on “when to choose libraries vs. core + custom” with accessibility and performance examples. - Marketing: Emphasize success stories of high‑end sites built largely on core and custom blocks. - Support: Build knowledge base content around recovering from abandoned or deprecated block libraries. - Design: Provide opinionated design tokens and patterns for core blocks to reduce perceived need for design-heavy libraries. - Documentation: Expand guides on building custom blocks (including ACF-based) with strong accessibility defaults. - Photos / TV / Polyglots: Not directly implicated but can highlight accessible, core‑based site showcases globally. - Accessibility: Maintain block‑level accessibility standards; provide guidance for plugin authors to align. - Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Encourage plugin scoring and surfacing of backward compatibility, maintenance history, and perf/accessibility impact. - Offer linting and scaffolding for plugin authors to avoid breaking changes to markup and CSS. - Hosters can flag high‑risk libraries and provide safer defaults. #### The WPOCC - Programs: Support maintainers of core-adjacent plugins (forms, e‑commerce) with accessibility and stability grants. - Projects: Run documentation and migration clinics for agencies stuck on deprecated libraries/page builders. - Funding experiments: Sponsor gradual refactors from library-heavy stacks to core + custom patterns on exemplar sites. ### FAIR - Technical independence: Promote architectures where essential layout content is portable (core/custom) rather than locked into third‑party blocks. - Policies and covenants: Encourage plugin maintainers to adopt clear deprecation and compatibility covenants. - Productized governance artifacts: Provide scorecards for plugin risk (maintenance, access, perf) that agencies can reuse in procurement. ## 🧪 Hypotheses - H1: Enterprise WordPress sites using only core/custom blocks experience fewer breaking layout changes during plugin updates than those relying on block libraries. - H2: Migrating from premium themes/page builders to core themes and blocks measurably reduces accessibility violations. - H3: The presence of third-party block libraries increases average page load times compared to equivalent core/custom implementations. - H4: Small-business sites built with block libraries achieve similar business outcomes (leads, calls) at lower upfront cost than custom builds. - H5: Organizations that treat their marketing sites as mission-critical assets adopt stricter plugin governance and fewer visual libraries. ### 📊 Methodology - H1/H3: Longitudinal study of a cohort of enterprise sites; track plugin updates, visual regressions, and Lighthouse/WebPageTest metrics, categorizing sites by architecture. - H2: Before/after accessibility audits (axe, WAVE, manual WCAG checks) on sites migrating from page builders/premium themes to core‑first builds. - H4: Compare small‑business sites across two groups (library vs. custom) on cost, time‑to‑launch, and simple KPIs (contact form submissions, calls). - H5: Survey of organizations on plugin policies, perceived criticality of website, and composition of their plugin stacks; analyze correlations. ### ❓ Questions - How can plugin authors better communicate breaking changes before release to agencies maintaining many sites? - What tooling could automate detection of CSS/markup changes that might break custom styling when updating a block library? - Where should WordPress core stop in terms of block coverage before it begins competing too directly with third‑party libraries? - Can content models or block patterns be designed to minimize lock‑in, even when libraries are used? ### 🔮 Future Research - Develop standardized “plugin risk profiles” combining maintenance history, security, accessibility, and performance scores. - Explore migration strategies and tools to convert legacy library-based content into core/custom blocks at scale. - Study long‑term TCO (total cost of ownership) of different WordPress architectures across agency portfolios. - Investigate how much accessibility debt typically accumulates when small sites use popular page builders or block libraries without audits. ### 💡 Implications - Practice: Agencies should adopt explicit guidelines for when block libraries are allowed, favoring core/custom for foundational layout. - Policy: Large organizations may need plugin review boards to approve structural plugins and enforce compatibility standards. - Security: Reducing third‑party dependencies that control critical markup lowers the blast radius of abandoned or compromised plugins. - Education: Training materials should emphasize long‑term architectural consequences of plugin choices, not just build speed. - Funding: Supporting core and key ecosystem plugins that reduce pressure to adopt risky libraries is a strategic investment. ### 🧠 Learning Styles Assessment - Reading level estimate: Around grade 9–11 (Flesch–Kincaid style): technical but generally plain language, with some specialized terms (WCAG, block editor, enterprise). #### 👀 Visual learners - Present: Conceptual contrasts (core vs. block libraries, enterprise vs. small-business sites) but few actual visuals. - Improve: Add diagrams of stack architectures, before/after performance charts, and flow diagrams for plugin update risk. #### 🔊 Aural learners - Present: None explicitly. - Improve: Offer a short audio version of the article or a podcast segment discussing the tradeoffs. #### 🗣️ Verbal learners - Present: Clear explanations, examples, anecdotes from real projects, well-articulated reasoning. - Improve: Glossary of terms (block editor, ACF, enterprise WordPress, technical debt). #### 🧩 Kinesthetic learners - Present: Implicit calls to try building with only core/custom blocks. - Improve: Provide step‑by‑step exercises—e.g., rebuild a small page first with a library, then with core/custom, and compare. #### 🧠 Logical learners - Present: Cause–effect chains (block library decisions → maintenance risks); structured arguments. - Improve: Tables comparing architectures and explicit decision trees (“If mission‑critical → choose X”). #### 🧑‍🤝‍🧑 Social learners - Present: Origin in public discussion; relevant to agency teams. - Improve: Add discussion prompts for agency standups or workshops, and example policies. #### 🧘‍♀️ Solitary learners - Present: Text suited for individual reflection and policy drafting. - Improve: Include reflection questions about current stacks and risk tolerance. #### 🌿 Naturalistic learners - Present: No direct environmental tie-ins. - Improve: Use analogies to ecosystems (dependencies, invasive species, resilience) to frame plugin choices. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Blog format likely has headings and basic structure; author is accessibility-focused, so markup is probably reasonable. - Improve: Ensure all interactive components (custom blocks) have proper roles, labels, and focus handling. #### Keyboard navigation - Present: Emphasis on accessibility suggests baseline keyboard support on core/custom blocks. - Improve: Systematically test custom blocks for focus order, visible outlines, and escape mechanisms for complex widgets. #### Contrast and readability - Present: Core theme defaults generally respect contrast guidelines. - Improve: Periodic audits as branding layers are added (colors, typography tweaks). #### Text resizing and reflow - Present: Twenty Twenty‑Four and core blocks are responsive by default. - Improve: Test 200%+ zoom, ensure no clipped content, and support reduced-motion preferences. #### Media and captions - Present: Limited media in this article; Equalize Digital typically prioritizes captions and transcripts elsewhere. - Improve: For future posts with videos, ensure full captions, transcripts, and no autoplay. #### Forms and interactions - Present: Article mostly static; site likely has accessible forms elsewhere given firm focus. - Improve: Maintain patterns for clear error messaging, labels, and sufficient target sizes. #### Standards reference - Map all custom and core block modifications against WCAG 2.2 AA; track issues and fixes in a central backlog. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on WordPress agencies and enterprise clients in a mostly Western context. - Improve: Include examples from diverse regions and smaller organizations in the Global South. #### Inclusive language - Present: Generally neutral, professional, and non-derogatory. - Improve: Define technical jargon for non‑expert readers; avoid insider-only references. #### Neurodiversity support - Present: Well-structured headings and logical flow. - Improve: Further chunking with bullet summaries and callouts; consistent patterns across posts. #### Representation - Present: Mainly one author’s experience; clients broadly referenced (government, higher ed, etc.). - Improve: Include case studies featuring diverse teams and organizations. #### Psychological safety - Present: Critique of tools without personal attacks; acknowledges positive aspects of block libraries. - Improve: Add explicit encouragement that changing architectures is incremental and mistakes are learning opportunities. ### ✅ Logical Validity #### Strong reasoning - The article uses causal reasoning: past negative experiences with libraries → reduced trust → new policy. This is supported with concrete examples (CSS class changes, abandonment). - It employs conditional reasoning: enterprise, mission-critical sites with legal/compliance requirements should prioritize stability and control, hence core/custom over visual libraries. #### Fallacies - Possible survivorship/availability bias: the worst experiences with certain libraries loom large; the article acknowledges “amazing block libraries” but doesn’t quantify typical risk. A fix would be to add data or note that evidence is anecdotal. #### Tone of voice - Tone is candid, opinionated, and pragmatic, with occasional humor and informality (e.g., not trusting devs “to not F my website up”). It balances critique with acknowledgment of legitimate uses for block libraries. ### 🛡️ DARVO Analysis - Deny: The article does not deny others’ experiences; it explicitly recognizes benefits and valid uses of block libraries. - Attack: It criticizes decisions by some library maintainers (breaking changes, abandonment) but not in a personalized or hostile way. - Reverse victim/offender: No attempt to recast Equalize Digital as a victim of specific individuals; it focuses on structural risk and learned caution. ## 🎯 Conclusion Amber Hinds argues that for Equalize Digital—and by extension, many enterprise or mission-critical WordPress sites—the safer, more sustainable architecture is to use WordPress core blocks plus purpose-built custom/ACF blocks, reserving third-party plugins for complex, mission-critical application features rather than foundational layout or UI. Block libraries and page builders remain appropriate tools for small, non‑critical sites with limited budgets, but agencies should carefully weigh long-term accessibility, performance, security, and maintenance risks before building their content model on them. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Core and custom blocks reduce long-term risk > [!quote] [Why We Don’t Use Block Libraries at Equalize Digital](https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/) by [[Amber Hinds]] via [[amberhinds.com]]. Published 2026-01-17. > “We use and love core blocks… If a website can be built with only WordPress core blocks, that is the best way to build.” Two lines: Hinds positions core blocks as the safest foundation for long-term maintainability and accessibility. Use when arguing for core-first architectures. [view highlight](https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Block libraries create rebuild and lock-in risk > [!quote] [Why We Don’t Use Block Libraries at Equalize Digital](https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/) > “If that library is abandoned… you’re now signed up for huge amounts of work to remove or replace the components across potentially hundreds or more pages.” Two lines: Captures the core lock‑in and migration pain argument against relying on block libraries for foundational components. [view highlight](https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Core-only content reduces redesign costs - Sites whose posts use only core blocks are cheaper to redesign because content isn’t locked into third-party structures. - Pointer: Hinds’ recommendation to use only core blocks in blog posts. - Links: [[WordPress-Architecture]] [[Content-Portability]] #### [Z2] Block libraries increase update testing burden - Every update to a visual library requires additional regression testing of layouts and custom styles. - Pointer: Hinds’ discussion of broken styles and surprise feature changes. - Links: [[Plugin-Governance]] [[Maintenance-Costs]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Draft a standard operating procedure for evaluating new WordPress plugins in client projects—accessibility, performance, security, and lock‑in. — context/https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/ #fleeting #inbox - [F2] Run an inventory of existing sites to find where block libraries or page builders control foundational layout. — context/https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/ #fleeting #inbox - [F3] Prototype a reusable, accessible custom tabs block to replace third‑party equivalents. — context/https://amberhinds.com/2026/01/why-we-dont-use-block-libraries-at-equalize-digital/ #fleeting #inbox --- <!-- deep-read:sections end -->