DEV Community: Jatniel Guzmán

TypeScript 7.0 Is Here: The Compiler Is Much Faster

Jatniel Guzmán — Sun, 12 Jul 2026 06:00:44 +0000

TypeScript 7.0 is now officially available as a stable release, and this is one worth paying attention to.

Not because it introduces a flashy new syntax feature or another configuration option, but because it improves something developers feel every day: waiting.

The TypeScript compiler has been rewritten in Go. The goal is clear: take advantage of native code, multithreading, and better parallelization to make builds, type checking, and the editor experience much faster.

Microsoft says TypeScript 7 is usually between 8x and 12x faster on large projects. In some cases, with more parallelization, the results go even higher.

The Numbers Are Pretty Clear

Microsoft published benchmarks on several well-known open-source projects using TypeScript 7’s default configuration:

Project	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

The VS Code result is especially impressive: a build that took more than two minutes now takes just over ten seconds.

And when increasing the number of workers with --checkers 8, VS Code goes down to 7.51 seconds, which is 16.7x faster than TypeScript 6.

Another interesting point is that this speedup does not seem to come with higher memory usage. In the projects Microsoft measured, memory usage actually went down, between 6% and 26% depending on the project.

The Biggest Difference May Be in the Editor

For me, the most important part is not just faster builds.

The real improvement is the feedback loop while coding.

TypeScript 7 also comes with a new language server based on LSP. In practice, the things we use all day should feel faster: autocomplete, real-time errors, type hovers, code navigation, find references, and more.

Microsoft gives a good example: in the VS Code repository, opening a file with an error used to take about 17.5 seconds before showing the first diagnostic. With TypeScript 7, it takes less than 1.3 seconds.

On a small project, that is nice.

On a large codebase or a monorepo, that can really change the way you work.

What Teams Are Seeing on Real Projects

TypeScript 7 is not only coming with internal benchmarks. Microsoft says this version has been tested for more than a year on large codebases, both inside and outside Microsoft.

Some of the companies mentioned include Slack, Canva, Figma, Vercel, Notion, Sentry, and Bloomberg, as well as Microsoft teams working on Teams, Office, PowerBI, and Xbox.

A few numbers stand out:

Slack reportedly reduced type checking in CI from 7.5 minutes to 1.25 minutes.
Canva went from 58 seconds to 4.8 seconds before seeing the first error in the editor.
One Microsoft team reported saving around 400 hours of CI time per month.
The new language server reduced failing commands by more than 80% and crashes by more than 60% compared to TypeScript 6.

These numbers matter most when you work on large projects. When type checking gets too slow, teams often push it to CI or run it less often. If TypeScript 7 makes it practical again during local development, that is a real productivity win.

Installation

To install TypeScript 7:

bash id="g4p2wc" npm install -D typescript

Then run:

bash id="fkg78d" npx tsc

By default, TypeScript 7 uses 4 workers for type checking. You can adjust this with --checkers:

bash id="kz618u" npx tsc --checkers 8

Of course, this should be tested depending on your machine and your project. More workers can make builds faster, but they can also increase memory usage. On a powerful development machine, it is worth trying. On a limited CI runner, it is better to measure before changing anything globally.

The Main Thing to Watch

Not every part of the ecosystem can move to TypeScript 7 immediately.

TypeScript 7.0 does not yet expose a stable programmatic API. That API is expected in TypeScript 7.1.

This affects tools and frameworks that depend directly on TypeScript, such as Vue, Astro, Svelte, MDX, some Angular workflows, Volar, and typescript-eslint.

For those cases, Microsoft recommends running TypeScript 6 and TypeScript 7 side by side for now.

For example:

json id="nmbg7p" { "devDependencies": { "@typescript/native": "npm:typescript@^7.0.2", "typescript": "npm:@typescript/typescript6@^6.0.2" } }

The idea is simple: keep TypeScript 6 for tools that still need its API, and use TypeScript 7 where possible to benefit from the performance improvements.

My Take as a Developer

I find this release really interesting because it does not try to get attention with visible new features. Instead, it solves a very real problem: waiting.

Waiting for type checking to finish, waiting for the editor to show errors, waiting for CI to confirm something we would rather know locally… these small delays add up quickly on large projects.

TypeScript 7 does not change the way we write TypeScript overnight. But it can change how fast we work with TypeScript.

And for a tool that is so widely used in modern development, that is a big deal.

Congratulations to the TypeScript team for this work. Rewriting such a central compiler in Go is impressive, and I would not be surprised if it inspires other languages and development tools.

Source: Microsoft’s official announcement, “Announcing TypeScript 7.0”.

Originally published on jatniel.dev.

TypeScript 7 RC: the compiler rewritten in Go, around 10x faster

Jatniel Guzmán — Sun, 21 Jun 2026 11:39:50 +0000

Microsoft just shipped the Release Candidate for TypeScript 7, with the stable release expected next month. And the big deal, for once, isn't a new syntax or yet another config flag. It's that the entire compiler has been rewritten in Go.

Over the past year, the team ported the existing codebase (until now, TypeScript that compiled to JavaScript) to Go. It was done methodically from the current implementation, not rewritten from scratch, so the type-checking logic stays structurally identical to TypeScript 6. You don't change how you write TypeScript, you just get more speed.

Why it's so fast

The speedup isn't magic, it comes from the language. Go compiles to native code and takes advantage of parallelism through shared memory. The result Microsoft reports: builds that are often around 10 times faster than TypeScript 6. That number comes from their own measurements and from companies like Figma, Bloomberg, Vercel, Notion, and Slack, which have been testing pre-release builds for over a year and report similar gains.

And it doesn't stop at the tsc command line. The Language Server Protocol (LSP), the thing that powers autocomplete, type hovers, and real-time errors in your editor, runs on the same foundation. So the editor responds much faster, and that's probably what you'll feel most day to day on a large project.

The repo is open source (Apache 2.0, more than 25,000 stars on GitHub) and about 85% Go. For a project this size, and coming from Microsoft, betting on Go was not the obvious choice.

TypeScript 6, the step you shouldn't skip

TypeScript 7 inherits TypeScript 6's defaults, and anything deprecated in 6 now turns into a hard error. Since 6 is still recent, plenty of projects will need to adapt.

That's exactly what 6 is for: it doesn't bring big new features, it sets the stage. It warns you about the options and syntax that go away in 7. The team's advice, and mine: move to 6 first, clear those warnings, and the jump to 7 happens without surprises.

A few examples of what becomes a hard error in 7: target: es5, moduleResolution: node, baseUrl, or module: amd/umd/systemjs. On the defaults side, strict is now true and module is esnext. Two changes catch people off guard and are worth a look: rootDir now defaults to ./ (you'll often need to point it back to ./src), and types defaults to [], so you have to list your @types packages explicitly.

Running 6 and 7 side by side

Not all of your tools will be compatible with 7 overnight. typescript-eslint, for example, imports the typescript package directly, and the stable programmatic API won't land until TypeScript 7.1, a few months from now.

Microsoft set this up so the two versions can live together without stepping on each other. A compatibility package, @typescript/typescript6, ships a tsc6 binary and re-exports the 6 API. The trick is to use npm aliases in your package.json:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc"
  }
}

The typescript package your linter looks for actually points to 6, which is stable and what the tools expect, while npx tsc uses 7 for the rest of the project. It's a textbook parallel change: 6 keeps things tidy on linting, and 7 makes everything else faster. Tooling compatibility should settle down around 7.1.

Parallelization, checkers, and watch mode

TypeScript 7 parallelizes several steps: parsing, type-checking, and emit. Parsing and emit split easily across files. Type-checking is trickier because of dependencies between files, so the team spins up a fixed number of workers that share the work deterministically: same input files, same output results.

By default you get 4 workers, adjustable with --checkers. If you have more cores you can raise it, at the cost of more memory. On a tight CI runner, lower it instead.

There's also --builders, to build several projects in a monorepo at once. Watch out, the effect multiplies with --checkers: with --checkers 4 --builders 4 you can have up to 16 type-checkers running. And --singleThreaded forces a single thread, handy for debugging or for comparing 6 with 7.

Watch mode was rebuilt on top of Parcel's file watcher, also ported to Go. No more expensive polling over big node_modules folders, and file watching is much lighter.

Commands to try it

Install the RC:

npm install -D typescript@rc

Check the version:

npx tsc --version
# Version 7.0.1-rc

Compile like always, just faster:

npx tsc

Tune the number of type-checking workers:

npx tsc --checkers 8

Force a single thread to compare with 6:

npx tsc --singleThreaded

Install 6 and 7 at the same time with aliases:

npm install -D typescript@npm:@typescript/typescript6
npm install -D typescript-7@npm:typescript@rc

And to live on the nightlies:

npm install -D @typescript/native-preview
npx tsgo --version

The nightly binary is still called tsgo. Once 7 ships stable, everything moves back to the typescript package.

In short

TypeScript 7 doesn't touch your code or the typing rules, it goes after speed, both in the build and in the editor. The sensible plan: move to TypeScript 6 now to clear the warnings, test the RC in parallel on a real project, and report bugs on the microsoft/typescript-go repo. Stable lands next month.

Official announcement: Announcing TypeScript 7.0 RC.

Originally published on jatniel.dev.

Cursor Launches Origin, a GitHub Rival, Right Before SpaceX Buys the Company

Jatniel Guzmán — Wed, 17 Jun 2026 15:19:16 +0000

Cursor just announced Origin, a code storage and Git hosting platform. In one line: a direct competitor to GitHub. It ships this fall, and for now there's only a waitlist. So far, nothing wild in a market where everyone wants a piece. What makes it interesting isn't the what. It's the when.

From editor to platform

Some context first. Cursor, made by Anysphere, started as a fork of VS Code with AI built in. In a few years it went from a toy to the editor a lot of us open every morning.

In December 2025, Cursor bought Graphite, a startup focused on code review: stacked pull requests, merge queues, structured reviews. With Origin, the last piece falls into place, which is hosting. Cursor doesn't just want to be the place where you write code. It wants to be the place where it's stored, reviewed, and merged.

They're blunt about the pitch. GitHub was built for humans: one developer, a few commits a day, a pull request, a coworker who reviews it. Origin starts from a different assumption. Soon, Cursor says, it won't be one person pushing code. It'll be dozens of agents at once, cloning, branching, merging, and fixing their own mistakes in parallel. Origin is built to handle that load, and it throws in AI-powered automatic merge conflict resolution on top.

The numbers they showed on stage make the point: about 22 commits per second in a single repo, close to 300,000 clones and tens of thousands of pushes an hour. Numbers that make no sense at human scale, and all the sense in the world if you point an army of agents at the same repo.

You could call the bet early. Most of us don't have fifty agents running around the same project. But the idea isn't crazy, and it explains why Cursor dropped so much money on Graphite six months ago.

The detail that changes everything

Here's where it gets interesting. Just a few days before Origin, SpaceX signed a deal to buy Cursor for $60 billion, all in stock. Cursor becomes a wholly owned part of SpaceX once the deal closes, which is expected this fall. And it's worth remembering that SpaceX absorbed xAI, Musk's AI company, earlier this year.

So by the time Origin ships, it'll belong to the same group as xAI. A group that already trains its own models: Cursor and xAI have confirmed they're working together on one that's coming soon, described as trained from scratch on more than a hundred thousand GPUs.

The question all this raises

Line up the pieces. You write your code in Cursor. You host it on Origin. And the whole thing belongs to a company that trains top-tier AI models.

I'm not saying it's a trap, and I'm not assuming anyone has bad intentions. But the question is worth asking plainly: where does my code live, and who gets to use it? We already ask it about GitHub and Copilot, and the answers aren't always reassuring. The difference with Origin is that the whole chain ends up under one roof: the tool that writes, the place that stores, and the model that learns.

When one company controls all three links, the line between "hosting your code" and "learning from your code" comes down to the terms of service. And terms of service get rewritten.

What this means for a freelancer

On the practical side, I mostly work on client projects: Symfony, Laravel, PrestaShop, APIs. Not all the repos are mine, and several clients have strict rules about where the code can live. Switching platforms isn't a technical tweak you knock out on a Friday afternoon. It's a decision that touches confidentiality, compliance, and sometimes the contract itself.

For now I'm staying on GitHub. Not out of loyalty: GitHub has its own problems, and its recent outages made that clear. But trading a dependency on Microsoft for one on SpaceX isn't a win. It's just another giant, with its own priorities.

What I'd do in your shoes

Origin is worth a look, especially if you're starting to run agents in production and GitHub is choking at scale. I'll probably join the waitlist, if only to see how it actually works. There's still a lot we don't know: pricing, importing and exporting repos, how it plays with GitHub and GitLab, what it offers companies. What's up right now is a landing page, not documentation.

But before I move a single serious repo, I want to read those terms, know what happens to the data, and wait for the deal to actually close. You don't get control of your code back after the fact. You protect it before you click "migrate."

Originally published on my blog. Read more of my writing on PHP, freelancing, and dev tooling at jatniel.dev.

Claude Fable 5 and Mythos 5 are here.

Jatniel Guzmán — Tue, 09 Jun 2026 19:55:09 +0000

Claude Fable 5 and Mythos 5 are here.

Same model, two names. What sets them apart isn’t capability, but guardrails.

Fable 5 is available to everyone. Mythos 5 remains restricted to Project Glasswing partners, with some safeguards removed in specific domains.

The detail that matters for developers: this isn’t a model that burns through tokens. Quite the opposite.

On a spreadsheet benchmark suite, it outperforms Opus 4.8 at every effort level, using fewer turns and completing tasks 25–30% faster.

It’s included at no extra cost for Pro, Max, Team, and Enterprise users until June 22. After that, it switches to usage-based pricing.

They’re giving you the most powerful model they’ve ever released… for two weeks. Enjoy it while it lasts—on June 23, the free ride is over.

Definitely worth testing properly before forming an opinion. 🧐

Original post : Claude Fable 5 and Claude Mythos 5

Jatniel
Senior freelance PHP developer. Symfony, Laravel, PrestaShop.
Web applications, REST APIs, and e-commerce.
jatniel.dev

Six months of AI in 2026, and a whole lot of noise

Jatniel Guzmán — Sun, 07 Jun 2026 20:51:35 +0000

This week, two major players also hit the brakes and changed their tune.

Six months of AI in 2026, and honestly, things went off in every direction. Almost every week, a new model promising to "change everything": GPT-5.4 and 5.5, Claude Opus 4.6 through 4.8, Gemini 3.5 Flash, Kimi, DeepSeek V4, MiniMax M3, Gemma 4.

But under the marketing, the real shift is somewhere else: we moved from the chatbot that answers to the agent that actually does things. And it comes with a bill. GitHub Copilot just switched to usage-based pricing, and part of the community is freaking out over the prices.

The part that stuck with me, though, is the turn this week. Anthropic is now calling for an industry-wide pause, and Sam Altman, who warned a year ago that AI would wipe out junior jobs, now admits he was "pretty wrong."
The idea taking hold isn't "AI is going to take your job." It's more uncomfortable: AI is going to change which parts of your job actually have value.

I broke down the full six months, the dates, the sources, and what it actually means for us as devs, in the full article.

Read the whole thing here: https://jatniel.dev/en/bytes/six-months-of-ai-in-2026-and-a-whole-lot-of-noise

If it resonates, feel free to share it.

Claude Opus 4.8: what actually changes when you code for real

Jatniel Guzmán — Thu, 28 May 2026 21:33:13 +0000

Anthropic has just released Claude Opus 4.8.

The price stays the same, Claude Code gets a few new features, and the overall message is pretty clear: better coding reliability, stronger support for long-running tasks, and more useful agents for complex workflows.

I would not call it a revolution.

But as a developer, there are a few things here that are definitely worth looking at.

Reliability is becoming the real topic

The part that caught my attention the most is this: according to Anthropic, Opus 4.8 is about 4 times less likely to miss a bug in code it has just written.

There is another point I find even more important: the model seems better at saying when it is unsure, instead of confidently telling you that everything is fine.

When you work with AI-generated code on a regular basis, that matters.

I would much rather have a model say “this needs review” than one that is wrong with perfect confidence.

Effort control

Another interesting addition is effort control.

Next to the model selector, you can now choose how deeply you want Claude to work on a task. By default, Opus 4.8 runs in high mode, but you can push it to extra or max for more complex work.

The idea is practical: not every task needs the same level of reasoning.

For a small fix, you do not need to bring out the heavy machinery.

For a delicate refactor, a technical migration, or an agent working for a long time across a codebase, asking for more depth can make sense.

That said, it is important not to confuse things: this setting does not replace choosing the right model. It changes how Opus approaches a specific task.

React more : Claude Opus 4.8: what actually changes when you code for real

[Boost]

Jatniel Guzmán — Mon, 22 Sep 2025 15:01:53 +0000

Javier Eguiluz

Sep 22 '25

New in EasyAdmin: Custom Admin Routes

#easyadmin #symfony #php

3 min read

[Boost]

Jatniel Guzmán — Mon, 22 Sep 2025 14:54:33 +0000

arasosman

Aug 15 '25

PHP Developer Salary Guide 2025

#php

9 min read