Why TypeScript matters on a public site

TypeScript for websites is a guard for the next person who opens the repository. It checks that a button has a label, that a link has a destination, and that a card receives a title before it renders. Those checks fail in the editor, while the change is still private. The public site is spared a blank control and a broken layout.

The value is fewer broken props and safer edits. A sentence on the about page that names the language does not protect anyone. The protection is in the types the team actually keeps up to date, on the components the site is built from.

What a prop is, and how it breaks

A marketing site is a set of pieces. A project card. A navigation link. A section with a headline, a paragraph, and an image. In React, each piece is a component, and the data you pass into it is a set of props. Title, href, summary, image source. When a prop is missing or the wrong kind of value, the component guesses. The guess is often a blank gap, the word "undefined," or a link that goes nowhere.

That failure is easy to ship because the page still "loads." The founder looks at the homepage, which was not the file that changed, and calls the release fine. The project page, edited by someone adding a new case study, is the one with the hole. TypeScript refuses the build when the new case study does not match the shape the card expects. The next person sees the problem at the moment they make the edit, which is the moment they can still fix it.

Google's guidance on helpful, people-first content asks a question that sounds editorial and is also a quality bar for the interface: does the page look sloppy or hastily produced, and does it contain errors a reader can catch? A card that renders an empty title is that kind of error. The visitor cannot tell whether the project has no name or the template broke. TypeScript does not write the name. It stops the template from pretending the name was optional when the design required it.

A shape the next person can trust

The useful type is a description of a real thing on the site, written next to the component. A project card on a company site can look like this:

```ts
type ProjectCard = {
title: string;
href: string;
summary: string;
};
```

Whoever adds a project has to provide those three strings. If they pass a number where the title should be, or they forget the link, the editor marks the call site. They do not have to remember a wiki. The type is the note.

This is the protection for the next person in the repo. It might be the founder, six months later, with a contractor who was not in the original build. It might be the studio on a second engagement. It might be an in-house engineer touching the site for the first time on a Friday. The type tells them what a card is allowed to be. Clean code, in the sense that matters here, is a headline and a component they can find. Types are how those components stay honest after the finding. The companion piece, What clean code means on a marketing site, stays with that findability. This one stays with the checks that keep a found component from lying.

Hanabi writes its sites in TypeScript for this reason. The stack beside it, React and Next.js and Tailwind, is there to ship the page. The types are there so a later edit has a wall to bump into before the wall is a public blank.

What the types should cover

Cover the pieces that, if blank, would embarrass the company or break a path.

• Links and buttons: a destination and a name. A button with an empty label is invisible to someone using a screen reader and useless to everyone else.
• Content objects: the fields a section promises. If the design shows a quote and a name, both are required. An optional quote with a required name, or the reverse, should be an explicit choice, written in the type.
• Images that are content: a source and alt text. Decorative images can say so on purpose. The type should make "we forgot the description" different from "this image is decorative."
• Forms: the fields the server expects, so the client cannot submit a shape the action will reject.

Leave room for optional data when the design truly allows absence. An eyebrow label above a headline might be optional. Mark it optional in the type, and teach the component to render nothing, not a gap the size of the missing label. Absence should be a decision you can see in the code.

Shared types beat a fresh shape on every page. If the homepage and the work index both show projects, they should import one project type. Drift starts when each page invents a slightly different card and the new field is added to only one of them.

What TypeScript will not do

It will not choose the headline, the type ramp, or the offer. A fully typed page can still be vague. The checks confirm that the data arrived in the shape you declared. They do not confirm that the sentence is any good.

It will not make the site fast by itself. A typed component can still pull in a heavy library, ship an oversized image, or wait on a script before it paints. Performance is a separate review. Types keep the structure from collapsing while you do that review.

It will not replace a look at the page. Generated content, a CMS field left blank by the editor, and a string that is present but wrong ("Title goes here") all satisfy string. The type catches the missing prop. A person catches the bad sentence. Drafts and a preview URL are how that person gets the chance.

It will not help if the types are lies. A component typed as accepting any, or a habit of silencing errors so the deploy can proceed, removes the guard and keeps the ceremony. The rule worth keeping is small: no silenced error on a content component, and no any on the props a page passes in. If a shape is awkward, fix the shape.

How to ask for it in a build

You do not need to read the types to require them. Ask the studio where the shape of a project, a post, or a navigation item lives. Ask what happens if a required field is omitted. The answer you want is that the site fails to build, on a preview, with a message that names the field. The answer to refuse is that someone will notice on the live site.

Ask whether the next engineer, who was not in the kickoff, can add a page using the existing types without a private explanation. If the types are named after the business (Project, Post, Service) rather than after a temporary layout (HeroVariantThree), that engineer has a chance.

The repository should be yours, and the types should be in it, not in a separate document that rots. When the component changes, the type changes in the same commit. That is the whole discipline.

Hanabi's services are design and production code in one engagement, which is why the types and the layout are allowed to be one conversation. If you are hiring anyone to build a public site you will still be editing next year, ask for this guard by name. It is a quieter promise than a visual concept, and it is the one that keeps the concept intact after the first round of real edits.