close

DEV Community

Cover image for 7 New JavaScript Features (And 2 I'm Still Waiting For)
Sylwia Laskowska
Sylwia Laskowska

Posted on

7 New JavaScript Features (And 2 I'm Still Waiting For)

Upcoming ECMAScript 2026 standard updates

Remember how I promised you (or rather myself) two weeks ago that from now on I'd only write light, easy posts? Well… I broke that promise 😅 Last week I published a huge article about one of the least sexy topics imaginable: legacy applications. Somehow, despite that, the DEV editorial team liked it enough to include it in the Top 7 Posts of the Week ❤️

But today is finally the day for something a bit lighter. And I think it's a topic that deserves more attention.

These days we spend a lot of time talking about AI agents, and I absolutely understand why, because it's a fascinating field. But I sometimes feel we're forgetting that the programming languages we use every day are evolving too.

I spend most of my days writing JavaScript (well… TypeScript, obviously 😄). And yes, the ecosystem has matured a lot over the last few years. We no longer have endless React vs Angular wars. We're also mostly past those times when everyone loved Redux one month and six months later decided it was an overengineered monster and removed it from every application 😅.

But both the ecosystem and the ECMAScript standard keep evolving.

After the legendary ES6 release in 2015, which changed frontend development forever, the TC39 committee switched to an iterative approach and started shipping new features every year.

And the nice thing is that if you're using modern browsers or runtimes, you often get access to these features almost immediately.

So, what do we get in ECMAScript 2026?

Oh, and to keep things entertaining, all code examples in this article are based on the internal monologue of imaginary LinkedIn gurus with very strong opinions. Any resemblance to actual people is, naturally, purely coincidental 😇

Other articles from this series:


1. Map.prototype.getOrInsert() / Upsert

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map/getOrInsert

This is one of those features that makes you wonder: "Wait… why didn't we have this ten years ago?"

Imagine we're collecting opinions from LinkedIn gurus. Until now, we had to do something like this:

const opinions = new Map();

function addOpinion(topic, author) {
  if (!opinions.has(topic)) {
    opinions.set(topic, []);
  }

  opinions.get(topic).push(author);
}

addOpinion("React is dead", "10x Engineer");
addOpinion("React is dead", "Principal AI Evangelist");
Enter fullscreen mode Exit fullscreen mode

It works, but there's quite a bit of boilerplate.

With ES2026, things become much nicer:

const opinions = new Map();

opinions
  .getOrInsert("React is dead", [])
  .push("10x Engineer");

opinions
  .getOrInsert("React is dead", [])
  .push("Principal AI Evangelist");

console.log(opinions);
Enter fullscreen mode Exit fullscreen mode

We also get a computed version:

const opinions = new Map();

opinions
  .getOrInsertComputed(
    "Nobody writes clean code anymore",
    () => []
  )
  .push("DDD Purist");
Enter fullscreen mode Exit fullscreen mode

Come on, that's so much cleaner and easier to read. It's also perfect for caching! Much less code, much nicer API.


2. Iterator.concat()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator/concat

Before we talk about concat(), let's quickly answer a question:

What is an iterator?

An iterator is basically a cursor that lets us consume data one element at a time without storing everything in memory.

For example:

const posts = [
  "Angular is dead",
  "JavaScript was a mistake"
];

const iterator = posts.values();

console.log(iterator.next());
// { value: "Angular is dead", done: false }

console.log(iterator.next());
// { value: "JavaScript was a mistake", done: false }

console.log(iterator.next());
// { value: undefined, done: true }
Enter fullscreen mode Exit fullscreen mode

And because iterators are lazy, we can even generate infinite sequences without blowing up memory:

function* endlessHotTakes() {
  while (true) {
    yield "Everything should be rewritten in Rust.";
  }
}

const iterator = endlessHotTakes();

console.log(iterator.next().value);
console.log(iterator.next().value);
console.log(iterator.next().value);
Enter fullscreen mode Exit fullscreen mode

Last year we got Iterator Helpers, which introduced things like map(), filter(), and friends:

function* linkedinFeed() {
  yield "Use Rust for everything";
  yield "JavaScript was a mistake";
  yield "Clean code is dead";
  yield "Angular is dead";
}

const controversialTakes =
  linkedinFeed()
    .filter(post => post.includes("dead"))
    .map(post => `🔥 ${post}`);

console.log([...controversialTakes]);
Enter fullscreen mode Exit fullscreen mode

And now we get another nice addition: Iterator.concat(). Suppose frontend gurus and backend gurus each have their own stream of wisdom:

function* frontendExperts() {
  yield "React is dead";
  yield "Nobody needs Redux";
}

function* backendExperts() {
  yield "Microservices solve everything";
  yield "Frontend developers don't understand architecture";
}
Enter fullscreen mode Exit fullscreen mode

Now we can combine them elegantly:

const feed = Iterator.concat(
  frontendExperts(),
  backendExperts()
);

console.log([...feed]);
Enter fullscreen mode Exit fullscreen mode

In my opinion, these iterator features don't get nearly as much attention as they deserve.


3. Array.fromAsync()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fromAsync

This is basically the async equivalent of our beloved Array.from().

It's primarily designed for async iterators, although I suspect that most JavaScript developers don't use async iterators every day. For example, imagine comments arriving one by one from LinkedIn:

async function* angryComments() {
  yield "This could have been a plain HTML form.";
  yield "Angular is dead.";
  yield "React is dead.";
  yield "JavaScript was a mistake.";
}

const comments = await Array.fromAsync(
  angryComments()
);

console.log(comments); 
// This could have been a plain HTML form.
// Angular is dead.
// etc
Enter fullscreen mode Exit fullscreen mode

But here's something many people don't realize: it also works with promises.

const opinions = [
  Promise.resolve("Nobody should use classes."),
  Promise.resolve("Signals change everything."),
  Promise.resolve("Microservices ruined software.")
];

const takes = await Array.fromAsync(opinions);

console.log(takes); 
Enter fullscreen mode Exit fullscreen mode

And you can even map values immediately:

const comments = await Array.fromAsync(
  angryComments(),
  opinion => opinion.toUpperCase()
);

console.log(comments);
Enter fullscreen mode Exit fullscreen mode

Pretty convenient.


4. Math.sumPrecise()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/sumPrecise

This one solves a floating-point problem that's almost as old as the Internet itself 😄 As many of you probably know, in JavaScript:

console.log(0.1 + 0.2);
// 0.30000000000000004
Enter fullscreen mode Exit fullscreen mode

I won't dive into why that happens today: we'd be here all night 😄

The important thing is that ES2026 introduces Math.sumPrecise(), which performs much more accurate summation and avoids the accumulation of rounding errors.

Suppose a LinkedIn guru is listing all the things that allegedly increase productivity:

const productivityBoosts = [
  0.1, // cold showers
  0.2, // AI agents
  0.3, // journaling
  0.4, // waking up at 4 AM
];

console.log(
  Math.sumPrecise(productivityBoosts)
);
Enter fullscreen mode Exit fullscreen mode

Now, to be fair, most frontend developers will probably never need this. Plain old addition works perfectly fine for everyday use.

But if you're working in finance, statistics, simulations, or AI/ML, where tiny errors can accumulate over thousands or millions of operations, this becomes much more interesting.


5. Error.isError()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/isError

This one is probably aimed more at library authors and advanced developers. Or maybe not? 😉 Until now, checking whether something was actually an error usually looked like this:

try {
  throw new Error(
    "Angular is dead."
  );
}
catch (e) {

  console.log(
    e instanceof Error
  );
}
Enter fullscreen mode Exit fullscreen mode

And most of the time, that worked perfectly fine. Until it didn't.

If an error originated in another realm, for example an iframe, a Web Worker, or a VM context—instanceof Error could suddenly betray you:

const strangeThing =
  window.frames[0].eval(
    "new Error('JavaScript was a mistake.')"
  );

console.log(
  strangeThing instanceof Error
);

// false 
Enter fullscreen mode Exit fullscreen mode

This problem has been annoying library authors for years, which is why many frameworks and libraries have their own helper functions for detecting errors. Now we finally get a built-in solution:

console.log(
  Error.isError(strangeThing)
);

// true
Enter fullscreen mode Exit fullscreen mode

Simple and beautiful.


6. Base64 for Uint8Array

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/toBase64

Quick reminder: Base64 is simply a way of converting binary data into plain text. Why would we do that? Because many protocols and formats are much happier dealing with text than raw bytes. For example, we might send an image as a Base64 string.

Now, someone might say: "Wait a minute, Base64 already existed in JavaScript!" And yes, it did. But it mostly worked with strings:

btoa("JavaScript was a mistake.");
Enter fullscreen mode Exit fullscreen mode

When dealing with binary data, things quickly became ugly:

const bytes = new Uint8Array(buffer);

const base64 = btoa(
  String.fromCharCode(...bytes)
);
Enter fullscreen mode Exit fullscreen mode

Not terrible, but definitely not something you'd call elegant.

Now we can simply write:

const screenshot =
  await fetch(
    "/proof/react-is-dead.png"
  );

const bytes =
  new Uint8Array(
    await screenshot.arrayBuffer()
  );

const base64 =
  bytes.toBase64();

console.log(base64);
Enter fullscreen mode Exit fullscreen mode

Much cleaner. And, perhaps more importantly, much easier to understand six months later.


7. JSON.parse Source Text Access

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

JSON.parse() is great. Until somebody sends you a gigantic number. Suppose a LinkedIn guru claims to have 999 trillion followers:

const json = `
{
  "followers":
  999999999999999999999999999999
}
`;

const data = JSON.parse(json);

console.log(data.followers);
Enter fullscreen mode Exit fullscreen mode

Oops. JavaScript numbers have limits, and very large integers may lose precision.

With ES2026, the reviver callback gets access to the original source text, allowing us to recover huge values safely:

const data = JSON.parse(
  json,
  (key, value, context) => {

    if (key === "followers") {
      return BigInt(context.source);
    }

    return value;
  }
);

console.log(data.followers);
Enter fullscreen mode Exit fullscreen mode

No more accidental corruption of giant numbers.

Most of us won't need this every day. But if you're dealing with IDs, financial data, or huge integer values, this can save you from some nasty bugs.


Bonus: The Great Absentees

I was really hoping these features would make it into ES2026, but unfortunately we'll have to wait another year.

Well, sort of. Modern browsers and runtimes have already started implementing them, but they are not officially part of the ECMAScript 2026 specification yet.

These are probably the two features I'm personally most excited about.


Temporal API

TC39 proposal:
https://github.com/tc39/proposal-temporal

If you've been doing frontend development long enough, chances are you've had at least one traumatic experience involving dates. Maybe something like this:

const date = new Date("2026-03-30");

console.log(date);
Enter fullscreen mode Exit fullscreen mode

Depending on your timezone, congratulations! You've just entered the exciting world of: "Why is it yesterday?"

Or perhaps you've experienced everyone's favorite:

const today = new Date();

today.setMonth(today.getMonth() + 1);
Enter fullscreen mode Exit fullscreen mode

And suddenly you're debugging why March plus one month somehow became May.

Or maybe you've been lucky enough to deal with time zones.

At which point you discover that time itself is apparently an illusion and that daylight saving time was invented specifically to ruin programmers' lives.

This is why many of us ended up using libraries like Moment.js. Ironically, even the Moment.js maintainers now recommend using other solutions. Then came date-fns, Luxon, and various other attempts to restore sanity.

They certainly help. Until somebody says: "By the way, users in Australia are reporting weird bugs." And that's usually where the fun begins.

Temporal aims to fix all of this by introducing proper date and time types.

Instead of:

const now = new Date();
Enter fullscreen mode Exit fullscreen mode

we get things like:

const now = Temporal.Now.instant();

const birthday =
  Temporal.PlainDate.from(
    "1987-07-23"
  );

const meeting =
  Temporal.ZonedDateTime.from(
    "2026-11-03T10:00:00[Europe/Warsaw]"
  );
Enter fullscreen mode Exit fullscreen mode

And suddenly everything becomes much more explicit.

By the way, I spent an embarrassing amount of time trying to figure out whether Temporal had actually made it into ES2026. Eventually, I found the TC39 repository, where it clearly says that although the proposal has already reached Stage 4, its expected publication year is 2027.

So we're close. Very close. And I can't wait ❤️


Explicit Resource Management (using)

TC39 proposal:
https://github.com/tc39/proposal-explicit-resource-management

This is one of those features that C# and Python developers have been quietly enjoying while the rest of us pretended that try/finally was perfectly fine 😄

Sometimes you create something that needs cleaning up afterward: file, database connection, stream, WebSocket, etc. Today, we usually write something like this:

const webinar =
  createAIAgentsWebinar();

try {

  webinar.start();

}
finally {

  webinar.close();

}
Enter fullscreen mode Exit fullscreen mode

The finally block is often written with the same enthusiasm as unit tests. Worse, if we forget it entirely, we may end up with resource leaks and mysterious bugs.

With using, cleanup happens automatically when leaving the scope:

using webinar =
  createAIAgentsWebinar();

webinar.start();
Enter fullscreen mode Exit fullscreen mode

Once we leave the scope, JavaScript automatically calls the cleanup logic. How cool is that?

It's one of those features that might not affect the average frontend developer every day, but for Node.js developers, library authors, and people working with streams and files, it can be incredibly useful.


Uff...

I have to admit, this article turned out to be way more work than I originally expected 😅 It was supposed to be short and easy. And somehow I ended up digging through TC39 proposals, MDN pages, browser implementations, and trying to figure out whether Temporal had actually made it into ES2026 or not.

But I hope it was worth it and that you enjoyed it ❤️

What about you? Which feature surprised you the most? And are you also eagerly waiting for Temporal to finally free us from all date-related suffering?

(Or at least that's what the LinkedIn gurus will probably tell us next week 😇)


If you enjoyed this article, feel free to connect with me on LinkedIn😊

Top comments (19)

Collapse
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

But today is finally the day for something a bit lighter.

Lighter?🤔
Hmm… interesting, for sure. Lighter? Depends on your own javascript skills.

And about inclusion in the Top 7 Posts of the Week: the post deserves it, you deserve it. It was really interesting.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thanks, Pascal! Yeah... I think something went slightly wrong with the "lighter" part of this post. Maybe next week I'll finally manage to write something truly lightweight. 😅

And you're right about the migration post. Writing the article itself took quite a while, but compared to preparing the conference talk, that was the easy part! There was a lot of research, testing, refining examples, and trying to distill years of migration lessons into something useful and practical.

So I'm especially happy to see that people found it valuable. 😊

Collapse
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

What you are seeing—and what I see too—is that hard work still pays off: gathering sources, doing your research, incorporating your own knowledge, and pulling it all together—all of this contributes to the richness of an in-depth article and to the recognition of your work, whether through the comments you receive, inclusion in the "Top 7 of the Week," or in many other ways.

Thread Thread
 
sylwia-lask profile image
Sylwia Laskowska

Exactly! 😄 Maybe it doesn't make us any richer, but at least we get to have great conversations with interesting people in the comments. And that's one of the best parts of writing. 😊

Collapse
 
hemapriya_kanagala profile image
Hemapriya Kanagala

Sylwia, I can tell a lot of work went into this one 😄

I'm not that deep into JavaScript myself, but I still learned a few things from this. It's easy to forget that the language keeps evolving while everyone is busy talking about AI these days.

Thanks for sharing this.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thank you so much! 😊

That's always my goal: to make technical topics approachable and easy to digest, even for people who don't work with JavaScript every day. I'm really glad you found something useful in it!

Collapse
 
gramli profile image
Daniel Balcarek

Nice, it looks like JS is slowly catching up with “real” languages like C#. 😄🤪 Just joking, of course. 😄

But honestly, Temporal.Now.instant() and using features look amazing. Having them in JS would be great. I hope we get them next year.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Haha, exactly! 😄 We're getting closer to the "real languages" every year.

Though honestly, JavaScript will never fully get there, because we'd have to break half the web to do it. 😂

Temporal should make it into ES2027 without much drama, but using is still only at Stage 3, so we'll see. I'm keeping my fingers crossed though!

Collapse
 
adamthedeveloper profile image
Adam - The Developer • Edited

awesomeeeeee!! this is my favorite now btw:

const meeting =
  Temporal.ZonedDateTime.from(
    "2026-11-03T10:00:00[Europe/Warsaw]"
  );
Enter fullscreen mode Exit fullscreen mode
Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Exactly! 😄 A brave new world where dates actually make sense. 😂

Collapse
 
dannwaneri profile image
Daniel Nwaneri

The getOrInsert addition is the one I've been waiting for . That pattern of checking has() then set() then get() shows up everywhere in agent memory implementations and it's always felt like boilerplate that shouldn't exist. Math.sumPrecise() is the other one worth flagging for anyone doing token budget calculations where floating point drift compounds across requests. Good breakdown — the TC39 repository dig on Temporal was worth it.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thanks, Daniel! 😊 That's a great example.

To me, it really shows how these features are catching up with the reality of modern development and helping us write code that's a better fit for today's AI- and agent-driven applications, instead of relying on the same old boilerplate patterns.

Collapse
 
linb profile image
Jack Lee

JavaScript has always felt like a premature baby.
Back in the early days, every project was a collection of hacks, browser quirks, polyfills, and "don't touch this code" comments. Many of today's features aren't innovations so much as missing pieces that should have existed from the beginning.
The surprising thing is not how much JavaScript has changed, but how long it took to grow up.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Exactly! 😄 That's actually one of the reasons I've been on a bit of a crusade in my articles lately: making people aware that many of the hacks and workarounds we've used for years simply aren't needed anymore.

And as for the missing pieces... well, what can we expect from a loosely typed language that was famously created in about a week? 😂 

Collapse
 
technogamerz profile image
𝕋𝕙𝕖 𝕃𝕒𝕫𝕪 𝔾𝕚𝕣𝕝

Wow, absolutely loved this breakdown! JavaScript is evolving so beautifully, and these ES2026 features are exactly what we needed. Map.prototype.getOrInsert() is an absolute game-changer for reducing boilerplate and boilerplate map checks, and the performance benefits of Iterator.concat() without memory bloat are huge. Love the witty examples and the tone of the article—makes complex updates so digestible and fun to read. Can't wait to start refactoring my code with these. Thanks for this amazing write-up!!!!

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thank you so much! 😊

That's exactly the goal: raising awareness of what's already available in the language, so people don't end up pulling in entire libraries for things JavaScript can now do out of the box. 😄

And honestly, some of these additions may look small, but over time they can remove a surprising amount of boilerplate from our codebases.

Collapse
 
evanlausier profile image
Evan Lausier

uggh... server date offsets. The worst!

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Haha, true! 😄 Always. ALWAYS. In every single project. 😂

Some comments may only be visible to logged-in visitors. Sign in to view all comments.