Comment by Jason Knight on "What's the correct way to iterate over an array of objects in ES6 parallelly?"

The concept of a single "correct way" is a flawed one -- in JS there are always multiple ways of doing things and each is best suited to a specific type of data and a specific type of output.

That said, I'm wondering how you expect anything done in parallel in an inherently single threaded language. I mean you can fake the behavior, and there's the specification train wreck of promises, but if this is data you already have there's no point in trying to parallelize anything.

So I'd be throwing a question back at you -- what's the data and what are you doing to it? THAT determines the proper answer.

Why do you feel that promises are a "specification train wreck"?
While javascript itself runs in a single thread, you can offload work to other threads using various browser APIs such as Web Workers, which achieves real parallelism.

Joe Gaspar

An point 1:

a) The documentation is some of the worst I've seen out of the W3C or ECMA -- and that's going someplace special after the inept disaster they accepted from the WhatWG in the form of HTML 5, pissing on everything good in 4 strict from orbit. I honestly can't make heads nor tails out of any of the official documentation since again it's written for people who make browsers, not people who make websites. I've been programming for four decades, can hand assemble 6502, Z80, and x86 machine language -- and from my standpoint "promises" are a needlessly pointlessly convoluted mess of a language implementation that seems to confuse the ever living piss out of beginners and experts alike!

But that's anything W3C related of the past ten years, you HAVE to go to third party resources to have any of it make sense -- which to be brutally frank means the specification and official documentation is shit.

b) It doesn't work consistently with how existing event driven systems work in JavaScript. Wouldn't have just been simpler to be able to create it as a normal event instead of creating a whole new series of "functions and constructs for nothing".

It feels as convoluted as flex-box does; there's a reason I'm moving away from bothering with flex and leaning more and more towards the (horribly mis-named) CSS3 Grid Layout module. In that same way "promises" just reeks of "there has to be a simpler way to have added this" mated to "Somebody wants to shoe-horn concepts from another language into one where it doesn't fit!"

On point 2:

Assuming the engine you're on supports them properly and doesn't just PRETEND they do. Assuming the browsers you have to deploy for even support it. I mean, fine if you're working on server-side code for node.js, but client side it's just not real-world deployable.

... and if those other API's are what REALLY does it, what the blazes do we need a language contsruct for? Pointless redundancy. AGAIN one of the concepts 4 strict was giving us that got tossed in the bin -- removing pointless redundancies.

Jason, Imagine you have an array of some objects. You want to make an API call on those objects, but you don't want it to be sequential. This is my use case. Also, I agree that there's no one correct way to do anything, happy to know one of those correct ways for the use case I mentioned.

Siddarthan Sarumathi Pandian To me that is still too 'vague' a description of what is being done. I would still be asking WHY not sequential? ...and even if so how and what that data is and WHY it is being processed out of order / parallel would be the determining factor of how I'd go about it.

What is being put in and what's being done with it is how you make your choices. Simply saying "API call" and "objects" is uselessly and pointlessly vague. WHAT objects? WHAT API? What mechanism of passing? What processing?

Search Hashnode