AlpineJS

Do menus, modals and filters really need a whole frontend framework?

AlpineJS adds interactivity measured in kilobytes, not megabytes. Dropdown menus, modals, tabs, filters and form logic run straight from your HTML, with no separate frontend application and no heavy build step.

Most company websites need surprisingly little interactivity: open a menu on mobile, show a modal with a form, switch tabs, filter a list, and reveal or hide a field based on a choice. Despite that, sites like these increasingly get React or Vue bolted on. That adds a build step, hundreds of kilobytes of scripts and an entire layer that has to be maintained and updated. The visitor pays for it in load time on mobile, the client pays for it in the price of every future change.

AlpineJS covers exactly that space. It is a small library where behaviour is written directly into HTML attributes, much like jQuery once was, but with clear declarative syntax and reactive state. It needs no virtual DOM and no build of its own, and it is added to a page with a single file. In WordPress themes, Sage projects and static sites it gives you interactivity that is readable straight from the source and does not weigh down the rest of the site.

01

What Alpine solves and why it stays small

Alpine is around fifteen kilobytes and its entire vocabulary can be learned in an afternoon. State is declared on an element, and conditional rendering, loops, transitions and event handling are written as attributes. It is not a React replacement, it is a complement for sites that are server-rendered HTML at their core and only need to come alive. That is also why it deploys quickly: nothing gets rewritten, existing templates simply gain attributes where something needs to react.

  • Around 15 kB versus hundreds of kB for React
  • No mandatory build or separate application
  • Behaviour is visible directly in the HTML
  • Can be added to an existing site gradually

02

The elements I build with Alpine most often

In practice it is the same group of elements on most projects. Mobile and multi-level menus, modal windows and side panels, tabs and accordions in FAQ sections, filtering and sorting of listings, copy to clipboard, character counters and notifications. All of these need to work reliably and accessibly rather than impressively. For each one I also handle keyboard operation, correct ARIA attributes and closing with the Escape key, so the site stays usable without a mouse.

  • Mobile menus, dropdowns and side panels
  • Modals and confirmation dialogs
  • Tabs, accordions and FAQ sections
  • Filtering, sorting and live search in listings
  • Keyboard operation and ARIA attributes

03

Forms and logic without a separate API

On a typical site, form logic eats the most time. Show billing details only after a checkbox is ticked, recalculate a price from the selected variant, validate a format before sending, submit in the background and show the result without a page reload. Alpine handles all of that without spawning a separate frontend application. The server side stays in WordPress or Laravel, where the logic already lives, so validation is not duplicated in two places where the two copies eventually drift apart.

  • Conditional fields and multi-step forms
  • Live price or total recalculation
  • Background submission without a page reload
  • Server-side validation stays the source of truth

04

Alpine and Tailwind as a natural pair

Alpine and Tailwind CSS work well together because both keep everything next to the component: appearance in classes, behaviour in attributes. Reading a template, you see at once how an element looks and what it does, without hunting through three files. Transitions and animations can be handled with Tailwind classes that Alpine toggles. Inside a Sage theme this becomes a component used on ten pages and maintained in a single place.

  • Appearance and behaviour in one place in the template
  • Animations through Tailwind classes toggled by Alpine
  • Fits Sage components and static sites alike
  • Fewer files to search through when something changes

05

When Alpine is not enough and React fits better

I do not recommend Alpine everywhere. If the core of the project is a large interface with its own routing, state shared across screens, an offline mode or tables with thousands of rows, React or Vue gives the team better tools. The line sits where state stops belonging to a single element and starts belonging to the whole application. Ordinary websites, brochure sites, shops with a classic cart and WordPress themes are exactly the case where Alpine is sufficient and cheaper to maintain a year later. I work at 40 EUR per hour including VAT, and adding interactivity to an existing site is usually 3 to 10 hours.

  • React for a large interface with its own routing
  • React when state is shared across screens
  • Alpine for sites built on server-rendered HTML
  • Adding interactivity roughly 3 to 10 hours at 40 EUR per hour including VAT

?

Frequently asked questions about AlpineJS

Is AlpineJS a replacement for React?

No, and it does not try to be. Alpine brings server-rendered pages to life and keeps state next to a specific element. React fits better where the frontend is a standalone application with its own routing and state shared across screens.

Can Alpine be added to an existing website?

Yes, and that is the most common case. Alpine is added with a single file and rolled out element by element. There is no need to rewrite templates or change how the site works, so we can start with one menu or one modal.

Will Alpine replace jQuery on an older site?

In most cases yes, and the result tends to be more readable. jQuery usually solves the same tasks with longer, scattered code. If a plugin on the site still requires jQuery, I leave it where it is and write the new parts in Alpine.

What about accessibility and SEO?

Content is rendered by the server, so search engines and screen readers receive finished HTML. On interactive elements I add ARIA attributes, correct keyboard order and closing with the Escape key. Hidden parts are not hidden in ways that would confuse search engines.

What does adding interactivity to a site cost?

A single element such as a menu, modal or tabs is usually one to three hours. A fuller set of elements across a site typically lands between 3 and 10 hours, which is 120 to 400 EUR including VAT at a rate of 40 EUR per hour.

Need the site to feel alive without rewriting it?

Tell me which elements should react and what the site runs on. I will say whether Alpine covers it, how many hours it takes and what I would approach differently.

Discuss interactivity