DEV Community: Eyruz Badalzada

Bootstrap vs FrontAlign: Which Is Better Depends on Your Architecture

Eyruz Badalzada — Thu, 30 Jul 2026 14:04:42 +0000

Bootstrap has been the default answer to "how do I ship a UI fast" for over a decade. Pre-styled buttons, a battle-tested grid, and JS plugins for every common interaction pattern — you drop in the CSS and JS, add some classes, and you have a working interface.

FrontAlign competes for some of the same territory (fast to ship, components included), but it gets there from a different starting point: utility-first CSS plus a zero-dependency runtime, rather than a component-class library plus a plugin system. Here's how the two actually differ once you get past the surface-level "both give you a Navbar and a Modal."

Styling Philosophy: Component Classes vs. Utility-First

Bootstrap's core styling unit is the semantic component class: .btn, .btn-primary, .card, .navbar, .alert-danger. You compose interfaces by combining these with a smaller set of utility classes (spacing, flex, display) that Bootstrap added in v4/v5 as a complement — not a replacement — for the component classes.

FrontAlign flips that emphasis. Utilities are the primary building block, and components are layered on top via fa-component attributes rather than being the thing you style directly:

<div fa-component="swiper">...</div>
<nav fa-component="tabview">...</nav>

new FrontAlign();

Practically, this means Bootstrap interfaces tend to look "Bootstrap-y" out of the box unless you invest in Sass overrides, because you're working within predefined component classes. FrontAlign interfaces are closer to fully custom, because you're composing utilities rather than inheriting a component's default visual identity.

Build Pipeline and Customization

Bootstrap's customization story runs through Sass: you override $primary, $border-radius, and dozens of other variables and maps, then recompile. Bootstrap 5.3 added CSS custom properties and a data-bs-theme attribute for light/dark switching, which narrowed the gap with runtime theming — but deep visual customization (spacing scale, typography scale, component variants) still generally goes through the Sass build.

FrontAlign's JIT compiler scans your source for used classes and strips the rest, driven by frontalign.config.js:

export default {
  theme: { primary: '#2563eb' },
  fonts: [{ family: 'Inter', weights: '400,600,700' }],
  jit: {
    scan: ['./app', './components', './pages'],
    safelist: ['button', 'is-primary', 'is-active'],
  },
};

The bigger architectural difference shows up at runtime, not build time — covered next.

Runtime Theming

Bootstrap 5.3's data-bs-theme="dark" covers light/dark switching well via CSS variables, but changing core design tokens (brand color, radius scale, spacing) beyond light/dark still typically means a Sass recompile.

FrontAlign treats arbitrary theme changes as a runtime concern by default:

new FrontAlign({
  theme: { primary: '#6366f1' },
});

If your product needs a user-facing theme picker or white-labeling beyond a dark-mode toggle, that's a meaningfully lower-friction path in FrontAlign. If dark mode is the only runtime switch you need, Bootstrap 5.3+ already covers it natively.

Component Coverage

This is the category where the two frameworks overlap the most. Bootstrap ships Modal, Offcanvas (its drawer equivalent), Dropdown, Collapse, Accordion, Navbar, Carousel, Toast, Tooltip, Popover, Alerts, Forms with validation states, Badges, Placeholders (its skeleton/loading equivalent), and Spinners.

FrontAlign's list reads almost like a modern remap of the same set: Modal, Drawer, Dropdown, Collapse, Accordion, Navbar, Carousel, Swiper, Toast, Tooltip, Popover, Alert, Select, Tabview, DarkMode, Form (attribute-driven validation, optional AJAX submit), Badge, Skeleton, Lazy Image, and a dual-mode Range slider.

<form fa-component="form" data-ajax="/api/submit" novalidate>
  <input type="email" data-rule="email">
  <button type="submit">Send</button>
</form>

The practical difference isn't "who has more components" — it's initialization model. Bootstrap components are largely initialized via data attributes plus its own JS plugin classes (bootstrap.Modal, bootstrap.Tooltip, etc.), and some require manual re-initialization for dynamically injected content. FrontAlign's Smart Observer Runtime watches the DOM continuously and auto-initializes new fa-component elements as they appear, without you calling anything again.

Dependencies

This is where the architectures diverge most concretely. Bootstrap's CSS has no dependencies, but several of its interactive JS components — Tooltip, Popover, Dropdown — depend on Popper.js for positioning. That's an extra library in your bundle unless you're using a build that already includes it.

FrontAlign ships as zero-dependency across both CSS and JS, positioning and all. That's a smaller and more predictable bundle if you're using those interaction patterns heavily, though it also means FrontAlign's positioning logic hasn't had a decade-plus of edge-case hardening the way Popper.js has.

Grid and Layout

Bootstrap's 12-column grid (container, row, col-*) is one of the most widely understood layout systems in frontend development — most developers can read Bootstrap grid markup without looking anything up. Its breakpoints (sm, md, lg, xl, xxl) are tuned to fairly conservative, long-standing device-width conventions.

FrontAlign uses responsive utility prefixes (sm:, md:, lg:, xl:, 2xl:) rather than a dedicated grid component, with breakpoints tuned to modern screen sizes:

{ sm: "640px", md: "864px", lg: "1120px", xl: "1408px", "2xl": "1792px" }

If your team already thinks in Bootstrap's row/col mental model, that's real, transferable muscle memory. If you're comfortable composing layout with flex/grid utilities directly, FrontAlign's approach avoids an extra abstraction layer on top of CSS Grid/Flexbox.

Browser Support

Bootstrap 5 supports a broad range of browsers, including some older ones, since it doesn't lean on newer CSS features by default. FrontAlign's use of OKLCH colors, CSS Layers, and Intersection/MutationObserver ties it to more modern browsers (Chrome/Edge 111+, Firefox 113+, Safari 15.4+). If legacy browser support is a hard requirement, that's worth checking before committing to either.

So, Which One?

Reach for Bootstrap if:

Your team already knows its component classes and grid system
You want the most broadly documented, most Stack-Overflow-answered option
Dark mode is the extent of your runtime theming needs
You need dependable behavior across a wide range of browsers, including older ones

Reach for FrontAlign if:

You want utility-first styling instead of inheriting Bootstrap's default visual identity
You need runtime theming beyond light/dark, without a rebuild
A zero-dependency footprint (no Popper.js, no separate positioning library) matters to your bundle size
You want components to auto-initialize on dynamically injected content without re-running setup code

Neither framework is "outdated" or "better" in the abstract — Bootstrap's component-class model and Sass pipeline are a known, stable quantity; FrontAlign's utility-first-plus-runtime model is a more modern bet with a smaller dependency footprint. Pick based on how your team already thinks about styling and how much runtime flexibility your product actually needs.

FrontAlign docs: frontalign.dev/docs

Tailwind vs FrontAlign: Which Is Better Depends on Your Architecture

Eyruz Badalzada — Thu, 30 Jul 2026 14:02:03 +0000

If you've built anything on the frontend in the last five years, you've almost certainly touched Tailwind CSS. It reshaped how a huge chunk of the industry thinks about styling — utility classes instead of hand-rolled CSS, a build pipeline that only ships what you use, and a massive ecosystem built around it.

FrontAlign enters the same utility-first space, but it's solving a slightly different problem. Instead of asking "how do we generate utility classes efficiently," it asks "what if the utility layer, the components, and the runtime behavior all shipped together, with zero dependencies?"

Neither answer is universally "better." The right pick depends on the shape of your project. Here's a breakdown by architecture, not by hype.

The Core Difference: Utility Engine vs. Utility Engine + Runtime

Tailwind is, at its heart, a CSS generation tool. It scans your markup, matches utility patterns, and emits a stylesheet at build time. Everything else — dropdowns, modals, form validation, carousels — is left to you or to a component library layered on top (Headless UI, Radix, shadcn/ui, etc.).

FrontAlign ships that same utility-first, JIT-compiled CSS layer, but pairs it with a JavaScript runtime that auto-discovers and initializes components directly from markup attributes:

<div fa-component="swiper">...</div>
<nav fa-component="tabview">...</nav>
<img data-src="/image.jpg" alt="Lazy image">

new FrontAlign();

That single call boots a "Smart Observer Runtime" that watches the DOM, initializes components as they appear (including ones added dynamically), and lazy-loads images with data-src — no manual re-init calls scattered through your app.

This is the crux of the architectural split: Tailwind gives you the styling primitive and expects you to assemble the rest. FrontAlign gives you the styling primitive plus a component/behavior layer already wired together.

Build Pipeline

Both frameworks lean on a JIT compiler that scans your source for used classes and strips the rest. Configuration looks structurally similar too — FrontAlign's frontalign.config.js supports theme tokens, font declarations, scan paths, a safelist for runtime-injected classes, and custom breakpoints:

export default {
  theme: { primary: '#2563eb' },
  fonts: [{ family: 'Inter', weights: '400,600,700' }],
  jit: {
    scan: ['./app', './components', './pages'],
    safelist: ['button', 'is-primary', 'is-active'],
    extensions: ['mdx'],
    debug: false,
    concurrency: 50,
  },
};

If your team already has Tailwind's config mental model memorized, FrontAlign's build-time story won't feel like a big leap. The meaningful difference shows up at runtime, not build time — see the next section.

Runtime Theming

This is one area where the two diverge clearly. Tailwind's theme values are compiled into your CSS at build time; changing them typically means editing config and rebuilding (CSS custom properties can get you partway to runtime theming, but it's not the framework's default model).

FrontAlign exposes runtime configuration as a first-class feature, separate from the build-time config file:

new FrontAlign({
  theme: { primary: '#6366f1' },
});

If your product needs user-configurable themes, white-labeling, or a theme switcher that doesn't trigger a rebuild, that's a real architectural point in FrontAlign's favor. If your theme is fixed at design time and you just want static, art-directed CSS, it's a non-issue either way.

Component Coverage

This is the other major fork in the road. Tailwind is deliberately unopinionated about components — that's a feature for teams who want full control over markup and behavior, and a liability for teams who don't want to build or vendor a component library from scratch.

FrontAlign ships components directly: Modal, Drawer, Dropdown, Collapse, Accordion, Navbar, Carousel, Swiper, Toast, Tooltip, Popover, Alert, Select, Tabview, DarkMode, Form (with attribute-driven validation and optional AJAX submission), Badge, Skeleton, Lazy Image, and a dual-mode Range slider.

<form fa-component="form" data-ajax="/api/submit" novalidate>
  <input type="email" data-rule="email">
  <button type="submit">Send</button>
</form>

The tradeoff is the classic one for any batteries-included tool: you move faster out of the box, but you're also more coupled to that library's conventions and markup expectations. Tailwind's ecosystem is broader and more heterogeneous precisely because it doesn't dictate component structure.

React and Framework Support

Tailwind is framework-agnostic by design and works anywhere PostCSS can run — React, Vue, Svelte, Astro, plain HTML, you name it, with a huge body of community integrations.

FrontAlign works across the same general surface (Vanilla JS, React, Next.js, Vue, Astro, Laravel, WordPress, static HTML) and adds a dedicated React package with hooks for component-level control:

'use client';
import { useNavbar, useDrawer } from 'frontalign/react';

If you're deep in a React/Next.js codebase and want hooks that map directly to component state, that's a convenience Tailwind doesn't provide natively — you'd reach for a separate headless library.

Dependencies and Bundle Philosophy

Both frameworks emphasize a lean footprint. Tailwind's runtime footprint is effectively zero, since it's a build-time tool with no JS shipped unless you add it yourself. FrontAlign ships zero external dependencies too, but — unlike Tailwind — it does ship its own JS runtime by design, since components and the observer system need it to function.

That's not a strike against FrontAlign; it's a different bet. You're trading "no JS unless I add it" for "a small, dependency-free JS runtime that powers the components I'm already using."

Browser Support

Worth flagging: FrontAlign's OKLCH color system and use of CSS Layers, IntersectionObserver, and MutationObserver mean it targets fairly modern browsers (Chrome/Edge 111+, Firefox 113+, Safari 15.4+). Tailwind's baseline is generally more permissive depending on which CSS features you opt into. If you have hard requirements for older browser support, check this before committing either way.

So, Which One?

Reach for Tailwind if:

You want a pure styling primitive and full control over component architecture
You're already invested in an existing component library (Radix, shadcn/ui, Headless UI)
You need the widest possible ecosystem, plugin support, and community resources
Older browser support is a hard constraint

Reach for FrontAlign if:

You want utility CSS and a working component set out of the box
Runtime theming (no rebuild) matters to your product
You want attribute-driven component initialization without wiring up your own observer/mount logic
You're fine targeting modern browsers only

Architecture, not marketing, should make this call. If your project already has a component layer and you just need utilities, Tailwind's narrower scope is a feature. If you're starting fresh and want the utility layer and the components to arrive already integrated, FrontAlign's bet on a runtime is the more direct path.

Both are valid answers to "how do we style modern interfaces without CSS chaos." They just start from different assumptions about where the framework's responsibility ends and your app's begins.

FrontAlign docs: frontalign.dev/docs

Build NextJS Agency website in 30 seconds

Eyruz Badalzada — Sun, 19 Jul 2026 15:18:15 +0000

Seeing is better than hearing a hundred times! Build your own agency website in just 30 seconds. Continue with Premium if you wish, or develop on your own.

I Got Tired of Stitching Together Tailwind + a Component Library + a Theming Layer — So I Built FrontAlign

Eyruz Badalzada — Fri, 17 Jul 2026 20:06:11 +0000

Every front-end stack eventually hits the same wall.

You pick a utility-first CSS framework for styling. Then you realize you still need a separate library for modals, dropdowns, and carousels. Then you need a theming solution on top of that. Then you have to wire up lazy-loading for images yourself. And if you're using React, you're hoping someone already built the hooks for all of it.

Each piece works fine on its own. Together, they're three or four dependencies that don't fully agree with each other, requiring multiple config files and context providers.

That's the exact problem I set out to solve with FrontAlign — a unified UI engine that bundles utility-first CSS, a smart component runtime, a JIT compiler, and a dedicated React package into one system. Zero dependencies.

What makes FrontAlign different?

FrontAlign isn't "yet another utility CSS framework." It's an attempt to bring the pieces that usually live in separate libraries under one roof without the bloat:

Utility-first CSS built on a modern OKLCH color system (no more muddy colors) and native CSS layers (no more !important wars).
Smart, auto-initialized components (modals, drawers, smart carousels, tabs, etc.).
A built-in CSS compiler & JIT builder to prune unused styles for production.
Runtime theming — dynamically change your theme variables without a rebuild.
A skeleton loading system that works purely with HTML attributes.
Zero dependencies under the hood.

The "Aha!" Moment: The Smart Observer Runtime

Usually, if you inject new HTML into the DOM (via AJAX, React, HTMX, etc.), you have to manually re-initialize your JavaScript components. FrontAlign fixes this with its Smart Observer.

<!-- Add this anywhere, anytime -->
<div fa-component="swiper">
    ...
</div>

<!-- Lazy loads automatically just by using data-src -->
<img data-src="/image.jpg" alt="Lazy image">

FrontAlign watches the DOM. Render a component later? It initializes it. Add a lazy image? It loads it when it enters the viewport. No manual init() calls scattered throughout your app.

Form Validation... Without the JS Wiring

One of my favorite features I built into FrontAlign is declarative form validation. You don't need to write custom JS logic for basic validation or AJAX submissions.

<form fa-component="form" data-ajax="/api/submit" novalidate>
    <!-- Validates automatically based on data-rule -->
    <input type="email" data-rule="email">
    <button type="submit">Send</button>
</form>

It also includes complex components like dual-mode (min/max) range sliders right out of the box.

A JIT Compiler, Built In

Utility-first CSS is great for velocity, but it balloons your stylesheet. FrontAlign ships with its own compiler:

npx frontalign build

It scans your source files, keeps only the classes you actually reference, applies your fa.config.js theme tokens, and writes a single optimized stylesheet.

Runtime Theming vs Build-Time Config

FrontAlign cleanly separates build-time (JIT) and runtime. Need a white-label dashboard where users pick their own theme? You can inject themes at runtime without rebuilding:

new FrontAlign({
    theme: {
        primary: '#6366f1' // Updates instantly
    }
});

React Support (With Actual Hooks)

While FrontAlign works beautifully with plain HTML, Vue, Astro, or Laravel, I know React developers need component-level control. The library ships with a dedicated React package:

'use client';

import { useForm } from 'frontalign/react';

export function FormExample() {
  useForm();

  return (
    <form className="form" fa-component="form"noValidate>
      <div className="form-group is-floating">
        <input id="email" type="email" className="form-input"data-rule="email" />
        <label htmlFor="email">Email address</label>
      </div>

      <div className="form-group">
        <input type="range" className="form-range"fa-component="range" min="0" max="100" defaultValue="40" />
      </div>

      <button type="submit" className="button is-primary">Submit</button>
    </form>
  );
}

You can also import specific components rather than the whole engine if you want to keep your bundle tiny:

import { Modal, Toast, Skeleton } from 'frontalign';

All components and the framework's core are SSR-safe. You can use FrontAlign in any environment — from Next.js to plain static HTML.

Browser Support & The Future

FrontAlign leans heavily on modern platform features (IntersectionObserver, MutationObserver, CSS layers, OKLCH). Because of this, it targets modern browsers (Chrome 111+, Safari 15.4+). If you need to support IE11 or ancient browsers, this isn't the tool for you or you have to use fallback.

Where this is going

The primary goal right now isn't to out-utility Tailwind or out-component Bootstrap. It's to stop developers from needing both, plus a theming library, plus a lazy-load script, plus separate framework bindings, just to build a normal interface.

Try It Out

You can install it via NPM:

npm install frontalign

Or drop in the CDN to play around instantly:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/frontalign/dist/css/frontalign.min.css">
<script src="https://cdn.jsdelivr.net/npm/frontalign/dist/js/frontalign.min.js"></script>
<script>
    new FrontAlign();
</script>

Try With Starter Template

You can install and run starter template with one command:

npx create-frontalign mytemplate --template agency

I'd genuinely love your feedback. If you try it on a real project and something breaks, feels off, or works beautifully, please let me know. Critical feedback is what will help this grow.

🔗 Website & Docs: frontalign.dev
⭐ GitHub Repo: Frontalign — a star would mean the world to me if you like the idea.