JavaScript & TypeScript in 2026: What to Use

If you are starting a product this year, the JavaScript decisions you make in the first two weeks will follow you for years. Your runtime version, your TypeScript settings and your build tool all decide how fast your team can work and how painful your next upgrade will be.

2025 moved several of those defaults. The TypeScript compiler is being rewritten in Go. Node.js 24 became the new long-term support line. Vite started swapping its bundler for one written in Rust, and Next.js made Turbopack its default. This post covers what changed, what is still in preview, and what we would put in a new project's README today.

TypeScript 7 is coming, and it is fast

In March 2025 the TypeScript team announced that it was porting the compiler and language service to Go. The project is called Corsa, and it will ship as TypeScript 7.0. The current JavaScript-based compiler continues as TypeScript 6.0, which the team describes as the last release on the old codebase and a bridge to 7.0.

The team's December 2025 progress update (opens in a new tab) is the best snapshot of where things stand. The headline numbers are full builds that are often around 10x faster than TypeScript 6.0. Their own benchmarks include:

You can try it now. The compiler ships as the @typescript/native-preview npm package, which gives you a tsgo command that runs alongside tsc, and there is a matching VS Code extension that updates daily. The team says the preview is safe to use for type-checking, and that --incremental, project references and --build mode are ported.

There are real gaps, and they matter for planning:

• TypeScript 7 removes behavior that 6.0 deprecates. --strict becomes the default, and baseUrl, the es5 target and node10 module resolution go away.
• JavaScript output only downlevels to ES2021, and decorators are not supported yet.
• --watch can be less efficient in some cases.
• Tools that call the existing compiler API will not work against 7.0 until a new API lands.

What to do: keep tsc as your source of truth for builds in 2026, and add tsgo as a fast type-check step in CI or in your editor. Then fix the things TypeScript 7 will reject while your codebase is small. Turn on strict, drop baseUrl in favor of explicit paths or package imports, and use a modern module and moduleResolution setting such as nodenext or bundler. If you start a project with those settings, the move to 7.0 should be a version bump.

Node.js 24 is the LTS line to start on

Node.js 24 ("Krypton") moved to long-term support on October 28, 2025 with release 24.11.0, and it is supported until the end of April 2028. The other lines worth knowing:

• Node.js 22 is still in LTS, with support until April 2027.
• Node.js 20 reaches end of life on April 30, 2026. After that it gets no security fixes.
• Node.js 25 is the current, odd-numbered release. It will never be an LTS line, so keep it off production.

If you have a service on Node 20, plan the upgrade for this quarter. For a new product, start on 24 and pin it in .nvmrc, your Dockerfile and your CI config so every environment matches.

The other Node.js change that affects daily work is TypeScript support in the runtime. Since Node.js 22.18.0 (opens in a new tab), released in July 2025, type stripping is on by default. You can run a .ts file directly with node script.ts. Node removes the type annotations and runs what is left. It does no type-checking, it ignores tsconfig.json, and it only handles syntax that can be erased. Enums, namespaces with runtime code and constructor parameter properties need a transform, so they are out.

TypeScript 5.8 added a flag for exactly this case. --erasableSyntaxOnly (opens in a new tab) makes the compiler report those constructs as errors, so you learn at build time instead of at runtime. We would turn it on in any new codebase. It keeps your code compatible with Node's type stripping, and the replacements it pushes you toward (union types instead of enums, plain properties instead of parameter properties) are easier to read anyway.

What to do: use native type stripping for scripts, tooling and small services. You can drop ts-node from those places. Keep a real build step for anything that needs path aliases, downleveling or bundling.

ECMAScript 2025 replaces some utility code

Ecma approved ECMAScript 2025, the 16th edition of the language, in June 2025. The introduction to the ECMAScript 2025 specification (opens in a new tab) lists everything it added. The features most product teams will use:

• Iterator helpers. map, filter, take, drop and friends now work on iterators directly, so you can process a Map, a generator or a large lazy sequence without converting it to an array first.
• New Set methods. union, intersection, difference, isSubsetOf and others replace the hand-written helpers most codebases carry.
• Promise.try. It starts a promise chain from a function that might throw synchronously, so one catch handles both kinds of error.
• JSON modules. You can import JSON with import attributes: import config from "./config.json" with { type: "json" }.
• RegExp.escape. It safely escapes user input before you build a regular expression from it.

ES2025 also adds inline modifier flags in regular expressions and Float16Array for 16-bit floats, which matters if you work with graphics or machine learning data in the browser.

What to do: set your TypeScript lib and target to match the runtimes you support, then check before adding a small utility dependency. Set operations and lazy iteration are now in the language.

Build tools moved to Rust

The biggest tooling change of 2025 was the move to native bundlers.

Vite. The Vite team released the Vite 8 beta (opens in a new tab) on December 3, 2025. It replaces the old pairing of esbuild for development and Rollup for production with a single bundler, Rolldown, written in Rust. The team says Rolldown performs at esbuild's level and is 10 to 30 times faster than Rollup, and that most Vite plugins work without changes. Vite 7, released on June 24, 2025, is the current stable version.

Next.js and Turbopack. Next.js 16 (opens in a new tab), released on October 21, 2025, made Turbopack the default bundler for both development and production builds. Vercel's numbers are 2 to 5 times faster production builds and up to 10 times faster Fast Refresh. Apps with custom webpack configuration can still opt out with next build --webpack. Next.js 16 also requires Node.js 20.9 or later and TypeScript 5.1 or later, removes the next lint command, and promotes React Compiler support to stable (off by default).

Before these changes, a product with a web front end and a component library often ran two or three bundlers with different plugin systems. Teams on Vite or Next.js are now converging on one native bundler per framework, and slow local builds are less of a reason to adopt extra tooling.

What to do: if you choose Vite, start on Vite 7 and try the Vite 8 beta on a branch. Moving to 8 when it is stable should be small if you avoid obscure Rollup plugins. If you choose Next.js, start on 16 with Turbopack and treat any webpack-only plugin as a cost you need to justify.

A default stack for a new product in 2026

Here is what we would standardize on for a new TypeScript product today. Every line can be changed for a good reason, but each one should be a decision someone writes down.

A few habits matter more than any single tool:

• Write the versions down. A short "stack decisions" page in the repo stops each new developer from adding a favorite tool.
• Budget an upgrade window. Node 20's end of life in April is a fixed date, and TypeScript 7 is on its way. Put them in the roadmap now so they are planned work.
• Prefer the platform. Native type stripping, ES2025 built-ins and framework-default bundlers mean fewer dependencies to audit and update.

Plan your stack before you write code

Most of the changes from 2025 make life easier for teams that start clean: faster type-checking, a runtime that runs TypeScript, and one bundler per framework. The cost lands on teams that defer upgrades and then have to move Node, TypeScript and their build tool in the same quarter. A new product can avoid that by choosing current defaults on day one and keeping its configuration close to them.

Planning a new product and want a second opinion on the stack? Book a free 30-min call (opens in a new tab) and we will review your technical choices with you.

Related service: Custom Software Development