Why I Replaced jQuery with htmx for Croatian Interactive Forms

I remember the exact moment I questioned my loyalty to jQuery. I was building a multi-step application form for a Croatian client in the tourism sector, and the page was bloated with $.ajax() calls, DOM manipulation spaghetti, and event handlers that seemed to multiply overnight. The form worked, but the codebase felt fragile.

The question became unavoidable: was there a simpler way to build interactive forms without shipping a 30KB library just to toggle visibility and submit data? That’s when I stumbled upon htmx, and it fundamentally changed how I approach front-end interactivity for Croatian websites.

The Real Cost of jQuery in 2024

A Library From a Different Era

jQuery was a lifesaver in the late 2000s. It normalized browser inconsistencies and gave us clean syntax for DOM traversal. But the web platform has caught up. Native JavaScript methods like querySelector() and fetch() do nearly everything jQuery used to do, without the overhead.

For Croatian businesses, every kilobyte matters. Many users still access websites on mid-range smartphones or older desktops. Loading jQuery for a simple contact form or a registration wizard is like renting a truck to move a single chair.

The Maintenance Debt

When you use jQuery for interactive forms, you end up writing a lot of custom JavaScript to handle state. Show this field, hide that section, validate this input, send that request. Over time, the logic scatters across multiple functions and event listeners.

I once inherited a Croatian real estate portal with a property submission form that had over 400 lines of jQuery. Changing one validation rule required tracing through five different event bindings. That’s not maintainable. That’s technical debt with interest.

Enter htmx: A Different Philosophy

What htmx Actually Does

htmx is a tiny JavaScript library (roughly 14KB minified and gzipped) that lets you build dynamic interfaces directly in HTML. You add attributes like hx-get, hx-post, hx-target, and hx-swap to your elements, and they automatically make AJAX requests and update the page.

No need to write a single line of JavaScript for the request itself. The server returns HTML fragments, and htmx swaps them into the DOM. It’s a return to the simplicity of server-rendered pages, but with modern interactivity.

How It Changed My Form Workflow

For a Croatian e-commerce checkout form I recently built, the difference was night and day. Instead of writing jQuery to validate the postal code field on blur, then update a city dropdown based on the response, I simply added:

<input type="text" name="postal_code"
       hx-get="/api/cities"
       hx-trigger="blur"
       hx-target="#city-select"
       hx-swap="innerHTML">

That’s it. The server returns a <select> element with the correct options, and htmx inserts it. The logic lives on the backend, where it belongs. The front-end code becomes declarative and readable.

Practical Patterns for Croatian Interactive Forms

Real-Time Validation Without JavaScript

Croatian users expect instant feedback, especially on registration forms for local services. With htmx, I can validate an email address as soon as the user moves to the next field.

The pattern is simple: use hx-trigger="blur" on the input, send the value to a server endpoint, and return either an error message or a green checkmark. The validation logic is reusable across forms because it’s just a server route.

I built a booking form for a small hotel on the Dalmatian coast using this approach. The date picker fields check availability in real time. When a user selects an arrival date, htmx sends a request to the server, which returns available room types. The user never sees a loading spinner, and I wrote zero front-end validation code.

Multi-Step Wizards with Zero Page Reloads

Multi-step forms are common in Croatia for loan applications, insurance quotes, and event registrations. Traditionally, you either reload the page between steps or build a complex single-page application with state management.

htmx makes this trivial. Each step is a server-rendered HTML fragment. The “Next” button triggers a POST request with the current step’s data, and the server returns the next fragment. The form state persists on the server side, so there’s no risk of data loss if the user closes the tab.

One of my clients runs a Croatian startup accelerator. Their application form has six steps, including file uploads and conditional questions. With htmx, the entire experience feels like a modern web app, but the backend is a standard Django form. The development time was cut by more than half compared to a jQuery implementation.

Dynamic Field Addition Without Clunky JavaScript

Adding repeatable fields, like multiple phone numbers or guest names, is a common requirement. jQuery solutions usually involve cloning DOM nodes and incrementing IDs, which quickly becomes error-prone.

With htmx, I use a simple pattern: a button that sends a GET request to a server endpoint, which returns a new field group as HTML. The button’s hx-target points to a container div, and hx-swap="beforeend" appends the new fields. The server handles the numbering and validation logic.

I implemented this for a Croatian membership form that needed dynamic skill tags. The result was clean, maintainable, and required zero custom JavaScript for the dynamic part.

Handling Edge Cases the htmx Way

File Uploads Without a Page Refresh

File uploads are notoriously tricky with traditional form submissions. jQuery solutions often involve hidden iframes or complex FormData manipulation. htmx handles this natively with the hx-encoding="multipart/form-data" attribute.

For a Croatian legal document submission portal, I built an upload form that shows a progress bar and a preview thumbnail after each file is processed. The server returns the thumbnail HTML, and htmx replaces the progress bar with the result. The user stays on the same page, and the code is straightforward.

Conditional Sections Based on User Input

Croatian forms often have conditional sections that appear based on previous answers. For example, if a user selects “Company” as their account type, additional fields for VAT ID and company registration number should appear.

With jQuery, you typically listen for change events and toggle visibility with show() and hide(). With htmx, I send the selected value to the server, which returns the appropriate HTML fragment. This approach ensures the conditional logic is consistent and testable on the backend.

The key advantage is that the server knows the full context. It can pre-populate fields, apply different validation rules, and even return entirely different form structures based on the user’s choice.

Why This Matters Specifically for Croatian Developers

Local Infrastructure Considerations

Croatian web hosting is often shared or low-tier, especially for small businesses. jQuery-based forms that load heavy JavaScript bundles can feel sluggish. htmx shifts the processing load to the server, which handles HTML rendering efficiently. The client-side payload remains minimal.

I’ve tested htmx forms on Croatian mobile networks with 3G speeds. The experience is surprisingly snappy because the HTML fragments are small and the library itself is lightweight. Users don’t wait for JavaScript to parse and execute before they can interact.

Alignment with Croatian Development Culture

Many Croatian developers come from backend-heavy backgrounds, especially PHP (Laravel) or Python (Django). htmx plays perfectly into that strength. You write forms the way you already know, with server-side validation and template rendering, but the interactivity feels modern.

I’ve seen teams in Zagreb and Split adopt htmx because it reduces the need for a dedicated front-end specialist. A single developer can build the entire form, from database schema to interactive UI, without context switching between languages.

The One Thing That Surprised Me

The Debugging Experience Is Better

I expected debugging to be harder with htmx because there’s no explicit JavaScript to step through. In practice, the opposite is true. When something goes wrong, I look at the network tab. The request and response are plain HTML. I can see exactly what the server sent back.

With jQuery, I often had to add console.log statements to track down why a DOM element wasn’t updating. With htmx, the problem is almost always on the server side, which is where my expertise lies. That shift in debugging focus saved me hours on a recent Croatian NGO membership form project.

You Still Need JavaScript Sometimes

htmx handles 90% of form interactivity, but not everything. Complex client-side calculations, real-time chart updates, or custom drag-and-drop interfaces still benefit from dedicated JavaScript. The difference is that you only write JavaScript for the parts that genuinely need it.

For a Croatian financial calculator form, I used htmx for the form submission and result display, but wrote a small vanilla JS script for the live interest rate calculation. The codebase stayed clean and focused.

A Concrete Example: The Croatian Tax Declaration Form

Let me walk you through a real project. A client needed a tax declaration helper form for freelancers in Croatia. The form had to:

• Validate OIB (personal identification number) in real time
• Show different sections based on income type
• Calculate estimated tax dynamically
• Submit the final data to a backend API

With jQuery, I would have written event handlers for each input, AJAX calls for validation, and a state machine for the conditional sections. The code would have been at least 200 lines of JavaScript.

With htmx, I built it in under 50 lines of HTML attributes. The OIB validation field uses hx-trigger="blur" and hx-post="/validate-oib". The income type selector uses hx-get="/tax-sections" to load the appropriate form fields. The tax calculation is handled by a server-side function that returns the result as HTML.

The client was thrilled because the form felt responsive, and I was thrilled because the code was maintainable. When they later asked for a new income type, I added a new server-side template and updated the dropdown options. No JavaScript changes needed.

The Practical Takeaway

If you’re building interactive forms for Croatian websites, start with server-rendered HTML and add htmx for the interactive parts. You’ll write less code, maintain it more easily, and deliver a faster experience to your users.

Next time you reach for jQuery, ask yourself: does this really need a library, or can I express this interaction as an HTML attribute? The answer will surprise you more often than not.

I’ve stopped including jQuery in my form projects entirely. htmx handles the heavy lifting, and my productivity has never been higher. The Croatian web development community is small but resourceful, and adopting tools that align with our backend strengths is a smart move.

Try building your next contact form or registration wizard with htmx. You might find, as I did, that the simpler approach is also the more powerful one.