Hello Charlie

3 Frontend RBAC Quiz: Would Your Permission Check Pass?

Charlie — Sat, 05 Sep 2026 00:00:00 GMT

I’ve got answers to the 3 questions from my last post. In that post, I wrote about 3 ways FE can handle authorization

Static routing
Server-driven UI
A granular permission array (instead of roles)

All three are different, but they share one root idea

FE isn’t about security. It’s about UX. Every decision still depends on the server.

Most apps run just fine on this idea. But the trouble starts once real users and real data pile up.

So I left 3 questions at the end of that post. Now I’m back to actually dig into them.

A user is filling in the third field of a form. Meanwhile, the admin quietly revokes their access.

This person has no idea yet.

The frontend doesn’t decide who’s authorized. It’s just a mirror of the server’s decision.

These three questions are really just one, in disguise.

When the mirror shakes. When the mirror breaks. Can you still stand up straight? Haha.

The frontend mirrors the server’s permission decisions.

Q1. What if permission gets revoked mid-action?

The user keeps typing. The admin has already pulled their access. The server won’t save it. That’s the server’s job.

The real problem comes next. The screen just keeps smiling, like nothing happened.

How do you get a real-time update?

You don’t want to be knocking on the server the whole time.

This is where SSE (Server-Sent Events) comes in.

All you really need is one signal: “Something changed.” You don’t need the full data, just the alert.

So… what if that signal gets lost while your connection drops? No worries.

You just send the ID of the last signal you got, and the server fills in the rest.

Q2. What do you trust when the network drops?

When you’re offline, you can’t just ask the server again.

So… should you trust the last permission you saw? Trusting it feels risky. What if it’s already outdated?

The answer is optimistic UI.

You trust the last known permission. Let the user keep working, and queue up whatever they do.

Why is this safe?

Because you can check everything again once you’re back online.

The permission you’re trusting isn’t a real decision. It’s just a temporary kindness.

It’s fine if it’s stale, because the client was never the one making the final call anyway.

So where does the unsynced work go?

Throwing it away is the easy answer. It’s also the wrong one.

An outbox keeps work waiting until it can be sent.

Think of a mailbox. You don’t throw away a letter just because the post office is closed. You drop it in, and it goes out once the office opens again.

Same idea here. You stack the actions in an outbox and send them out in order once you’re back online.

pending → syncing → (synced | rejected)

Q3. What about “I can only edit my own posts”?

This one’s the sneaky trap.

edit:posts tells you the user can edit posts. It doesn’t tell you whether they can edit this post.

So the check quietly turns into

const canEdit = can('edit:posts') && post.authorId === currentUser.id;

Looks fine at first. The problem is, this one line gets copy-pasted across every component.

That’s the mirror trying to make its own decisions.

The moment FE tries to reimplement the rule, FE has to be updated every time the policy changes.

So instead of shipping the rule, ship the decision.

The server calculates “Can this user do this?” per resource and sends it down with the data

{
  "id": "post_123",
  "title": "…",
  "_permissions": { "canEdit": true, "canDelete": false }
}

// FE just reads the decision
const canEdit = post._permissions.canEdit;

Now, even if the policy changes, your FE code doesn’t change a single line. The server just sends a different value.

(Quick tip: if you’re rendering a list of posts, batch these checks instead of asking one by one.)

Yeah, this value can go stale too. But that’s not a new problem.

The same two answers from Q1 and Q2 apply here

catch the signal and re-check, or trust it optimistically and re-verify later.

So, one rule to rule them all

All three questions really fold into one.

Permission changes in real time → catch the signal, ask again, but don’t wreck the user’s work.
The network drops → trust the last permission for a bit, then double-check with the server once you’re back.
Permission depends on the resource → don’t copy the rule over, just render the decision.

A mirror doesn’t make up answers. It just reflects.

5 Minutes into Frontend RBAC

Charlie — Sat, 05 Sep 2026 00:00:00 GMT

When it comes to permissions (RBAC) on the frontend, are you just hiding a button with if (role === 'ADMIN') and calling it done?

It works. Until it doesn’t. So before the patterns, the one rule most tutorials skip:

That’s your Single Source of Truth (SSOT). Keep that boundary clean and everything below is about experience. Blur it, and you’ve shipped a lock with the key taped to the door.

The frontend decides what to show; the backend decides what’s allowed.

Now, the three patterns.

Approach 1. Static Route Mapping (Config-Driven)

The simplest approach maps roles to routes.

ADMIN  -> Dashboard, Users
EDITOR -> Dashboard
VIEWER -> Dashboard (read only)

It works perfectly on day one. Then the requirements change.

A role needs access to part of a page. A new edge case fits none of your existing roles. Marketing wants editors to see one admin-only widget.

Now the role checks don’t live in one config file. They scatter across components, routes, menus, and feature flags.

The coupling grows quietly and you only notice the day you add one new role and break four screens you forgot existed.

Good for: small apps with few, stable roles.
Painful when: roles multiply or permissions get granular.

Here, the server decides. Instead of hardcoding menus, the frontend renders whatever the backend sends down—the navigation, the visible features, the allowed actions.

This shines in B2B SaaS, where every customer has a different plan and different permissions. You can’t hardcode that.

The trade-off is timing: a permission-aware UI can’t fully render until the payload arrives. But that’s not the blank screen a lot of write-ups make it out to be. Your shell and skeletons paint immediately, and caching the last known set lets returning users see their real UI right away.

A trade-off you manage, not a wall you hit.

Good for: multi-tenant products with per-customer permissions.
Painful when: you treat the permission fetch as blocking instead of progressive.

Approach 3. Granular Permissions

The third approach stops shipping roles to the frontend and ships a flat array of permissions instead.

["view:dashboard", "edit:users", "delete:comments"]

Now components don’t care who you are. They ask one question:

Do I have this permission?

<Can permission="edit:users">
  <EditUserButton />
</Can>

This is decoupling. The component knows nothing about admins, editors, or viewers. Only a single capability. Drop it anywhere, test it in isolation, reuse it without rewiring a role matrix.

It’s still RBAC. The roles don’t disappear. They move.

The backend keeps them, maps each one to a set of permissions, and sends down the resolved flat array. Roles stay a backend concern; permissions become the language the frontend speaks.

One honest cost: those strings multiply and aren’t type-checked. Typo "edit:users" and nothing complains until runtime. Govern them with a central registry or generated types before they drift.

Before You Go: A Few Things Worth Thinking About

These three patterns will carry most apps a long way. But the moment your product has real users and real data, a few questions show up that none of them answer cleanly.

I won’t solve them here. The answers deserve their own article, and honestly, the thinking is the valuable part. So let’s just sit with them.

What happens when a permission is revoked mid-action?

A user is three fields into a form when an admin pulls their access. The backend will reject the save—fine, that’s the SSOT doing its job. But should the UI let them keep typing into a dead end? How does the frontend even find out in real time, without hammering the server? And once it knows, how do you take access away without yanking half-finished work off the screen?
What do you trust when the network drops?

Offline-first apps can’t refetch permissions on demand. Do you trust the last permission set you saw and risk acting on stale rules? And if the user makes a change you can’t sync, where does that work go? Throwing it away is the easy answer. It’s also the wrong one.
What about “I can only edit my own posts”?

This is the sneaky one. edit:posts tells you the user can edit posts. Not whether they can edit this post. The check quietly becomes can("edit:posts") && post.authorId === currentUser.id. The moment your permissions depend on the resource and not just the user, plain RBAC starts to creak, and you’re standing at the doorway of a different model entirely.

None of these has a single right answer. They have trade-offs, which is exactly what makes them worth thinking through before you hit them in production.

So I’ll leave you with the question instead of the answer:

How would you handle each of these in your own app?

(That third one, in particular, is where I’d like to pick things up next time.)

[In Melbourne] Free Coffee Cupping: Five Senses ‘Get It India’

Charlie — Mon, 07 Sep 2026 00:00:00 GMT

Five Senses’ Get It India cupping is a free West Melbourne session on Thursday 24 September 2026. The organiser describes it as an Indian coffee programme with a tasting of coffees made using different processing methods. The event has not taken place yet, so the details here come from the published listing. Event listing.

AI-generated representative image of coffee cupping.

Event details

When: Thursday 24 September 2026, 5:30–7:30 pm, Melbourne local time.
Where: Five Senses Barista Academy, 300 Rosslyn Street, West Melbourne VIC 3003.
Price: Free (A$0).
Booking: Reserve a spot through Eventbrite.

Five Senses lists the same address on its academy contact page. Recheck Eventbrite before you book or travel, because ticket availability and event details can change.

What the session covers

The Eventbrite listing says the evening covers Indian coffee’s history and growing conditions, with Veer Attikan and Gungegiri estates named in the programme. It also says the tasting will explore innovative processing methods.

If cupping is new to you

Five Senses’ cupping guide describes cupping as a way to compare coffee samples side by side for flavour, acidity, body and aftertaste.

For your own notes, start with a plain comparison: which cup feels fuller, or which flavour stays with you longer? Write down what you notice in ordinary words. You could also ask which estate each sample comes from and how it was processed. These are tasting prompts, not promises about how this session will be run.

The listing does not explicitly confirm beginner suitability. If this would be your first cupping, ask Five Senses whether the session suits newcomers and whether you need to bring anything. Check any access requirements with the venue before booking.

Details checked: 7 September 2026. For the latest ticket information, use the original event page.

[In Gold Coast] Whale watching with Sea World Cruises

Charlie — Tue, 15 Sep 2026 00:00:00 GMT

I joined Sea World Whale Watch on the Gold Coast on 11 September 2026, at 3 pm.

We got to see both a mother whale and her calf! I felt a little seasick, but the photos and video below capture what we saw out on the water.

Whale watching with the city still in view. Photos and video supplied by Charlie.

Finding the boat

The blue Sea World Cruises sign makes the terminal easy to recognise. In the photo below, the entrance is beside the Sea World ferry-stop sign.

The terminal entrance.

The blue-and-white boat is tied up alongside the pontoon. There are open viewing areas on the upper decks, and you can see passengers already waiting on board.

The boat at the pontoon before heading out.

A closer look at the boarding area and upper decks.

Whales above the waves

Out at sea, the photos show choppy water and whitecaps.

One catches a whale almost upright above the surface, surrounded by a patch of white water. The beachfront towers are visible behind the whale in the other photo.

A whale above the surface, with spray hanging over the water.

The short video catches a different moment: a tail lifts above the surface and disappears, followed later by a whale’s back coming into view. The coastline stays in the background throughout the clip.

Watch the 15-second whale-watching video. Opens as a video with playback controls and the original sound.

A little seasickness, and a jacket helps

I felt a little seasick during the trip.

Before departure, seasickness tablets were being sold on board for A$4. That was the price on my visit. Check with the operator for current availability and pricing.

It can feel a little cold out at sea, so bring a warm layer even if you feel comfortable on shore.

Before you book

These are moments from this trip. The photos aren’t a promise of what another sailing will see.

Check the departure point and arrival instructions on your own booking, and leave room in your plans for any changes the operator announces.

Sea World Cruises asks guests to arrive about 30 minutes before departure and allow up to 2.5 hours for whale watching.

Its packing advice includes enclosed flat shoes and a warm jacket. Check the operator’s FAQ when planning your visit.

The whale-watching departure point is Sea World Cruises Terminal, Seaworld Drive, Main Beach, beside the theme park’s main entrance.

Use the official directions to plan your journey, and check the terminal guide if you need access information.

We Already Have LLMs. Why Does Jev Exist?

Charlie — Thu, 17 Sep 2026 00:00:00 GMT

AI-generated conceptual illustration. This is not a Jev product screenshot.

Jev is a decision model from TypeSafe. The developer defines the questions. Jev returns a choice, a score or a yes probability that application code can use. Modern LLMs can do the same jobs, but Jev is designed around this narrower role.

Route a refund request

Suppose a customer writes:

I was charged twice and I want my money back.

A support classifier only needs to decide which team should receive the request.

The developer defines the possible answers first, such as refund, explain_charge and other. Jev selects one. Ordinary code handles the next action.

The object and 0.96 below are invented for explanation. They are not the result of a live Jev call or a TypeSafe SDK shape. The value does not mean 96 per cent accuracy.

// Hypothetical application adapter, not a TypeSafe SDK signature.
const supportDecision = {
  category: 'refund',
  confidence: 0.96,
};

if (supportDecision.category === 'refund' && supportDecision.confidence > 0.9) {
  routeToRefundTeam();
} else {
  sendToHumanReview();
}

The AI classifies the request. It does not issue the refund or choose the 0.9 cutoff. Application code decides whether to automate the action or send it to a person. The cutoff is also illustrative and needs testing on the application’s own data.

unstructured input
        ↓
bounded AI decision
        ↓
probabilities and confidence
        ↓
ordinary if/else code

How this differs from a structured-output LLM

Current LLM APIs also support JSON schemas, tool calls and constrained output. OpenAI’s Structured Outputs guide says supported models can follow schemas containing basic types and nested objects.

Older prompt-only integrations could produce malformed JSON, such as an invalid trailing comma. Current structured-output features greatly reduce that problem. The output may still be wrong in meaning, and a model may refuse the request.

Jev’s output range is narrower. Its public API offers three decision types: Choice, Score and Noul. For these decisions, it also returns probabilities for the available options.

Scroll horizontally to view every column on a small screen.

Jev and a modern structured-output LLM cover different ranges of work
Question	Jev	Structured-output LLM
Output range	Choice, Score or Noul	A supported JSON Schema
Free strings and nested objects	Cannot generate them directly	Supported
Probabilities for alternative answers	Returned for bounded Choice and Score decisions	Usually not part of schema conformance itself
Generate an explanation or reply	No	Yes
Can be correct in shape but wrong in meaning	Yes	Yes

A structured-output LLM covers more ground when the application needs a flexible response, complicated reasoning, conversation or information whose possible values cannot be listed in advance. Jev may be more direct when the valid answers are known and their probabilities change what the application does next.

The three answers Jev can return

TypeSafe’s public HTTP API receives the content to evaluate as state, along with a model name and questions. state can be a string, object or array. The documented model name is jev-latest.

Each question uses one of three formats:

Choice selects one label from a list supplied by the developer. It returns the selected label, a probability for every label and confidence. The Choice documentation allows up to 255 labels.
Score evaluates the input against ordered levels described by the developer. The Score documentation says it returns a probability for each level, a probability-weighted score, descriptions of the levels and confidence. The weighted result can be fractional even when the levels use integers.
Noul answers a yes-or-no question with a number from 0 to 1. That number is the probability of “yes”. According to the Noul documentation, it does not have a separate confidence field.

Jev does not offer a general “fill any JSON Schema” output. It cannot directly generate a free string, an arbitrary nested object or an unrestricted number.

TypeSafe’s date extraction example follows the same boundary. Jev chooses date parts, then ordinary code checks the result.

High confidence can still be wrong

A Choice result contains a probability for every option. If the options are refund, explain_charge and other, the response includes three probabilities. Together, those values form a probability distribution.

Choice and Score also return confidence. TypeSafe’s confidence guide describes it as a summary of how clearly the probabilities concentrate on one option.

The fields answer different questions:

Confidence is not the same value as the highest option probability.
Confidence is not the probability that the answer is correct.

A high-confidence answer can still be wrong. The 0.96 above and 0.98 below are invented confidence values, not measurements.

Whether predicted probabilities match real outcomes is assessed across groups. If predictions given probability 0.8 are well calibrated, about 80 per cent of that group should be correct. It gives no certainty about one prediction. The scikit-learn calibration guide explains the same group-level distinction.

TypeSafe advises teams to test automation cutoffs on their own data. In the material reviewed for this article, I did not find public evidence showing how well Jev’s probabilities match outcomes in different domains.

TypeSafe says Jev cannot hallucinate. Its benchmark description also says the reported zero per cent hallucination or type-error figure is not empirical. An accepted response stays within the declared type and labels, yet Jev can still select a valid answer that is wrong.

A transaction-classification example

Consider this bank transaction description:

UBER *TRIP HELP.UBER.COM AU

An application could define five categories:

transport | food | accommodation | transfer | unknown

The result and 0.98 below are invented. They are not a live Jev result or an SDK call shape. High confidence does not guarantee a correct category.

// Hypothetical application adapter, not a TypeSafe SDK signature.
const transactionDecision = {
  input: 'UBER *TRIP HELP.UBER.COM AU',
  category: 'transport',
  confidence: 0.98,
};

if (transactionDecision.confidence > 0.9) {
  saveAutomatically(transactionDecision.category);
} else {
  sendToHumanReview();
}

A real financial application would need to consider the cost of a wrong category, review capacity and error rates for different transaction types. The automation cutoff may need to change with the risk of the decision.

What “System One Model” means

TypeSafe calls Jev the first System One Model. Its launch post says Jev outputs all probabilities in parallel instead of generating one token after another. TypeSafe also says it uses a parallel sampler and Reinforcement Learning for Calibrated Decisions, or RLCD. Its machine-learning primer describes Jev as returning decisions and probabilities instead of text.

These are vendor descriptions. In the material reviewed for this article, I did not find a paper, model card, weights, model size, input-length limit or training-data description. There was also not enough information to determine whether the internal network is a Transformer or another design. “Non-autoregressive” alone does not reveal that architecture.

Documented and proposed uses

Documented examples need to be separated from vendor proposals and hypothetical uses. An example in the documentation does not establish production accuracy or throughput.

Scroll horizontally to view every column on a small screen.

Status of ten possible Jev workloads as verified on 16 September 2026
Use case	Status and boundary
Customer-support routing	Documented in TypeSafe’s intent-routing pattern and customer-service evaluation
Transaction classification	Hypothetical. It fits Choice, but the bank example above is not a TypeSafe demo
Fraud-risk categorisation	Vendor-proposed. The use-case map describes fraud indicators and risk scoring. Domain testing is required
Content moderation	Documented in TypeSafe’s Choice consistency example
Lead scoring	Vendor-proposed in the use-case map. This is not validated product performance
Intent classification	Documented in TypeSafe’s intent-routing pattern
Document classification	Documented in TypeSafe’s hierarchical-classification example
LLM output verification	Documented in TypeSafe’s citation-checking and LLM-guardrail examples
Workflow routing	Documented through TypeSafe intent routing and confidence-based branching
High-volume background processing	Vendor-proposed in the use-case map. Production throughput is unverified

The official examples include intent routing, moderation, hierarchical classification, citation checking and LLM guardrails. TypeSafe’s use-case map proposes additional applications.

What to check before adopting it

A team can compare Jev with a smaller structured-output model, a conventional classifier, embeddings or explicit rules. Scikit-learn’s text-classification example shows a conventional approach. Embeddings can support similarity search and vector-based classification. The comparison should include model calls, retries, human review, data preparation and operating cost.

TypeSafe’s evaluation site claims low cost and latency. TypeSafe wrote the cases, and the reference probabilities were model-generated. The launch post also acknowledges possible bias from case design and routing. In the official and open-source material reviewed, I did not find an independently reproduced benchmark.

As of 16 September 2026, Jev is an early-access service that requires an API key. The product and API documentation reviewed did not establish numeric rate limits, a service-level agreement, data-retention terms, deployment options, a maximum state size or an input-length limit.

Jev may fit when the valid answers are known before the request and their probabilities change the next action. It does not fit summarisation, conversation, code generation or extraction where the possible answers cannot be listed. Longer reasoning tasks must be split into smaller questions and joined again in application code, which adds development work.

Before adoption, compare Jev, a structured-output LLM, a smaller model, a conventional classifier, embeddings and rules on the same labelled cases. Measure the error rate, human-review load and cost, then prepare a fallback for failures.

멜버른 단추·의류 부자재 샵, Fitzroy Jimmy Buttons

Charlie — Tue, 08 Sep 2026 00:00:00 GMT

남들과 같은 옷에 변화를 주고 싶거나, 현재 입고 있는 옷의 단추가 떨어졌거나, 의류 리폼을 하기 위해 부자재를 찾고 있다면, Jimmy Buttons & Haberdashery 요기를 들러보세요.

진열통 끝에 붙은 단추를 보며 모양을 비교할 수 있어요!

단추 샵 in Fitzroy

매장 주소: 375 George Street, Fitzroy VIC 3065 Jimmy Buttons 공식 홈페이지에서 주소와 매장 안내를 자세히 볼 수 있습니다!

가게로 가는 길

입구는 파란 벽에 흰 문이 있는 모습이에요. 다른 가게들에 비해 안쪽으로 깊게 들어가 있어서 눈에 안 띌지도 몰라요!

문에 ENTRANCE라고 적혀 있고, 위에 OPEN이라고 쓰여 있어요! 가게 문이 닫혀 있거나 열리지 않은 것 같아도 열려 있답니다!!

단추로 꾸며진 문

길을 찾을 때는 지도에서 Jimmy Buttons 위치 보기를 이용하세요. 출발 위치와 시간에 따라 대중교통 경로가 달라지니, 방문할 때의 길찾기 결과를 확인하는 게 좋습니다 :)

모양을 하나씩 비교하게 되는 단추 진열대

단추는 길쭉한 진열통 끝에 샘플을 붙여 놨어요! 통 끝에 붙은 단추는 저마다 모양이 달라요. 표면에 무늬가 있는 것부터 반짝이는 금색·은색 단추까지, 단추가 정~~~말 많아요.

그리고, 색상별로 단추가 모여 있으니 옷에 달 단추를 찾는다면 기존 단추나 옷 사진을 가져가서 비교해 보세요. 색뿐 아니라 크기와 옷에 다는 방식도 함께 보면 고를 때 도움이 됩니다!

지퍼와 버클, 레이스도 가득해요

단추 외에 의류 부자재도 다양하답니다!

방문 전에 확인할 것

특정 부자재가 목적이라면 크기와 색, 필요한 수량을 정리해서 매장에 먼저 물어보면 친절히 도와주십니다! 사진에 보이는 제품이 방문일에도 있는지는 장담드릴 수 없습니다 😅

공식 홈페이지 영업시간

월요일부터 금요일 / 오전 9시~오후 4시
토요일 / 오전 10시~오후 3시

영업시간과 휴무일은 방문 전에 공식 홈페이지에서 다시 확인해 보시는 걸 추천드려요!

TypeScript 7 Is “10x Faster.”

Charlie — Mon, 31 Aug 2026 00:00:00 GMT

Project: https://github.com/yesimnoh/ts7-benchmark
Live dashboard: https://yesimnoh.github.io/ts7-benchmark/

TypeScript 7 is here.

And the number everyone remembers is 10x faster.

That is a big claim.

So, naturally, I wanted to make a small project and bother it with numbers. I built a benchmark that runs TypeScript 6 and TypeScript 7 against the same code, records the time and memory, and publishes the results to a live dashboard.

First, what changed in TypeScript 7?

TypeScript 6 and earlier ran on a compiler written in TypeScript and executed through JavaScript.

TypeScript 7 moves the compiler and language service to a native implementation written in Go.

This gives the compiler two important advantages:

native execution
shared-memory parallelism.

The official TypeScript 7 announcement reports major full-build improvements across large projects, with examples ranging from about 7.7x to 11.9x faster.

But “build performance” contains more than one thing.

There is parsing. There is type-checking. There is emitting output. There may also be multiple projects in a dependency graph.

My benchmark measures only one part:

tsc --noEmit

No JavaScript output. No bundling. No incremental build. No editor startup. Just type-checking.

That boundary matters.

The benchmark setup

I wanted the project to answer more than “Which command finished first?”

So I gave it four fixtures:

Small synthetic: about 500 lines;
Medium synthetic: about 15,000 lines;
Large synthetic: about 120,000 lines;
Real-world: the open-source validation library Zod, pinned to a specific commit.

The synthetic fixtures generate valid interfaces and generic functions at controlled sizes. They make the workload repeatable.

But synthetic code is still synthetic code. Real applications contain deeper generics, stranger inference paths, and decisions someone made at 4:57 p.m. on a Friday.

That is why I included Zod as well.

For each fixture, the benchmark runs:

TypeScript 6 once as the baseline;
TypeScript 7 with --checkers 1;
TypeScript 7 with --checkers 4;
TypeScript 7 with --checkers 8.

Each timing uses two warmup runs followed by hyperfine’s timed runs. Peak memory comes from GNU time -v.

The current results were produced with:

TypeScript 6.0.3;
TypeScript 7.0.2;
a GitHub Actions Ubuntu runner;
4 CPU cores;
about 16 GB of memory.

The machine is part of the result, not a footnote.

TypeScript 7 was 3–4x faster

Using TypeScript 7 with four checkers, the current mean results look like this:

Scroll horizontally to view every column on a small screen.

Mean no-emit type-checking time reported in the benchmark
Fixture	TypeScript 6	TypeScript 7	Speed-up
Small synthetic (~500 lines)	1.10 s	0.33 s	3.3x
Medium synthetic (~15,000 lines)	1.25 s	0.38 s	3.3x
Large synthetic (~120,000 lines)	2.27 s	0.64 s	3.5x
Zod pinned commit	8.05 s	1.98 s	4.1x

The synthetic fixtures stayed in a fairly narrow range.

Zod benefited more.

That makes sense. Zod relies heavily on complex generic types, so the type checker has more meaningful work to distribute. The important result is not that every codebase becomes exactly four times faster.

It is that the gain changes with the shape of the code.

Benchmarks enjoy context almost as much as developers do.

Then why does Microsoft report around 10x?

Because we measured different things.

The official figures cover full builds on large real-world repositories. My test isolates type-checking with --noEmit, uses one real-world fixture, and runs on a four-core CI machine.

So these two statements can both be true:

TypeScript 7 can make full builds around 10x faster on some large projects.
Type-checking alone was around 3–4x faster in my benchmark.

A benchmark number without its workload is just a confident-looking decimal.

The more useful question is not:

Is TypeScript 7 really 10x faster?

It is:

Faster at what, on which project, and on what machine?

`--checkers`: where the result became interesting

TypeScript 7 introduces the --checkers option.

It controls how many checker workers can process the program in parallel. The default is four.

Before TypeScript 7, type-checking was effectively one worker doing the job alone.

Now several workers can share it.

At least, until the hardware runs out of chairs.

The Zod results show this clearly:

Scroll horizontally to view every column on a small screen.

Zod result by TypeScript 7 checker count
Configuration	Mean time
TypeScript 7 — 1 checker	2.62 s
TypeScript 7 — 4 checkers	1.98 s
TypeScript 7 — 8 checkers	2.24 s

Moving from one checker to four helped.

Moving from four to eight did not.

The runner only has four CPU cores. Eight checker workers cannot all execute useful work at the same time, so the extra parallelism adds coordination and memory overhead instead of speed.

More workers do not automatically mean more performance.

Parallelism still has to negotiate with the machine underneath it.

On a runner with eight or more cores, the ceiling may move. That is a future benchmark I would like to add.

Speed has a memory bill

The checker count also changes memory usage.

For Zod, TypeScript 7 used approximately:

734 MB with one checker;
1,002 MB with four checkers;
1,222 MB with eight checkers.

TypeScript 6 used about 1,206 MB in the same fixture.

So one checker used much less memory, while eight checkers slightly exceeded the TypeScript 6 baseline without improving the execution time.

This is the trade-off. More checkers can reduce waiting time when enough cores are available. They also need more memory.

For a developer laptop, four may be a reasonable default.

For a memory-constrained CI runner, one may be the better deal.

The fastest setting is not always the cheapest setting.

Making the benchmark reproducible

I did not want this to become one screenshot from one successful run.

The repository pins both compiler versions and the exact Zod commit. It stores the raw timing and memory results, then merges them into a single summary.json file.

A scheduled GitHub Actions workflow runs the benchmark every week. It:

records the runner specification;
installs both compilers;
regenerates the synthetic fixtures;
runs every fixture and checker combination;
commits the new results;
deploys the dashboard to GitHub Pages.

The numbers can change.

The method should not quietly change with them.

What this benchmark does not prove

There are still clear limitations.

GitHub Actions runners are shared virtual machines, so absolute timings contain noise. The ratios and trends are more useful than one millisecond value.

The synthetic fixtures stress code volume, but they cannot reproduce the type patterns of every application.

There is only one real-world project in the current suite. And again, this benchmark measures type-checking only. It says nothing directly about emit time, incremental builds, bundling, or editor responsiveness.

That is not a reason to ignore the result.

It is a reason to label it correctly.

So, is TypeScript 7 faster?

Yes.

Clearly.

In this benchmark, TypeScript 7 reduced type-checking time by roughly three to four times. On the real-world Zod fixture, four checkers produced the best result on a four-core runner.

The famous 10x number was not wrong.

It was answering a broader question.

My benchmark asked a smaller one:

If I isolate type-checking, how much faster is TypeScript 7 here?

The answer was 3–4x.

Not as loud as 10x.

Still fast enough to change the developer experience. And now there is a dashboard that can keep checking.

Official TypeScript 7 announcement: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

Hello Charlie

3 Frontend RBAC Quiz: Would Your Permission Check Pass?

Q1. What if permission gets revoked mid-action?

Q2. What do you trust when the network drops?

Q3. What about “I can only edit my own posts”?

So, one rule to rule them all

5 Minutes into Frontend RBAC

Approach 1. Static Route Mapping (Config-Driven)

Approach 2. Server-Driven Navigation (Backend-Driven UI)

Approach 3. Granular Permissions

Before You Go: A Few Things Worth Thinking About

[In Melbourne] Free Coffee Cupping: Five Senses ‘Get It India’

Event details

What the session covers

If cupping is new to you

[In Gold Coast] Whale watching with Sea World Cruises

Finding the boat

Whales above the waves

A little seasickness, and a jacket helps

Before you book

We Already Have LLMs. Why Does Jev Exist?

Route a refund request

How this differs from a structured-output LLM

The three answers Jev can return

High confidence can still be wrong

A transaction-classification example

What “System One Model” means

Documented and proposed uses

What to check before adopting it

멜버른 단추·의류 부자재 샵, Fitzroy Jimmy Buttons

단추 샵 in Fitzroy

모양을 하나씩 비교하게 되는 단추 진열대

지퍼와 버클, 레이스도 가득해요

방문 전에 확인할 것

TypeScript 7 Is “10x Faster.”

First, what changed in TypeScript 7?

The benchmark setup

TypeScript 7 was 3–4x faster

Then why does Microsoft report around 10x?

--checkers: where the result became interesting

Speed has a memory bill

Making the benchmark reproducible

What this benchmark does not prove

So, is TypeScript 7 faster?

`--checkers`: where the result became interesting