Why I Switched from Webpack to esbuild for Croatian Build Pipelines

I remember the exact moment: 2:47 AM, staring at a production build that had been running for almost four minutes. Our Croatian clients, mostly small businesses in Zagreb and Split, were starting to complain about deployment delays. That was the night I finally admitted to myself that Webpack, despite its power and flexibility, had become the bottleneck in our development pipeline.

The decision to switch from Webpack to esbuild wasn’t about chasing the latest trend. It was about cold, hard numbers: build times that dropped from 180 seconds to under 6 seconds. For a small team building websites for Croatian businesses, that difference meant the ability to iterate rapidly, test fixes immediately, and deploy to production without the afternoon coffee break Webpack demanded.

The Real Problem with Webpack in a Small Market Context

Webpack is an incredible tool. It’s battle-tested, has an ecosystem that can handle almost any edge case, and offers configuration depth that borders on the absurd. But for teams like ours—five developers, a handful of clients, and a focus on delivering value rather than engineering perfection—Webpack’s complexity was a tax we paid every single day.

Configuration Sprawl

Every new project started with the same ritual: copying a Webpack config from a previous project, then spending an hour tweaking loaders, plugins, and resolve aliases. The config file for our typical Croatian client project—a small business site with a blog, maybe an e-commerce section, and some custom animations—often ran over 200 lines. That’s 200 lines of module.rules, plugins, and optimization blocks that did nothing but translate modern JavaScript into something browsers could understand.

The real kicker? Most of those loaders were handling edge cases that never occurred. We were bundling TypeScript support, CSS extraction, image optimization, and polyfill injection for browsers that our Croatian audience rarely used. The average visitor to our clients’ sites comes from a modern Chrome or Firefox install on a decent phone. They don’t need the legacy baggage Webpack was hauling around.

The Slow Feedback Loop

Here’s where it hurt the most: development iteration speed. Croatian clients often request changes on the fly—a new product image, a revised headline, a different color scheme. With Webpack, even a small CSS change triggered a rebuild that took 8-12 seconds. That doesn’t sound terrible until you multiply it by twenty changes in an hour. You lose focus. You start batching changes to avoid the wait. You become less responsive to client needs because the tooling punishes you for being agile.

I had one client in Rijeka who runs a family hotel. She’d email me at 10 AM with a new room availability update, expecting it live by noon. With Webpack, I’d make the change, wait for the build, test it, notice a typo, fix it, wait again. The deadline became stressful not because the work was hard, but because the tool was slow.

Why esbuild Changed Everything

esbuild is a bundler written in Go, and that language choice is the core of its speed advantage. It doesn’t just optimize the bundling process—it parallelizes it at a level JavaScript-based tools simply cannot match. When I first ran esbuild on our main project, the build finished before I could blink. I literally checked if it had errored silently.

Raw Speed Comparison

Let me give you concrete numbers from our actual pipeline. Our main project—a multi-language site for a Croatian tourism agency with content in Croatian, English, and German—had the following build times:

• Webpack (production mode): 3 minutes 12 seconds
• Webpack (development mode with HMR): 22 seconds initial build, 8-12 seconds on incremental changes
• esbuild (production mode): 4.8 seconds
• esbuild (development mode with watch): 0.6 seconds initial build, under 100ms on changes

The production build difference is staggering. But the development experience is what truly changed our workflow. A 100ms rebuild means I can make a change, switch to the browser, and the update is already there. No waiting. No context switching. No frustration.

Simpler Configuration

esbuild’s configuration is intentionally minimal. You don’t configure loaders for every file type—you tell it what to do with JavaScript, CSS, and maybe a few other formats. Our entire esbuild config for that tourism agency project looks like this:

require('esbuild').build({
  entryPoints: ['src/index.jsx'],
  bundle: true,
  outfile: 'dist/bundle.js',
  loader: { '.js': 'jsx' },
  minify: true,
  sourcemap: true,
  target: ['chrome90', 'firefox88', 'safari14'],
}).catch(() => process.exit(1))

Compare that to the Webpack equivalent, which would require separate configuration for Babel, JSX handling, CSS loaders, image optimization, and environment-specific plugins. esbuild handles most of this out of the box with sensible defaults. For Croatian developers who want to spend time on client work, not tooling, this is a godsend.

The Trade-Offs You Need to Know (Honestly)

I’m not going to pretend esbuild is perfect. It has limitations that matter, especially if your project is complex. But for the majority of websites we build in Croatia—small to medium business sites, blogs, e-commerce stores—these trade-offs are acceptable.

Plugin Ecosystem

esbuild’s plugin system is functional but nowhere near Webpack’s depth. If you need esoteric features like custom AST transformations, Webpack is still the king. For us, the plugins we use are straightforward: React Fast Refresh, SVG optimization, and a custom plugin to inject environment variables. esbuild handles all of these without issue.

The bigger concern is long-term support. esbuild is maintained primarily by one developer, Evan Wallace. It’s a robust project with corporate backing (Figma uses it), but it doesn’t have the community safety net of Webpack. If a critical bug emerges, the fix timeline depends on one person’s availability. For Croatian developers who value stability, this is a legitimate consideration.

Code Splitting Limitations

esbuild’s code splitting works, but it’s less sophisticated than Webpack’s. Webpack can analyze your import graph and automatically split code into optimal chunks based on usage patterns. esbuild requires more manual intervention. For our typical projects, this isn’t a problem—most sites don’t have the scale where automatic code splitting makes a visible difference. But if you’re building a large single-page application with dozens of routes, Webpack’s automatic chunking might still be the better choice.

The Croatian Internet Factor

Here’s something I haven’t seen discussed elsewhere: esbuild produces slightly larger bundles than Webpack in some cases. Webpack’s tree-shaking is more aggressive and its minification (especially when paired with Terser) can produce smaller output. For Croatian users, many of whom access the internet via mobile data with limited speeds, bundle size matters.

In practice, the difference is usually 5-10% larger bundles with esbuild. For a typical 200KB site, that’s 10-20KB extra—a fraction of a second on a 4G connection. But if you’re optimizing for the slowest connections in rural areas of Croatia, that extra size could be noticeable. I’ve mitigated this by using esbuild’s minify option and enabling gzip compression on the server, which brings the difference down to negligible levels.

How I Migrated Our Pipeline (Step by Step)

The migration wasn’t an overnight switch. I ran both tools in parallel for two weeks, comparing outputs and catching edge cases. Here’s the approach that worked for our team.

Phase 1: Replace Development Server Only

Start by swapping out Webpack Dev Server for esbuild’s watch mode. This gives you the speed benefit immediately with minimal risk. You keep your production build on Webpack while you validate that esbuild produces correct output in development.

Create a simple script that runs esbuild in watch mode and serves the output directory with a lightweight HTTP server:

esbuild src/index.jsx --bundle --outfile=dist/bundle.js --watch &
serve dist -l 3000

We ran this for a week. The team immediately noticed the difference. Bugs in esbuild’s output (mostly around CSS handling) were caught and fixed during development rather than in production.

Phase 2: Validate Production Output

The next step is to run both tools in your CI/CD pipeline. Keep Webpack as the production builder, but add esbuild as a parallel step that builds to a separate directory. Compare the outputs: check that all assets are present, that the JavaScript executes correctly, and that the CSS renders properly.

This is where you’ll find the edge cases. For us, the biggest issue was that esbuild handles CSS @import statements differently than Webpack. Webpack inlines imported CSS into the bundle; esbuild keeps them as separate files. We had to adjust our build process to concatenate CSS files before passing them to esbuild.

Phase 3: Switch Production to esbuild

Once you’ve validated that esbuild produces equivalent output, make the switch. Keep the Webpack config as a fallback for one release cycle. If something breaks, you can revert in minutes.

The actual switch was anticlimactic. Our deployment went from taking 3.5 minutes to 8 seconds. The team celebrated with a round of coffee (still waiting for that to finish brewing, old habits die hard).

Practical Takeaway: Speed is a Feature for Your Clients

The biggest lesson from this migration wasn’t about tooling—it was about what speed means for your clients. Croatian businesses don’t care about your build system. They care about getting their website updated before their customers notice. They care about being able to fix a broken link during lunch hour. They care about launching their new product page before the competition.

esbuild gave us back the ability to deliver on those expectations without stress. Our deployment pipeline went from something we dreaded to something we could trigger while on a coffee break. The 3-minute build time wasn’t just a technical inconvenience—it was a business limitation that made us less responsive.

If you’re building websites for Croatian clients, look at your build pipeline honestly. Is it helping you deliver faster, or is it a tax you pay for complexity you don’t need? For most small to medium projects, esbuild is the right answer today. But keep an eye on the ecosystem—Vite, which uses esbuild under the hood for development, is gaining traction and might offer the best of both worlds: esbuild’s speed with a richer plugin system.

The future of frontend tooling is moving toward native-speed tools. Rust-based bundlers like Turbopack and Parcel 2 are already showing promise. For now, esbuild is the pragmatic choice for Croatian developers who want to spend their time building, not waiting.