Why I Stopped Using TypeScript for Small Croatian Sites

I was building a small landing page for a family-run winery in Istria, and the client just wanted a simple form and a gallery. I reached for TypeScript out of habit, and by the time I had the config files, type definitions, and build pipeline sorted, I had spent more time setting up than actually building the site. That’s when I started questioning whether TypeScript was really helping me or just getting in the way.

For years, I had bought into the hype: TypeScript catches bugs, improves readability, and scales beautifully. And it does—for large applications. But here in Croatia, most of my work involves small business sites, local shops, event pages, and personal portfolios. These projects don’t need a type system; they need speed, simplicity, and a clear path to deployment. So I made the switch back to plain JavaScript, and I haven’t looked back.

The Real Cost of TypeScript on Small Projects

Setup Overhead That Adds Up Fast

Every TypeScript project starts with a ritual: install the compiler, configure tsconfig.json, set up a build tool like Webpack or Vite, and decide on strict mode settings. For a small site with three pages, that’s fifteen minutes you could have spent writing actual features. Over a dozen projects a year, that’s three hours of pure configuration work.

I remember a project for a local bakery in Zagreb—five pages, a contact form, and an Instagram embed. I set up TypeScript, added ESLint with TypeScript rules, and then realized the client wanted a simple CMS integration. The types for the CMS library were outdated, so I had to write custom declarations. The whole setup took three times longer than building the site itself.

The Build Step That Slows You Down

TypeScript needs to be compiled to JavaScript before it runs. That adds a build step to your development workflow. For a small site, you might be using a simple static site generator or even just plain HTML with inline scripts. Now you need a bundler, a dev server with hot reload, and a build script for production. Every change requires a compile cycle.

Compare that to plain JavaScript: you write a .js file, link it in your HTML, and refresh the browser. No build step, no waiting, no configuration. For a two-page site, that’s the difference between a ten-minute update and a one-minute update. Over time, those minutes add up to real productivity loss.

When TypeScript Actually Helps—and When It Doesn’t

The Sweet Spot for TypeScript

TypeScript shines when you have a large codebase with multiple developers, complex data structures, or long-lived projects that need refactoring. Think e-commerce platforms, SaaS dashboards, or internal tools. In those cases, the type system pays for itself by preventing bugs and improving collaboration.

But most Croatian small business sites don’t fit that profile. They’re built by one person, have a few hundred lines of code, and are updated once a year. The types you define today will likely be irrelevant by the time the client asks for changes. You’re maintaining a system that nobody else will ever read.

The False Sense of Security

TypeScript can catch type mismatches, but it doesn’t catch logic errors, API changes, or broken business rules. I’ve seen developers spend hours fixing type errors only to discover the real bug was a missing await or a wrong endpoint URL. The type system gives you confidence in the wrong places.

For example, I once typed an API response perfectly, but the backend changed the field names without notice. TypeScript compiled fine, but the site broke in production. The type system didn’t save me—it just delayed the debugging. On small projects, you’re better off testing manually and moving fast.

Practical Alternatives for Small Croatian Sites

Plain JavaScript with Modern ES Features

Modern JavaScript (ES6+ and beyond) has evolved significantly. You get const, let, arrow functions, destructuring, optional chaining, and nullish coalescing. These features make code cleaner and safer without a type system. Plus, you can use JSDoc comments for basic type hints if you really need them.

Here’s a concrete example: instead of defining a TypeScript interface for a product, I just write a plain object and use destructuring in the function signature. It’s readable, testable, and requires zero setup. For a small site, that’s all you need.

Simple Tooling That Doesn’t Get in the Way

Skip the bundlers and build tools for tiny projects. Use a lightweight server like http-server or just open the HTML file directly. For styling, use plain CSS or a utility framework like Tailwind without the build step. For interactivity, write vanilla JavaScript in a <script> tag.

One of my favorite workflows now: I create an index.html, a style.css, and a script.js file in a folder. I open it in the browser, and I’m coding instantly. No npm install, no tsconfig.json, no build errors. It’s liberating.

When to Consider TypeScript (Even for Small Sites)

I’m not dogmatic about it. If the site uses a complex library with TypeScript definitions, or if I plan to reuse the code later, I might use TypeScript. Also, if the client is a tech-savvy startup that might grow, it’s worth the setup. But for 90% of Croatian small business sites, plain JavaScript is the better choice.

A Concrete Example: A Local Restaurant Site

I recently built a site for a konoba in Split. The requirements: a menu page, a reservation form, and a Google Maps embed. I wrote the whole thing in plain JavaScript with ES modules. The entire project was three files totaling about 200 lines of code.

If I had used TypeScript, I would have needed a tsconfig.json, type definitions for the Google Maps API, a module bundler, and a build step. The site would have taken twice as long to build and would have required a build tool to update. The client didn’t care about types—they cared about the reservation form working.

The result? The site loads instantly, updates are a drag-and-drop file replacement, and I can hand it over to the client knowing they can edit it with any text editor. No lock-in, no complexity.

The Takeaway: Choose the Right Tool for the Job

TypeScript is a powerful tool, but it’s not the right tool for every job. For small Croatian sites—local businesses, events, personal projects—plain JavaScript with modern features is faster, simpler, and more maintainable. The key is to match your tooling to the project’s actual needs, not to the hype or your own habits.

Next time you’re about to set up a TypeScript project for a small site, ask yourself: will the type system save me time in the long run, or will it just add overhead? If the answer is the latter, just write plain JavaScript. Your clients (and your future self) will thank you.