Why I Replaced React with Plain JavaScript for Croatian Landing Pages

I remember the exact moment I questioned my loyalty to React. I was optimizing a landing page for a small business in Split, and the React bundle—even after tree-shaking—was still over 100KB before any of the actual content loaded. For a page that needed to convert visitors in under three seconds, that felt like I was shooting the client in the foot before they even started.

The Real Cost of a Framework for Simple Pages

Most landing pages in Croatia serve a straightforward purpose: present an offer, build trust, and capture a lead. They aren’t dashboards, social feeds, or real-time collaboration tools. Yet, for years, I kept reaching for React out of habit. The problem? I was paying a hidden tax every single time.

The Bundle Size That Kills Mobile Conversions

Croatia has excellent 4G coverage in cities like Zagreb, Rijeka, and Osijek, but mobile data can still be expensive. Visitors on prepaid plans often hesitate before loading a heavy page. React’s runtime, plus the virtual DOM diffing logic, adds roughly 30–40KB gzipped overhead. For a landing page that could ship 15KB of pure HTML and CSS, that’s a 300% increase in weight for zero visible benefit to the user.

I tested this on a client’s promotion for a local winery. The React version loaded in 2.8 seconds on a mid-range Android phone. The plain JavaScript version, with the same design and animations, loaded in 1.1 seconds. That 1.7-second difference directly correlated with a 14% higher conversion rate during the two-week A/B test.

Framework Lock-In for a One-Page Site

Another hidden cost is the learning curve for the person who will maintain the site next. Many Croatian web agencies are small—two or three developers, sometimes freelancers. If you build a landing page in React, the next developer must know JSX, hooks, and the build toolchain. A plain JavaScript file, even if messy, can be understood by any developer who knows the language. I’ve seen clients struggle to find affordable maintenance after the original developer moved on.

When Plain JavaScript Outperforms React

I’m not arguing that React is bad. I’m arguing that its strengths are wasted on most Croatian landing pages. Let’s look at what plain JavaScript actually does better in this specific context.

Direct DOM Manipulation for Animations

Landing pages often rely on scroll-triggered animations—fade-ins, slide-ups, parallax effects. React’s reconciliation process adds a layer between your code and the actual DOM. If you want a smooth scroll animation that runs at 60 frames per second, you end up fighting React’s batching or resorting to useRef and manual DOM calls anyway.

I wrote a simple intersection observer handler in 20 lines of plain JavaScript for a real estate agent’s page in Dubrovnik. The animations fired immediately, without any re-render cycles. The client noticed the difference when scrolling on an older iPad. With React, the same animation had a noticeable hitch on every scroll.

State Management for a Contact Form

A landing page’s most complex interactive element is usually a contact form. React’s useState works fine, but it’s overkill. You can handle form validation, submission, and error display with a few event listeners and a plain object. The code is shorter, easier to debug, and doesn’t require any npm installs.

Here’s a concrete example. For a tourism agency in Zadar, I built a contact form that sends data to a PHP backend. The React version had 180 lines of component code. The plain JavaScript version had 65 lines. Both worked identically. The JavaScript version loaded faster and was easier for the client’s junior developer to modify later.

Building a Croatian Landing Page Without React

If you’re convinced that plain JavaScript might be the better choice, here is the practical workflow I’ve settled on after several projects.

Start with Static HTML, Then Layer Behavior

I write the entire page as static HTML and CSS first. No JavaScript at all. This forces me to ensure the page works without any scripting—a basic accessibility requirement and good for SEO. Once the layout and content are solid, I add JavaScript only for the interactive parts: form validation, mobile menu toggle, and scroll animations.

This approach also means the page renders instantly on the first paint. Search engines like Google see the full content immediately, which helps with local SEO for terms like “najam apartmana Split” or “web dizajn Zagreb.”

Use Modern Browser APIs

Modern browsers support everything a landing page needs without libraries. I use:

• IntersectionObserver for lazy-loading images and triggering animations.
• fetch for form submissions instead of Axios.
• CSS custom properties for theming instead of a CSS-in-JS library.
• The details and summary elements for FAQ accordions instead of custom state logic.

These APIs are well-supported across the browsers Croatian visitors actually use. Chrome and Safari dominate here. Even older Android browsers support IntersectionObserver.

Organize Code Without a Framework

I keep my JavaScript in a single file, organized by feature with clear comments. I use a simple module pattern with an IIFE (Immediately Invoked Function Expression) to avoid polluting the global scope. For larger projects, I split code into separate files and concatenate them with a simple build script.

The key is to avoid premature abstraction. A landing page doesn’t need a component architecture. It needs a script that runs when the page loads and handles a few specific interactions. You can always refactor later if the page grows into something more complex.

When You Should Still Use React

I’m not a purist. There are legitimate reasons to use React for Croatian web projects. If your landing page includes a real-time booking widget, a complex map with many markers, or a multi-step form with conditional logic, React’s state management becomes valuable. Also, if your team already knows React and the page will later expand into a full web app, starting with React might save time.

But ask yourself honestly: does the page need to re-render every time a user types in an input field? Most landing pages do not. They serve content and collect leads. For that mission, plain JavaScript is leaner, faster, and easier to maintain.

A Practical Takeaway for Croatian Developers

Next time you start a landing page project for a local client, try this: build the first version with zero JavaScript frameworks. Write the HTML and CSS directly, then add interactivity with vanilla JavaScript. Time the total development from start to finish. I’ll bet you finish faster than if you had set up a React project with Webpack, installed dependencies, and configured routing for what is essentially a single page.

You will also deliver a page that loads instantly on any device, costs less to host, and is easier for another developer to pick up later. That is a competitive advantage in a market where speed and reliability matter more than developer convenience.

The web is moving toward lighter, faster experiences. Core Web Vitals are now ranking signals. Croatian users on limited data plans will thank you for a page that loads in under two seconds. And you might find, as I did, that you enjoy writing plain JavaScript again—it’s just you, the browser, and the DOM. No abstraction layer needed.