ECMAScript 2026 and Modern JavaScript Development Services
Modern JavaScript development means writing to the current ECMAScript standard and running it directly, rather than authoring an older dialect and transpiling down to it. ECMAScript 2026, the 17th edition of ECMA-262, was published by Ecma International in June 2026. It is a modest edition in its own right; the two changes that reshape how date handling and resource cleanup are written — Temporal and explicit resource management — reached Stage 4 during 2026 and are slated for the 2027 edition, and engines are already shipping them ahead of publication.
Mixcore Studio has been building production software for more than 8 years, with a team of around 20 and over 320 projects delivered. On this page we deal with the language layer itself: the ECMAScript standard, TypeScript, and the toolchain that compiles, checks and bundles it. Framework choices live on the neighbouring Svelte, React, Vue, Angular and Node.js pages.
This page was rewritten in August 2026 because most of what a JavaScript services page said in 2024 is now wrong. Babel-to-ES5 pipelines, webpack as the default bundler, ESLint and Prettier as the only sensible pair, and the JavaScript-implemented TypeScript compiler have all been displaced. We would rather say that plainly than describe a stack that no longer exists.
What actually changed in the language
Two additions carry almost all of the weight, and both replace patterns that every large JavaScript codebase currently works around. Both reached Stage 4 in 2026 and are slated for ECMAScript 2027 rather than the 2026 edition, so engine and browser support — not the edition number — is what actually gates adoption.
- Temporal (Stage 4, slated for ES2027) — an immutable date and time API with built-in time zone and calendar support. It supersedes the
Dateobject, which has been the language's most reliably error-producing built-in since 1995. For anything scheduling-heavy, billing-related or cross-timezone, this is the single highest-value change in the standard. - Explicit resource management (Stage 4, slated for ES2027) —
usingandawait usingbind a resource to a scope and dispose of it deterministically when that scope exits. File handles, database connections, locks and subscriptions stop depending on a correctly writtenfinallyblock. - What ECMAScript 2026 itself adds —
Iterator.concatandArray.fromAsyncremove a common class of hand-rolled helper,Math.sumPrecisegives an accurate floating-point sum where naive addition drifts, andError.isErrorandMap.prototype.getOrInsertreplace two more familiar hand-rolled utilities. Useful, but none of it is a migration project. - Import attributes — standardised in ECMAScript 2025,
with { type: 'json' }is the standard form. The older import assertions syntax usingassertis superseded and should be migrated.
An honest caveat on Temporal: adopting it before it is available across your supported browsers means shipping a polyfill, and the Temporal polyfill is not small. If an application formats three dates and never touches a time zone, adding it is a net loss. We check the actual browser support matrix and the actual date logic in the codebase before recommending the migration, and in a fair number of cases we recommend waiting.
TypeScript is the default dialect, and it no longer needs a build step to run
GitHub's Octoverse 2025 report recorded TypeScript becoming the most-used language on GitHub for the first time, ahead of both Python at 2.6 million contributors and JavaScript at 2.15 million. In practice, new work is TypeScript unless there is a reason for it not to be.
What changed in 2026 is that the runtime now reads it. Node.js has stripped types by default since v23.6.0 and marked the feature stable in v25.2.0; Deno and Bun do the same natively. A .ts file runs directly, with no bundler and no compile step. This is genuinely useful for scripts, tooling and small services, and it comes with sharp edges we set expectations about up front:
- No type checking happens at runtime — stripping is not compiling. Node ignores
tsconfig.jsonentirely. You still need a type-check gate in CI, and removing it because the code runs is the mistake we see most. - Only erasable syntax works — enums, runtime namespaces, parameter properties, import aliases and decorators all error out.
.tsxis unsupported. - Import discipline is mandatory — the
typekeyword is required on type-only imports and file extensions are required in specifiers. We seterasableSyntaxOnly,verbatimModuleSyntaxandrewriteRelativeImportExtensionsso the compiler catches violations before the runtime does.
On Node versions: v24 'Krypton' is the Active LTS line and the sensible default for new production work, v26 is Current and enters LTS on 28 October 2026, and v22 'Jod' is Maintenance LTS with end of life on 30 April 2027. Anything still on Node 20 or earlier is now blocking framework upgrades as well as language features.
The toolchain is native now, and slow builds are a choice
The build layer was rewritten in Rust and Go, and the performance difference is large enough that "our build is slow" has stopped being an acceptable answer to a client.
- Vite 8 (12 March 2026) replaced the old esbuild-for-dev and Rollup-for-build split with Rolldown, a single Rust bundler, with Oxc as the compiler. The Vite team's release announcement reports up to 10 to 30 times faster builds, with case studies including Linear going from 46 seconds to 6 seconds and Ramp reporting a 57% reduction.
- TypeScript 7.0 (8 July 2026) is a native Go port of the compiler. The Microsoft TypeScript team reports typical full-build speedups of 8 to 12 times, and a full type check of the VS Code codebase falling from 125.7 seconds to 10.6 seconds.
- oxlint and Biome are displacing the ESLint and Prettier pair. oxlint ships more than 845 native Rust rules, and its JS plugins feature — still alpha — is aimed at running existing ESLint plugins. Next.js 16 removed the
next lintcommand outright. - Rolldown 1.0 shipped stable on 7 May 2026. Projects still on Vite 7 can adopt the
rolldown-vitedrop-in package as a staged migration before moving to Vite 8 proper.
The trade-offs are real and worth stating. Vite 8 requires Node 20.19 or 22.12 and above, and its install footprint is roughly 15 MB larger than Vite 7. TypeScript 7.0 ships without a stable programmatic API, which is targeted for 7.1, so typescript-eslint, ts-jest and the Vue, Svelte and Astro template type-checkers cannot run on it yet. The workable arrangement today is running tsgo for fast whole-project checks while keeping the 6.x line available for the tools that still need the JavaScript API. We do not recommend a single-compiler cutover until that gap closes.
Migrating legacy JavaScript without a rewrite
Most of the JavaScript work that reaches us is not greenfield. It is a codebase that works, earns money, and has accumulated a decade of patterns that are now the slow path.
- Assessment first — we inventory the dialect, module system, bundler, browser support matrix and test coverage, then produce a migration order based on where the actual cost sits, not on language purity.
- Bundler and linter migration — webpack to Vite 8 with Rolldown, or Babel pipelines retired where Baseline browser support makes the transpilation unnecessary.
- Incremental typing — JSDoc-annotated JavaScript with
checkJsis a legitimate destination for a codebase that cannot absorb a full TypeScript conversion, and it gets most of the editor and CI benefit. - Targeted language migration —
Dateto Temporal in the modules where time zones actually cause defects, callback and manual cleanup patterns tousingwhere resource leaks are real.
Rewriting a working codebase purely to modernise its syntax is not a project with a return, and we will say so. The version of this that pays is migrating at the boundary of work you were already funding: when a module is being changed anyway, it gets brought forward. That keeps the migration inside features rather than turning it into a separate line item nobody wants to sponsor.
Where modern JavaScript is the wrong answer
A few situations where we would advise against the obvious path:
- A content site does not need a single-page application. Client-only rendering is now the exception that has to be argued for. For marketing, content and commerce, server-rendered output with islands is the mainstream answer, and it is usually the cheaper one to keep fast.
- Some interactivity does not need a build step at all. A page with a few interactive elements can be served by hand-written modern JavaScript and a couple of custom elements. Declarative Shadow DOM has been Baseline since February 2024. That codebase will still run in five years without a dependency audit.
- Native TypeScript execution is not a replacement for compiling when you need decorators, enums or JSX. Those are exactly the features stripping refuses.
- Chasing the newest standard on a stable product costs more than it returns. If the language features do not remove a class of defect you actually have, the correct decision is to stay where you are and revisit at the next framework upgrade.
How we verify the work
Language and tooling choices only matter if they show up in measured output, so we hold the same three gates on every engagement.
- Core Web Vitals against field data — Google's thresholds are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, assessed at the 75th percentile of real-user data over a rolling 28-day window. INP is the one that punishes JavaScript-heavy interaction. Note that Chrome 151 shipped soft navigations unflagged in July 2026, so JavaScript-driven route changes in single-page applications are now measured where they previously were not; sites that looked fine may not stay that way.
- Accessibility with a deadline attached — the European Accessibility Act has applied to newly marketed services since 28 June 2025, and the US DOJ ADA Title II rule requires WCAG 2.1 AA by 26 April 2027 for larger public entities and 26 April 2028 for smaller ones. We test against WCAG 2.2 and hand over conformance evidence rather than a widget.
- Review and test coverage on AI-assisted code — the DORA 2025 State of AI-assisted Software Development report found 90% of respondents using AI at work, with a positive relationship to delivery throughput but a continuing negative relationship to delivery stability. The Stack Overflow 2025 Developer Survey of over 49,000 developers found only 3% highly trust the accuracy of AI output, and 66% name AI solutions that are almost right but not quite as a leading frustration. Our position is that the scarce role is the senior reviewer and the automated verification harness, not the first draft, and we staff accordingly.
Our expertise
- ECMAScript 2026 adoption
- TypeScript-first codebases
- Vite 8 and Rolldown builds
- Legacy JavaScript migration
- Core Web Vitals and INP
- Code review and CI gates
Frequently asked questions
What is ECMAScript 2026 and do I need to upgrade for it?
ECMAScript 2026 is the 17th edition of the ECMA-262 standard, published by Ecma International in June 2026. Its own additions are modest — Iterator.concat, Array.fromAsync, Math.sumPrecise, Error.isError and Map.prototype.getOrInsert among them. The two changes people usually mean by modern JavaScript are Temporal, a replacement for the Date object with proper time zone and calendar handling, and explicit resource management through the using and await using keywords; both reached Stage 4 during 2026 and are slated for the 2027 edition, though engines are already shipping them. You do not need to upgrade anything to keep running; you adopt the parts that remove a defect class you actually have, starting with Temporal if your product deals with time zones, scheduling or billing periods.
Should we replace Date with Temporal right now?
Only where the date logic is genuinely causing problems. Until Temporal is available across your supported browsers you have to ship a polyfill, and it is not a small one. For an application that formats a few dates and never crosses a time zone, that payload is not worth it. For scheduling, recurring billing or anything multi-region, Temporal removes a category of bug that has been expensive for thirty years, and migrating those modules first is the right sequence.
Can we run TypeScript without a build step now?
Yes for execution, no for safety. Node.js has stripped types by default since v23.6.0 and marked it stable in v25.2.0, and Deno and Bun run TypeScript natively, so a .ts file executes directly. But stripping performs no type checking and ignores tsconfig.json entirely, and only erasable syntax works, which rules out enums, decorators, parameter properties and .tsx. You still need tsc or tsgo as a CI gate. Dropping the type-check step because the code runs is the most common mistake we correct.
Is it worth migrating from webpack and ESLint to the Rust-based tooling?
Usually yes, and the case is easier to make than it was. The Vite team reports builds up to 10 to 30 times faster with Rolldown in Vite 8, with published case studies such as Linear moving from 46 seconds to 6 seconds. TypeScript 7.0, the Go port of the compiler, is reported by Microsoft at 8 to 12 times faster on full builds. The main caveat is TypeScript 7.0's missing stable programmatic API, which means typescript-eslint and the Svelte, Vue and Astro template checkers cannot run on it until 7.1, so most teams should run it alongside the 6.x line rather than cutting over completely.
How do you handle AI-generated code in a JavaScript project?
We treat it as a draft that has to pass the same gates as anything else, because the industry data says that is where the risk sits. DORA's 2025 report found 90% of respondents using AI at work, with a positive effect on throughput but a continuing negative effect on delivery stability, and the Stack Overflow 2025 survey found only 3% of developers highly trust the accuracy of AI output while 66% name almost-right AI solutions as a leading frustration. Our controls are review by a named senior engineer, type checking and linting in CI, and tests that assert behaviour rather than restating the implementation.
Do we still need to transpile JavaScript for older browsers?
Far less than most build configurations assume. A large amount of Babel configuration in production today targets browsers the client no longer supports, and it costs build time and shipped bytes for no benefit. We check the real analytics and the real support matrix, then set the compilation target from that. Retiring an unnecessary transpilation step is often the cheapest performance work available in a legacy codebase.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com