Why FG UI

Build more interface with less setup.

FG UI is built around a simple idea: you should be able to create polished websites and applications quickly without handing your interface over to a heavy framework, a remote service or a pile of dependencies.

Built entirely with FG UI.

Every layout, component, interaction, icon and interface pattern on this website is powered by FG UI itself. No Bootstrap, Tailwind or external UI framework is used.

The simple answer

FG UI gives you the finished pieces and keeps you in control.

You get a large, coherent interface system that is straightforward to use, local to your project and ready for real product work.

393 families

Build more with less assembly

178 Basic components cover reusable building blocks. 215 Combined patterns give you ready-made product structures such as dashboards, authentication, commerce, community, admin, portals, workflows and website sections.

Local first

Your UI stays with your product

CSS, JavaScript, icons and the default Manrope font can all run locally. FG UI does not require a CDN or a remote UI service just to render your interface.

Framework independent

Use normal HTML

There is no framework syntax to learn before you can make a button, card, form, dashboard or website. Load FG UI and use its classes.

Hardened

Built for real interfaces

FG UI 1.1.0 passed the complete 393-family automated release gate plus manual Firefox, Safari, iPhone, Android and NVDA validation, with keyboard, focus, ARIA, reduced-motion and forced-colour work in the core.

320px+

Responsive from the start

The system is designed to scale from narrow mobile widths through desktop layouts without requiring a second mobile component library.

One language

Stop redesigning the same controls

Typography, spacing, states, borders, shadows, controls and component behaviour come from one system, so different parts of a product feel related.

A different kind of UI toolkit

Less dependency. More ownership.

FG UI is designed to give you a complete interface system without quietly adding a second stack behind your own. The comparison below describes common patterns you may encounter in dependency-heavy UI setups. Not every other toolkit works the same way.

0runtime dependencies
0required network requests
0core cookies or browser storage
800local SVG icons
What matters
FG UI
Common alternative setup
Runtime dependenciesWhat must load for the UI to work
FG UINone.

The package declares zero runtime dependencies.

Common alternativeMay require several packages.

Framework-specific UI stacks can add runtime libraries or supporting packages.

Required external requestsThird-party runtime traffic
FG UINone required.

FG UI can run entirely from assets hosted with your own project.

Common alternativeCan add remote requests.

CDNs, hosted fonts, icon services or remote scripts are common choices in some stacks.

CDN dependencyAvailability outside your server
FG UINo CDN required.

Your interface does not need a third-party CDN to render.

Common alternativeMay rely on one.

Some setups load framework, font or icon assets from a third-party CDN.

FontsTypography delivery
FG UISelf-hosted Manrope included.

Six WOFF2 subsets are packaged locally, and you can opt not to use the FG UI font.

Common alternativeOften a separate decision.

You may need to source, host or remotely load a font yourself.

IconsInterface icon dependency
FG UI800 local SVG icon IDs.

The complete stable icon sprite is supplied with the kit.

Common alternativeCan be another dependency.

An icon package, hosted icon library or separate service may need to be added.

Cookies and storageCore privacy footprint
FG UINo cookies, localStorage or sessionStorage in the core.

FG UI itself does not add browser storage just to provide the interface system.

Common alternativeDepends on the stack and add-ons.

Hosted tooling, analytics or companion services can introduce additional browser storage.

Telemetry and trackingSilent product analytics
FG UINone in the core.

FG UI does not phone home, send telemetry or track your users.

Common alternativeVaries.

Hosted services and add-ons can add telemetry or analytics depending on how they are configured.

Package manager or build toolGetting started
FG UINot required.

Copy the assets, load the CSS and JavaScript, and start using normal HTML.

Common alternativeCan be part of the setup.

Some component systems expect npm, a bundler, compilation or framework tooling before you begin.

Framework lock-inHow portable your markup is
FG UIFramework independent.

Use familiar HTML, CSS classes and a small public JavaScript API.

Common alternativeMay be framework-specific.

Components can be tied to a particular rendering framework, syntax or project structure.

Ready-made product patternsHow much assembly is left to you
FG UI215 Combined component families.

Dashboards, authentication, commerce, community, admin, portal, workflow and website patterns sit alongside 178 Basic components.

Common alternativeCoverage varies widely.

Some libraries focus mostly on primitives, leaving larger product structures for you to assemble.

Responsive baselineSmall-screen behaviour
FG UIDesigned and audited from 320px upward.

Mobile behaviour is part of the same component system rather than a separate library.

Common alternativeDepends on the component.

Responsive coverage and mobile behaviour can vary between libraries and individual components.

Accessibility behaviourInteractive states and focus
FG UIHardened in the core.

Keyboard patterns, focus management, ARIA synchronisation, reduced motion and forced-colours behaviour are part of the release gates.

Common alternativeQuality varies.

Accessibility support can range from strong built-in behaviour to work the implementer must add.

No-JavaScript fallbackProgressive enhancement
FG UIReadable/native content is preserved where reasonable.

The browser-support policy explicitly tests no-JavaScript fallback behaviour.

Common alternativeCan depend heavily on JavaScript.

Framework-rendered interfaces may have less useful content before or without their JavaScript runtime.

Dynamic contentCMS, AJAX and injected UI
FG UIDesigned to initialise again safely.

FGUI.init(root), multiple instances, nested components and dynamic DOM behaviour are part of the reliability gates.

Common alternativeDepends on lifecycle architecture.

Dynamic content may require framework-specific mounting, hydration or lifecycle handling.

Custom brandingMaking the kit look like your product
FG UISemantic CSS custom properties.

Change shared brand tokens such as --fgui-primary without forking hundreds of component selectors.

Common alternativeApproach varies.

Customisation may use variables, configuration, recompilation or component-level overrides.

Version stabilityKnowing what an update means
FG UIStable 1.2.0 public contract and semantic versioning.

FG UI 1.2.0 preserves the complete 1.1 compatibility baseline. Published stable archives are immutable; breaking contract changes require a major release.

Common alternativePolicies vary.

Upgrade guarantees, deprecation windows and archive immutability differ between products.

Vendor availabilityWhat happens if our website is offline
FG UIYour deployed UI keeps running.

When you self-host the supplied runtime assets, your product does not depend on fgui.forgoodtools.com being online.

Common alternativeDepends on what is hosted remotely.

Any runtime asset or service loaded from elsewhere becomes another availability dependency.

About performance

FG UI does not claim that a toolkit alone makes every website faster. What it does give you is a cleaner performance starting point: no required third-party runtime requests, no framework dependency chain, and local fonts and icons. Your final speed still depends on your own pages, media, server and implementation.

Privacy and independence

The core does not quietly phone home.

FG UI is intentionally boring in the best possible way. It provides interface code and assets, then stays out of your users' data.

Zero network policy

No background server requests

The Stable core contains no required fetch, XMLHttpRequest, WebSocket, EventSource or beacon traffic. Your interface does not need to contact ForGoodTools to work.

No core storage

No cookies or browser storage

The FG UI core does not set cookies, localStorage or sessionStorage. Features you build can use storage if you choose, but the toolkit does not add it for you.

No telemetry

No tracking built into the toolkit

There is no analytics beacon, usage reporting or hidden telemetry in the Stable runtime.

Self-hosted

Fonts and icons stay local

Manrope and the complete SVG icon sprite are bundled with FG UI, so you do not need a third-party font or icon service.

No build gate

Start without npm or a compiler

A package manager or build system can still be part of your own workflow, but FG UI does not require one before you can build a page.

Modern, not bloated

No legacy-browser polyfill bundle

FG UI targets modern evergreen browsers and does not ship a legacy-browser compatibility bundle you do not need.

A useful test of ownership

If our website went offline, your self-hosted FG UI interface would not have to.

Once the FG UI assets are inside your project, the runtime can be served from your own infrastructure. There is no licence check, remote UI renderer, hosted font dependency or icon API required just to draw the interface.

The details that matter later

Built for the day after the demo.

A UI kit is easy to make look impressive in one screenshot. The harder job is keeping it predictable when your application grows, content changes and updates arrive.

Dynamic DOM

Re-initialise safely

FGUI.init(root) is designed for interfaces added after page load, including CMS and application workflows.

Multiple instances

More than one component at a time

Release gates cover multiple instances and nested components, not only isolated single-component demos.

CSP gate

Security-conscious runtime checks

Content Security Policy behaviour is included in the JavaScript reliability gates used for the Stable release.

Localisation

Language-ready API

The public runtime includes locale and translation helpers alongside dedicated localisation guidance.

Progressive enhancement

Native content where possible

No-JavaScript testing checks that readable content and native controls remain usable where an interaction can reasonably degrade.

Stable contracts

Updates have rules

Patch releases fix compatible defects, minor releases add backwards-compatible features, and breaking contracts require a major version.

What changes for you

From blank page to useful interface faster.

1

Choose a component

Start with a Basic component when you need a small piece, or a Combined component when you need a larger ready-made area.

2

Copy the HTML

Use familiar HTML classes rather than learning a separate rendering framework first.

3

Make it yours

Change the content, connect your data and compose screens while keeping the core design language consistent.

The proof is this website

You are using an FG UI product right now.

This site is built with FG UI itself. The navigation, page layouts, cards, forms, menus, modals, status elements, icons and responsive behaviour are the same system the site is explaining.