Do You Actually Need TypeScript on a Marketing Site?

Do you actually need TypeScript on a marketing site?

If your site has build scripts, a CMS integration or an API route, yes. If it is templates and CSS with a little sprinkled JavaScript, no. The deciding factor is whether data flows through your code from somewhere you do not control. That is where types pay for themselves and nowhere else.

This argument usually gets fought on principle, which is why it never resolves. One side says types catch bugs. The other says a marketing site has almost no logic to catch bugs in. Both are right about different sites.

Here is how we decide it on real projects, and what has changed in the last year that makes the decision cheaper either way.

What does TypeScript actually do?

It checks your code before it runs. The TypeScript handbook puts the distinction plainly: "JavaScript only truly provides dynamic typing, running the code to see what happens. The alternative is to use a static type system to make predictions about what the code is expected to do before it runs."

What it catches is broader than most people assume. The handbook lists typos in method names, functions you forgot to call, basic logic errors and accessing properties that do not exist. It describes these as "non-exception failures," meaning the cases where JavaScript does not throw an error and quietly does the wrong thing instead.

What it does not do is change anything at runtime. The handbook is unambiguous: "Type annotations never change the runtime behavior of your program." Your users get the same JavaScript either way. TypeScript is a tool for the people writing the site, not for the people visiting it.

Where does it genuinely earn its place?

At every boundary where data arrives from somewhere else. A CMS response, a form handler, an API you call, an environment variable, a JSON file someone else maintains. These are the places where a field gets renamed and nothing complains until a page renders blank in production.

Build scripts are the second case, and on a prerendered site they are the most important one. If a script fetches content and writes files that become your pages, a silent failure there produces a broken site rather than a broken component. That code deserves types even when nothing else does.

The third case is team size. Types are documentation that cannot go stale, which matters most when the person reading the code is not the person who wrote it. On a site one developer maintains, that benefit is smaller than the advocates claim. Our piece on over-engineering marketing sites covers the same trade in other areas.

Where is it mostly ceremony?

Sprinkled interactivity. A mobile menu toggle, a scroll-triggered class, an accordion. This code is short, fully visible on one screen, and has no external data. Adding a type system around it is overhead without a matching benefit.

Marketing pages that are genuinely static are the same. If your page is HTML and CSS with no data fetching, there is nothing for a type checker to check. The tooling cost is real and the return is close to zero.

And one-off campaign pages with a short life. If a page exists for six weeks around a launch, the maintenance argument for types does not apply, because nobody will maintain it.

How common is TypeScript now?

Common enough that the question is becoming what to exclude rather than what to include. The State of JS 2025 survey reports respondents splitting their time at an average of 77 percent TypeScript, with 4,367 respondents writing 100 percent TypeScript against 661 writing none. Individual questions in that survey drew roughly 9,700 to 10,900 responses.

The survey also reports that 86 percent of browser-targeted JavaScript goes through a build step, with static typing cited as the top advantage by 7,891 respondents. Treat those as a picture of the surveyed developer population rather than of all web development, since a voluntary survey skews toward engaged developers.

Still, the direction matters for hiring and handover. If you are building a site someone else will maintain, the convention in the wider ecosystem is part of the decision.

What changed with Node running TypeScript natively?

The setup cost dropped, which changes the calculation for build scripts specifically. Node.js documentation lists type stripping as stable, noting "type stripping is now stable" as of v25.2.0 and v24.12.0, with the separate transform flag removed in v26.0.0.

The mechanism is simple by design. Node's docs state: "By default Node.js will execute TypeScript files that contains only erasable TypeScript syntax. Node.js will replace TypeScript syntax with whitespace, and no type checking is performed." So you get to write and run typed scripts directly, with no bundler in between.

Note that last clause carefully. Node strips types, it does not check them. Running a file successfully proves nothing about its types. You still need a separate check step, which Node's own recommended configuration reflects by setting noEmit to true.

What are the sharp edges of native type stripping?

Some TypeScript features do not survive it. Node's documentation explains why: "Since Node.js is only removing inline types, any TypeScript features that involve replacing TypeScript syntax with new JavaScript syntax will error."

The features it names are enum declarations, namespaces containing runtime code, parameter properties, import aliases and decorators. Node's suggested configuration includes erasableSyntaxOnly, which stops you writing those by accident rather than discovering them at runtime.

There is one more trap worth memorising. Node's docs warn that "the type keyword is necessary to correctly strip type imports. Without the type keyword, Node.js will treat the import as a value import, which will result in a runtime error." So write import type explicitly. This bites people who copied working code from a bundled project.

Does TypeScript affect site performance?

No, and this deserves stating clearly because it comes up in almost every one of these conversations. Types are erased. The handbook says annotations never change runtime behaviour, and there is nothing left of them in the JavaScript a browser receives.

What can affect performance is the build pipeline you adopt alongside TypeScript. If choosing types means adding a framework, a bundler and a dependency tree, the weight comes from those choices, not from the type checker.

So keep the decisions separate. You can add TypeScript to a build script on a site that ships no framework JavaScript at all, and your Core Web Vitals will not notice.

What is the practical middle path?

Type the edges, not the middle. Put types on your content fetching, your CMS mapping, your API handlers and your build scripts. Leave the small interaction code as plain JavaScript. This gets most of the benefit for a fraction of the ceremony.

You can also get a large share of the value without adopting TypeScript syntax at all, by writing JSDoc comments and enabling checkJs. That keeps your files as ordinary JavaScript while still catching mismatches, which is a good fit for a small site with one maintainer.

Whichever you pick, make it a decision rather than a default. The failure we see most often is a marketing site carrying a full typed build pipeline because that is what the product repo does, maintained by someone who does not want it and does not use it. Our notes on sharing a monorepo between a marketing site and an app cover where that pressure comes from.

So what should you do on your next build?

Ask one question: does code in this site read data it did not create? If yes, type that path. If no, do not add a type system to prove a point. It is that simple, and it survives contact with real projects better than any general rule about best practice.

Then make sure whatever you choose is actually enforced. A repo with type annotations and no checking step in continuous integration has the cost of types and none of the safety, which is the worst of both.

If you want to talk through the right setup for a site your team will have to live with for years, we are happy to walk through it. Find us at phoenix.studio.