Why I Replaced Vite with a Simple Makefile for Croatian Static Sites

I’ve built dozens of static sites for Croatian clients—from small obrt websites to tourism landing pages for Istrian villas—and for the last two years, Vite was my default tool. But recently, I deleted vite.config.ts from my project and replaced it with a simple Makefile. Here’s why that decision made my workflow faster, more transparent, and better suited to the specific constraints of building for a Croatian audience.

The Real Problem with Vite for Small Static Sites

Vite is an excellent tool. Its hot module replacement and fast dev server are genuinely impressive. But I started noticing that for the projects I actually ship—simple brochure sites, local business pages, or event microsites—Vite was over-engineering the solution.

Configuration Drift and Setup Overhead

Every new Vite project starts with npm create vite@latest, which pulls in dozens of dependencies. For a Croatian tourism site that needs three HTML pages, a CSS file, and maybe a handful of images, that’s absurd. The node_modules folder alone often exceeds the total size of the actual site content. I’ve seen projects where the configuration file is longer than the site’s main stylesheet.

The problem isn’t just file size. It’s the mental overhead. When I come back to a Vite project six months later, I have to remember which plugins I installed, what the build.rollupOptions does, and whether I customized the base path for relative URLs. For a site that hosts a local winery’s opening hours and contact form, that complexity is a liability, not a feature.

Croatian Hosting Realities

This is the part that made me switch. Many Croatian hosting providers still run older PHP versions and serve files with Apache or LiteSpeed. They don’t expect SPAs or complex asset pipelines. When I deploy a Vite-built site to a shared hosting package from a Croatian provider, I often encounter issues with relative paths, missing .htaccess rewrites, or incorrect Content-Type headers for .mjs files.

I’ve debugged sessions where a client’s site served blank pages because the hosting’s mod_mime didn’t recognize JavaScript modules. The fix was trivial—add a line to .htaccess—but it’s a friction point that doesn’t exist when I use a simple Makefile that outputs plain HTML and CSS.

Building a Makefile Workflow That Actually Works

I didn’t abandon modern tooling entirely. I just stripped it down to what’s necessary. A Makefile, combined with a few command-line tools, handles everything Vite did for my static sites, but without the abstraction layer.

The Core Makefile

Here’s the minimal Makefile I use for Croatian static sites. It assumes you have make, sass, and imagemagick installed—all available via apt or brew:

# Makefile for Croatian static sites
SITE_DIR = site
BUILD_DIR = build

.PHONY: build clean serve

build: clean
	@mkdir -p $(BUILD_DIR)
	cp -r $(SITE_DIR)/* $(BUILD_DIR)/
	sass $(SITE_DIR)/styles/main.scss:$(BUILD_DIR)/styles/main.css
	convert $(SITE_DIR)/images/hero.jpg -resize 1200x800 $(BUILD_DIR)/images/hero.jpg
	convert $(SITE_DIR)/images/hero.jpg -resize 600x400 $(BUILD_DIR)/images/hero-thumb.jpg
	@echo "Build complete: $(BUILD_DIR)"

clean:
	rm -rf $(BUILD_DIR)

serve:
	cd $(BUILD_DIR) && python3 -m http.server 8080

That’s it. Twelve lines. It copies HTML files, compiles Sass to CSS, resizes images, and serves the result. No package.json, no node_modules, no build cache to invalidate.

Handling Asset Pipelining Without a Bundler

The common objection is: “But what about minification, cache busting, and asset hashing?” My answer: for most Croatian static sites, you don’t need them. If your site has 50 KB of CSS and 200 KB of images, minification saves you maybe 20 KB on first load. The overhead of setting up a hashing strategy isn’t worth it.

When I do need minification, I add a single line to the Makefile:

sass --style compressed $(SITE_DIR)/styles/main.scss:$(BUILD_DIR)/styles/main.css

For JavaScript, I use terser directly or just write plain ES6 modules that the browser loads. Croatian hosting providers support HTTP/2 now, so multiple small files load faster than a single bundled blob anyway. This is especially true for mobile users on 4G in Dalmatia—they download fewer total bytes with direct loading than with a bundled SPA framework.

Real-World Example: A Croatian Restaurant Site

Last month, I rebuilt a site for a konoba in Split. The owner wanted a simple one-pager: menu, location, contact form, and a photo gallery. The old site used Vite with React, which the previous developer had set up. It had 14 dependencies, a 400-line webpack config (migrated from an earlier era), and took 45 seconds to build on my machine.

I migrated it to the Makefile approach. The new site has:

• 3 HTML files (hand-written, no templating)
• 1 Sass file (compiled to CSS)
• 8 JPEG images (resized with ImageMagick)
• 1 JavaScript file (vanilla, for the contact form validation)

The build time dropped from 45 seconds to 0.8 seconds. The total project size went from 180 MB (mostly node_modules) to 2.1 MB. The client’s hosting—a cheap shared plan from a Croatian provider—serves the site without any configuration changes.

What I Gave Up

I lost hot module replacement. I no longer get instant CSS updates in the browser while editing. But for a 3-page site, I just save the file and refresh the browser manually. The time saved on build and deploy more than compensates for the occasional manual refresh.

I also lost the ecosystem of Vite plugins. No PostCSS autoprefixing, no automatic image optimization, no TypeScript compilation. But I write plain CSS with vendor prefixes manually (or use autoprefixer as a standalone tool in the Makefile). For TypeScript, I don’t use it on static sites—it’s overkill for a project that compiles to three HTML files.

When Makefiles Beat Vite (and Vice Versa)

This workflow isn’t a universal replacement. It’s a targeted tool for a specific problem: small, static, content-driven websites that serve a Croatian audience.

Makefile Wins for Small Static Sites

You should consider a Makefile when:

• Your site has fewer than 10 pages
• You’re the only developer
• You deploy to shared hosting with limited Node.js support
• You value build speed over developer experience niceties
• Your content changes infrequently (weekly or monthly)

In these cases, the Makefile approach eliminates the dependency tax. You never worry about breaking changes in tooling, supply chain attacks on npm packages, or build failures due to version mismatches. The site is just files on disk.

When to Stick with Vite

I still use Vite for larger projects. If I’m building a web app with client-side routing, API calls, and state management, Vite’s ecosystem is essential. For a Croatian e-commerce site or a membership portal, I reach for Vite without hesitation.

The boundary is clear: if your site needs JavaScript to render content, use Vite. If your site renders content that just happens to use JavaScript for interactivity, use a Makefile.

Practical Takeaway: Start Simple, Add Complexity Only When Proven Necessary

The next time you start a static site for a Croatian client, resist the urge to npm create something. Open a terminal, type touch Makefile, and write the three rules that actually matter: copy files, compile styles, resize images. You’ll have a working site in minutes, not hours.

When the client asks for a feature that genuinely requires a bundler—like code splitting or tree shaking—you can add it then. But you’ll discover that for the vast majority of Croatian static sites, those features never become necessary. The Makefile will still be there, doing its job, with zero dependencies and zero surprises.

I keep a Vite project template on my machine for when I need it. But for the last six projects, I haven’t used it once. The Makefile workflow has become my default, and I expect it to stay that way for the foreseeable future.