3 Questions: You Don't Know JavaScript | Prime Reacts 

I'm glad he got it wrong. I feel better about getting it wrong too.

That question is the equivalent of "you drive a car? Name all the assembly plants where all the parts in your car were manufactured". Obviously you don't need to know that if you just want to drive a car. Unless that's why I still can't pass my driving exam...

The order question is stupid, if your code relies on that this order is maintained in order to work, your code is wrong. No wander not many know it.

80%? lol my bet is more than 95%

I don't think 80% of JS devs understood any of them

As a non-JS dev, reading this is horribly confusing; I'm glad I don't have to deal with this.

As someone who grew up with jQuery, I am screaming

@@KeremyJato there are 3 languages I hate, PHP, Java, and JavaScript. I can tolerate the last one, but it is mostly Hate Driven Development

Me too, and then I realize I just mess with it until it does what I expect it to do.

If it was just interpreted at runtime that would be one thing. The fact that you have to interpret whether it's a pointer or not is insane.

return emotionally hurt me

@@ThePrimeTimeagen But ask yourself; why would you ever care about the value _after_ an iterator is already done, unless you manually handled the iteration?

"return" in generators is perfectly ok and I'd say a must: there are ton of problems where you want to early stop a generator. The issue is with "return " which is... odd.. at least.. A generator should yield values, and [eventually] end (return), it's not expected to return values. (btw, C# "solved" the ambiguity using "yield return " and "yield break" instead of reusing an existing keyword)

​@@IMJambyyield break sounds like a nicer syntax than return.

@@IMJamby stop early you say? sounds like an exception to me -- python

The so called and sometimes taught nowadays as "factory functions". Dude I had a huge clarifying moment last week when I finally decided to dive deep in understanding prototyping, inheritance and composition. Everything made sense afterwards, it was kinda of a cascade effect in my mind. But now I realize that javascript isn't well designed as some other languages.

@@jmfariasdev the inventor of JavaScript made it in just over a week iirc.

@k98killer people that architects and design programming languages are in another level that's for sure.

@@jmfariasdev It's just another thing that can be done well or poorly. Like anything else, it is a matter of learning from prior examples and then finding new ways to put ideas together.

var ass = new Promise(() => whatever.next()).await //gachiHYPER

Comment above says it all 👌

Lua Coroutines don't do this. You would have to function whatever() coroutine.yield(1) coroutine.yield(2) return 3 end or handle the final `nil`.

Bingo

Yes

Probably a computer 🤓💻

she use keynote ( i hear her answering your question once)

in real languages the compiler or linting would warn you about things like that, because here someone who first use generator can easily create a hard to find bug. the problem with js it that it's full of things like that

Commodore Basic V2

python (normie first language but at least it's not js)

You and me both..! I hate .js and all the (copy-paste integraded) JS into other New ones. Creates a web of a mess and slow af code.

I started with VBS yeah, but after leanring a little bit (which was a lot for a 12yo) but the first real one was js? but not to well, and the first really learnt was python

same garbage @@zokalyx

Finally, a safe language.

wish I could find a job in C

Rust us rusty though!

Because C has no footguns at all

@@spicybaguette7706 it does, but they are much more reasonable

It just wouldn't have a bound this simple

Binding is done on the fly! That allows a lot more memory saving

you pretty much had my thought process on 2 and 3 2 easy 3 i know she said it, but i refuse to believe it

If I was working with a codebase where knowing that order is necessary to maintain or debug it, I'd seriously reconsider my life choices.

Here's a hot take: HOW OFTEN in your day-to-day work do you need to know in which order these will execute? I mean, yes, you need to know there IS an event loop, and that there are certain steps within that loop that execute in a certain order, but how often do you need to KNOW THE EXACT order, or even ALL of the steps that execute within an event loop cycle? I mean, in the rare event that you do need to debug these (and that's when you run into a mix of setTimeout(..., 0) and setImmediate and Promise.resolve()), it shouldn't be that hard to google it out? Seriously, questions like that remind me of a meme about the Mendeleev's periodic table of elements, which he created specifically so that chemists DIDN'T need to memorize all the data about the elements, and then you get school teachers who FORCE the students to memorize it... -_-

It's not specified by spec, but some browsers/engines will add additional random time to the timeouts to mitigate Spectre attacks. Though, this can be disabled and it's not an important part of the question itself.

@@dealloc Well, I guess anything >6 will make it last out if those no matter what.

@@blenderpanzi It's not important to the question, because its a general question about the expected behaviour, given that you know the spec; not the internal workings of specific browsers and the random value that determines the timeout.

I remember the require('bluebird') times, I still failed the test. Somehow, a new stack has emerged (micro/macro) from my POV, with the chat even saying animation queue too ? I think spending so much time and energy delivering and learning tools, services, devops etc etc... makes us not having time to even learn that much of the language :x

it was humiliating

Yes. It's by spec. If an engine does it differently, file a bug report!

You are correct, at least in the past. Previously it had different order in different browsers. Need to check how is it now.

Sooo what if we discover dogs aren't canine? In a world of what ifs you won't get anything done

That's smells to me that you are not syncing your state with your rendering. Which can be perfectly viable if you rely on DOM mutations _after_ a commit (for one reason or another) for but no other reason really.

honestly, I'm not sure you're doing this right

@@dealloc I'm sorry. I was really unclear to what I'm doing. I use settimeout to push the queue around to figure out the flow. I don't leave a bunch of settimeouts in the code.

@@Tobsson Yes, but the only reason why you'd do that is 1) your flow is not well-defined, and 2) if in React, is due to not being in sync with React rendering, by doing work outside React's lifecycle.

@@dealloc defined? It becomes defined when it works as expected. 😂

I'm proud of you son

:(

It’s such a ghastly language. I’ve had to dive into it from time to time over the years, but do the minimum I need and get out.

@@nisonaticthanks for the explanation and this smells more like a hack than an actual solution

in chrome I get 1-4-3-2