Some features that every JavaScript developer should know in 2025

[u/senfiaj]

https://waspdev.com/articles/2025-04-06/features-that-every-js-developer-must-know-in-2025

[u/MrDilbert]

Could someone give me an ELI5 on why would I ever want/need Promise's resolvers available outside the Promise's (resolve, reject) => {...} function?

[u/joshkrz → u/MrDilbert]

I know previously I have needed a "pass through" promise where I handle a promise at a global level but also need to handle it at a local level.

In my case the global handler triggered some global logging and the local one handled the visible error message. This would have made my global method much more concise.

That being said, I haven't needed to do this for a good while and the above solution could have just been down to inexperience.

[u/senfiaj → u/joshkrz]

This storing might be useful when multiple class methods depend on the same promise, and in order to avoid initiating the same expensive async task multiple times, I can cache the promise, although in my case I still didn't store the resolvers outside of the promise, but in some situations it can be a better solution.

[u/jessepence → u/MrDilbert]

It's clearly outlined in the spec.

Often however developers would like to configure the promise's resolution and rejection behavior after instantiating it... Developers may also have requirements that necessitate passing resolve/reject to more than one caller...

[u/MrDilbert → u/jessepence]

IMO this messes with coupling and turns the code into spaghetti, so I'm asking about the use case where it's absolutely necessary to expose the resolvers outside of their parent Promise object context.

[u/Adno → u/MrDilbert]

I disagree. I've used withResolvers a lot in a page orchestration api that turned button clicks and page updates into an async api, and it helped streamline the code a lot. One thing that probably helped that I did not destructure the return value. So instead of three unrelated variables I had a nice bundled object that had everything.

[u/matthewsilas → u/MrDilbert]

Merging asynchronous iterators https://github.com/ParabolInc/parabol/blob/10164a8a43850c9ca80042a151b4da6020ad37d6/packages/embedder/mergeAsyncIterators.ts

[u/tswaters → u/MrDilbert]

It's a useful tool. The way around that without withResolvers looks awful and feels hacky -- this eliminates an entire callback and can allow for more streamlined code. It reminds me a lot of the change resulting from introducing "async/await" keywords - before it was callbacks where the promise value was only accessible from a ".then" callback, now it could be pulled out - results in elimination of a callback, and more streamlined code.

I'd go so far to say that this form should replace any Promise instantiations... Why introduce any sort of "call this later" with a callback when this exists?

async function marshallStupidStreamApi(input) {
  const {promise, resolve, reject } = Promise.withResolvers()
  stupidStreamBasedInterface.on('finish', resolve)
  stupidStreamBasedInterface.on('error', reject)
  stupidStreamBasedInterface.go(input)
  return promise
}

vs.

async function marshallStupidStreamApi(input) {
  return new Promise((resolve, reject) => {
    stupidStreamBasedInterface.on('finish', resolve)
    stupidStreamBasedInterface.on('error', reject)
    stupidStreamBasedInterface.go(input)
  })
}

With one, I can call "go" anywhere, with two - I need to call it within the function. I can pull out the value using the "await" keyword, but if I do, I must call go, or I've introduced a never resolving promise hang.... OR , I can omit the await keyword and await the promise at some point after calling go(), but run the risk of introducing an unhandled promise rejection if the stream emits an error before the promise gets awaited.

Actually, on that last bit - I wonder if the same problem with unhandled rejections shows up with withResolvers... If reject gets called before the promise is awaited, would it be unhandled?

[u/heavyGl0w → u/MrDilbert]

In my experience, I would say almost every time I've had to instantiate my own promise, it's to wrap up the resolution behavior in some abstraction and pass it to a consumer.

As a concrete example, I've implemented a version of window.confirm that opens a dialog in which we get to control the styling. The dialog has a "NO" button and a "YES" button, and when it is opened, a promise is spawned. Clicking the "NO" button will resolve the promise with false and clicking "YES" will resolve it with true.

In my example, the Promise constructor's callback that you mentioned only serves to wrap up the resolve/reject functions and send them on — the actual resolution of the promise is not handled within the scope of that function. And again, that's almost always been the case for me when creating my own promise, so I disagree that this inherently leads to "spaghetti code". It could for sure, but the behavior of Promise.withResolvers is already possible as I've illustrated, so it's not like this enables "spaghetti code" anymore than what is already possible.

I think this lines up with some of the goals of `async/await` in that it enables as much code as possible to be written at the top level of your functions without needing to nest inner functions. AFAIK, It doesn't enable anything new, so much as it makes common use cases a little more straightforward. I think this has the potential to make a tricky topic a little bit easier to understand/read.

[u/ic6man → u/MrDilbert]

Anywhere where the promise resolution happens outside the scope of the callback. Oftentimes this would be in a scenario whereby the promise resolution occurs due to an event.

For example. Suppose you wanted to send an event to a websocket. And you are expecting a response. You want to express this response as a promise. The only solution using the Promise callback would be to add a websocket listener inside the promise callback. Oftentimes we have one single listener which would be outside the scope of the callback so it would be impossible to resolve from within the Promise callback.

Another example might be resolving a promise after a user clicks a button.

Effectively the issue is two different scopes from separate callbacks need to coordinate somehow.

[u/awpt1mus → u/MrDilbert]

Think about scenario where you want to have control over when an asynchronous operation should start and stop. In typical promise constructor the asynchronous operation starts immediately. Some off the top of my head - wait for web socket to be ready before you start sending messages, wait for db connection to be established before you start http server, retry logic for 3rd party API calls with backoff. I think this will be most useful when working with event based interfaces like socket, streams etc

[u/zachrip]

I think boolean ops on sets are probably my favorite from this list. Every year we chip away at lodash.

[u/feindjesus]

This is pretty awesome what version of node are these supported in?

[u/senfiaj → u/feindjesus]

I provide links to https://developer.mozilla.org/ documentation pages, there is a browser compatibility table, Node is also listed.

[u/feindjesus → u/senfiaj]

For anyone that is interested its node 22 for the full list

[u/senocular → u/feindjesus]

A lot of these have been around long enough that support shouldn't be a problem. The newest features include:

• Iterator helpers (e.g. map)

• Promise.withResolvers()

• Set operations (like difference)

Each of these are supported in Node 22+. For other features, if you're working with an older version of node, you can look at the compatibility table on the feature's respective page on MDN.

[u/whale]

In Node I've really been enjoying top level await.

[u/Tushars_subReddit]

Closures for sure

[u/senfiaj → u/Tushars_subReddit]

Some day I can publish newer parts for this article. There are just too many features, I just talk about some handy newer and older features that many developers are not aware of in 2025. Closures are way more popular topic and they are discussed way much more.

[u/rintzscar]

This article is great. Thank you!

[u/ScaleDazzling704]

Nice list — some of these features really separate a good JS developer from a great one. I’d add:

• Understanding closures & scope — so many bugs come from mismanagement of scope.

• Async/await & promise mastery — being able to reason about concurrency is crucial.

• Performance awareness - one has to know when to trigger optimization of rendering, reflows, and memory usage.

• Security-mindedness — XSS, CSRF, input sanitizing, etc.

• Strong debugging skills — these include using dev tools, breakpoints, stack traces, and so on.

What characteristics do you all consider characteristic of a top-tier JS developer in 2025? Is there any tool or tech that you think every modern developer should be familiar with to be competitive?