Why I Replaced Alpine.js with htmx for Croatian CRUD Interfaces

I’ve built a lot of Croatian business interfaces. Over the years, I’ve jumped from jQuery to React, then to Alpine.js for lighter tasks. But recently, I replaced Alpine.js with htmx for our local CRUD applications, and the difference in developer sanity and page performance has been staggering. Why would anyone ditch a beloved minimal framework for a hypermedia library? Let me show you exactly what pushed me over the edge.

The Croatian CRUD Reality Check

Most of our local projects aren’t flashy dashboards or real-time chat apps. They are invoice lists, customer databases, inventory tables, and reservation panels — pure CRUD. For years, Alpine.js felt like the perfect fit: small, reactive, and easy to sprinkle onto server-rendered HTML. But after a dozen projects, a pattern emerged that made me question everything.

The State Management Trap

Alpine.js makes local component state trivial. x-data, x-model, x-on — it’s beautiful for toggling a modal or filtering a dropdown. However, in real Croatian CRUD apps, the state isn’t local. You have a table of invoices, each with an edit button. Clicking “edit” opens a modal, fetches data, updates the form, and then submits.

With Alpine.js, I found myself writing hand-crafted JavaScript to sync the modal’s state with the server. I’d have x-init calls, fetch() in Alpine methods, and then manual DOM updates for success or error messages. The code worked, but it felt like I was fighting the framework’s declarative nature. Every new endpoint meant another Alpine method, another fetch wrapper, and another set of $el manipulations.

The Real Smell: Duplicated Logic

Here’s the concrete example that broke the camel’s back. We had a simple product list with inline editing. Click a row, it becomes an input field, press Enter to save. In Alpine.js, I had this:

<tr x-data="{ editing: false, name: '' }">
  <template x-if="!editing">
    <td x-text="product.name" @dblclick="editing = true; name = product.name"></td>
  </template>
  <template x-if="editing">
    <td><input x-model="name" @keydown.enter="save(product.id, name)"></td>
  </template>
</tr>

The save function lived in a separate script tag, making an AJAX call, then manually setting editing = false and updating the row’s display. Every new field required a duplicate state variable. The logic was split between Alpine’s reactive attributes and raw JavaScript. It wasn’t Alpine’s fault — it was the wrong tool for the job.

Why htmx Changed My Mind

htmx operates on a fundamentally different premise: let the server be the source of truth. Instead of managing client-side state for every CRUD interaction, htmx sends HTTP requests and swaps HTML fragments. For Croatian developers who already have a solid backend (PHP, Django, .NET, or even Go), this is a revelation.

Zero Client-Side State

In htmx, the inline editing example becomes:

<tr hx-target="this" hx-swap="outerHTML">
  <td hx-get="/product/123/edit" hx-trigger="dblclick">Product Name</td>
</tr>

And the server returns a new row with an input and a save button. No x-data, no x-model, no fetch calls. The state lives entirely on the server. When the user saves, the server returns the updated <tr> element. The client never needs to know what “editing” means. This eliminated an entire category of bugs in our codebase.

Less JavaScript to Maintain

Alpine.js requires you to write JavaScript for almost every non-trivial interaction. htmx reduces JavaScript to a minimum. For a typical Croatian CRUD interface — think a list of clients with search, pagination, and delete confirmation — I now write zero custom JavaScript. The search is a form with hx-get, pagination uses hx-trigger="click", and delete confirmation is a simple hx-confirm attribute.

I remember a project for a local car rental company. The admin panel had 14 different CRUD screens. With Alpine.js, each screen had around 80 lines of custom JavaScript. With htmx, the entire admin panel’s JavaScript was a single 20-line file for third-party integrations (like datepickers). The backend team could modify the UI without touching a single line of frontend code.

The Hidden Cost of Alpine.js in Complex CRUD

Alpine.js shines in small, isolated widgets. But in a typical Croatian business app, you have interdependencies: saving an invoice should update the customer’s balance, which is shown in a sidebar. With Alpine.js, you either use a global store (like Alpine.store) or pass events around. Both approaches add complexity.

Event Bus Spaghetti

I once built a reservation system where changing the date in one component needed to refresh three other panels. Alpine.js forced me to dispatch custom events, listen for them, and manually re-fetch data. The event flow became a tangled mess. Debugging required tracing through $dispatch calls across multiple files.

htmx handles this with hx-trigger from other elements. A date change triggers a GET to a URL that returns the updated panels. The server controls the response. There’s no client-side event chain to follow. The logic is in the HTTP response, which is far easier to reason about.

Overhead for Non-Interactive Pages

Not every page in a CRUD app is interactive. Many are simple lists with a few buttons. Alpine.js still loads its runtime and initializes components even when the page has no reactive state. htmx, being an attribute-based library, only processes elements that have hx-* attributes. On a read-only page, htmx does nothing. The performance difference is marginal on modern devices, but on older Croatian business computers (I’ve seen plenty of Windows 7 machines), every kilobyte counts.

The Server-Side Advantage for Croatian Teams

Most Croatian development shops have a strong backend culture. PHP with Laravel or Symfony, Python with Django, or even good old ASP.NET. htmx plays directly into this strength. The server returns HTML, which is what the backend team already knows how to generate.

Template Reuse

In Alpine.js, I often duplicated templates. The server rendered the initial HTML, and then Alpine.js components had their own templates for dynamic parts. With htmx, the server renders everything. The same Blade template that generates the initial list also generates the response for the edit action. No duplication, no mismatch.

I worked with a Zagreb-based agency that had three frontend developers maintaining Alpine.js components while the backend team maintained server templates. They constantly disagreed on what the UI should look like. After switching to htmx, the frontend team focused on CSS and HTML structure, and the backend team owned the dynamic parts. The tension disappeared.

Security Without Client-Side Tricks

CRUD interfaces need proper authorization. With Alpine.js, you often hide UI elements client-side based on user roles, but the real check must happen on the server. htmx makes this transparent: the server decides what HTML to return. If a user isn’t authorized to edit, the server returns the read-only version. There’s no client-side role check to accidentally bypass. This aligns perfectly with the security-first mindset common in Croatian enterprise projects.

When I Still Use Alpine.js (And You Should Too)

I’m not here to trash Alpine.js. It’s excellent for highly interactive, client-state-heavy interfaces. If your Croatian project involves a complex drag-and-drop dashboard, a real-time chat widget, or a map with markers, Alpine.js is still the better choice. htmx struggles with interactions that require immediate client-side feedback without a server round trip.

The Hybrid Approach

For the last project, I used both. The main CRUD table used htmx for listing, editing, and deleting. A small Alpine.js component handled a multi-step wizard form that needed to hold state before a final submission. The integration was seamless: Alpine.js handled the wizard’s internal state, and the final submit triggered an htmx request.

This hybrid approach gave me the best of both worlds. The heavy CRUD logic stayed on the server, while the wizard’s complex validation and step transitions lived in Alpine.js. I used less than 50 lines of Alpine-specific JavaScript.

Practical Takeaway

If you’re building CRUD interfaces for Croatian businesses — invoicing, inventory, reservations, client management — start with htmx as your default. Let the server handle state and rendering. You’ll write less JavaScript, reduce bugs, and make your backend team happier. Reserve Alpine.js for the small pockets of your app that genuinely need client-side reactivity. Your future self will thank you when you’re debugging a production issue at 2 PM on a Friday, and the entire problem lives in a single HTTP response instead of a chain of event listeners.