> This simplifies access to shared state without race conditions

But in ordinary JS there just can't be a race condition, everything is single threaded.

SkiFire13 3 hours ago | parent | next [-]

You can definitely have a race condition in JS. Being single-threaded means you don't have parallelism, but you still have concurrency, and that's enough to have race conditions. For example you might have some code that behaves differently depending on which promise resolves first.

▲

Kinrany 3 hours ago | parent | prev [-]

And it doesn't actually prevent concurrency.

▲

gf000 3 hours ago | parent [-]

Sure, but concurrent != parallel. You can't have data races with a single thread of execution - a while loop writing i=0 or i=1 on each iteration is not a data race.

Two async functions doing so is not a data race either.

▲

Rapzid 2 hours ago | parent | next [-]

You should really look up the definition of race condition; it has nothing to do with parallel processing. Parallel processing just makes it harder to deal with.

▲

gpderetta 3 hours ago | parent | prev [-]

Data race != Race condition

▲

gf000 3 hours ago | parent [-]

Data races are a specific race condition - they may be safe or cause tearing.

Serially, completely synchronously overwriting values is none of these categories though.

	▲	Maxatar 2 hours ago \| parent [-]
		You're mixing up quite a few somewhat related but different concepts: data races, race conditions, concurrency and parallelism. Concurrency is needed for race conditions, parallelism is needed for data races. Many single threaded runtimes including JS have concurrency, and hence the potential for race conditions, but don't have parallelism and hence no data races.