## DEV Community is a community of 667,450 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

# ⭐️ Interactive JavaScript Quiz #1

Lydia Hallie
@theavocoder | i like da codez

We all know that JavaScript quizzes can be... awful and confusing 😐 The pointless foo bar baz questions ruin all the fun of JavaScript and often just cause even more confusion!

Last year, I made a GitHub Repo with tons of JavaScript questions that aren't questions like "tricky" or "NaN === NaN", but rather focus on more realistic situations. I thought it would be fun to make it into an interactive game series here on Dev.to, with animated explanations wherever possible! 🥳

## lydiahallie / javascript-questions

### A long list of (advanced) JavaScript questions, and their explanations ✨

Of course, the examples are still minimal and don't show "the best/most performant way to do it". Sometimes I have to do things a certain way in order to be able to show certain behavior that may happen, and explain it that way 🙂

#### 1. What's the output?

##### Explanation

With the bind() and call() method, we can decide to which object the this keyword should refer. In this example, we're saying that the this keyword within the sayHi function should refer to the person object by calling both bind and call on the sayHi function 🥳

Although the bind() and call() methods both allow us to specify which object the this keyword should refer to, there's a tiny difference:

• bind() only returns a copy of the bound function
• call() executes the bound function immediately

First, we log sayHi.call(person, 21). The call method executes the (bound) function immediately, which results in Lydia is 21.

Then, we log sayHi.bind(person, 21). The bind method returns a copy of the bound function, meaning that we're simply logging a new, copied function 😃

#### Explanation

Whenever we declare a set a variable equal to an object, we're not actually giving that variable the value of that object. Instead, we're giving it the value of a reference (or actually pointer) to that object in memory! ⚡️

In this case, we give the person variable the value of a reference (pointer) to the object { name: "Lydia" } in memory.

Then, we declare a variable called members. The value of members is a reference to that array in memory!

The first element in the array that members has a reference to, is the object that person has a reference to. When we set objects equal to each other, we're actually creating a copy of the reference. This means that now person and the first element in the members array point to the same object in memory! 😃

Then, we set person equal to null. This means that person no longer has the value of the reference to the { name: "Lydia" } object in memory: it now has a reference to null! 🎉 Since the first element in the array that members has a reference to has its own, copied reference, the change of the value of person does not affect the first element in that array!

Since the first element in the members array still has a reference to the object { name: "Lydia" }, that object gets returned when logging the first element!

#### Explanation

We have a list of groceries! One item in this list is our favorite item, and one item in this list is our least favorite item.

First, we want to get the value of our favorite item, the grapes! One way of doing this, is by using the find() method. The find method returns the value of the item in the array that we're trying to find: the string with the grapes in this case "🍇". We assign the variable favoriteItem to that returned value.

Since the string "🍇" is a primitive data type (it's a string! 🥳), the string gets passed by value. This means that the value of favoriteItem is a copy of the item "🍇" in the groceries array, without containing any references to the groceries array.

We no longer want the grapes as our favorite item! Instead, we want to make the avocado "🥑" our favorite item. The variable favoriteItem gets reassigned with the value "🥑".

Then, we want to find the index of our least favorite food: the string with the cheese "🧀"! In order to find the index of the cheese, we can use the indexOf method. To the indexOf method, we pass the value of the element of which we're trying to get the index in the groceries array: "🧀" in this case.

Perfect! We now have the index of our least favorite item. Time to replace the least favorite item with some good food: a pizza "🍕". By replacing the value of the item on a specific index, we're modifying the groceries array.

Cool! We just changed the least favorite item in the groceries array. When logging the groceries array, ["🍅", "🍇", "🍕"] got returned.

How'd it go? Did you get all 3 right? If yes, awesome! 🎉 If you made some mistakes, no worries at all!

Hopefully you can learn something from the explanations, and take that new information into consideration the next time you may run into behavior that may seem "unexpected" 🙂

Feel free to reach out to me!

## Discussion (38)

Aleksandr Hovhannisyan

3/3! :)

Regarding #2, I don't like that JavaScript and Java developers continue to use the term "reference" when they're really talking about pointers.

References are aliases, which don't exist in Java or JavaScript. If they did have references, the answer to #2 would be different. These two languages have "object references," which are really just pointers by another name.

Your GIF is excellent, though, and explains exactly what's going on (correctly), using arrows like you normally would when talking about pointers.

For those wondering: This may seem pedantic, but it's not. There's a great discussion about the whole reference vs. pointer issue with respect to Java here:

Cheers!

Lydia Hallie

Agreed! 😄

I prefer to use pointer (in fact I just added a quick change to that section), the main reason I keep on using "reference" is because I've noticed that there is tons of resources out there online that only talk about references, I'm afraid it'll lead to more confusion to not mention them here.

But it's definitely worth updating the explanation! Thanks!

Aleksandr Hovhannisyan

Yup, that's understandable. Unless people have worked with C/C++/assembly, they likely won't be familiar with pointers, so it may end up confusing them.

Vedran Čačić

You're subtly wrong. Of course, you're completely right within the terminology of C++, but it is wrong on a moral level to use that terminology when explaining JS.

Many young people learn JS today. They have no idea a dinosaur such as C++ even exists, let alone that it has some quite technical definitions for notions such as references. It served Bjarne well (he had no choice, because he had to be backward compatible with C terminology), but it is high time we leave those exotic redefinitions behind. (Gosling tried to do it, but he did it halfway and the result it even more confusion.)

Young people today (in general, not CS-minded population) have no idea what "pointer" means (except as a designation for a certain finger:)), but they have a very good idea of what is a "reference" (google.com/search?q=define+reference). It is something that refers to the object in question. When we refer people to certain books in bibliography, it's perfectly understood that there are not books themselves in the bibliography (nor their aliases:-P), but references to them.

Let's use the word as it's intended to be used, and in the process demystify at least a bit of that impenetrable CS lingo. Yes, calling the JS variables "object references" will confuse you if you intend to implement JS in C++, but who would want to do that? :-D

Aleksandr Hovhannisyan • Edited

They have no idea a dinosaur such as C++ even exists

Which is a shame! C++ is a fantastic language for beginners to learn because it exposes them to fundamentals that are very important to learn early on, like pointers, memory management, memory leaks, OOP, namespacing, and lots of other concepts that you'll come across in other languages as well. It's only a dinosaur by age; it's still very much relevant today.

Young people today (in general, not CS-minded population) have no idea what "pointer" means (except as a designation for a certain finger:)), but they have a very good idea of what is a "reference" (google.com/search?q=define+reference).

Not necessarily true. When drawing diagrams of objects in memory, for example, we tend to naturally use arrows (pointers).

Let's use the word as it's intended to be used

If only we could... Unfortunately, the true meaning of "reference" has been lost.

Again, it's not pedantry. Terminology needs to be precise.

This post asking whether Java is pass by value or pass by reference has over 1.9 million views:

stackoverflow.com/questions/40480/...

So many people are drawn to a question that's actually really easy to answer—if only Java didn't insist on using the term "reference" when it really means "pointer." It confuses people when they learn about "passing by reference." Beginners think, "Well gee, Java has references... If I pass one into a function, surely that's pass by reference, right?"

Your suggestion is for us to continue shielding beginners from the truth for fear that they'll get scared away by the complexity. Frankly, if that's the case, they've chosen the wrong profession—shying away from complexity only creates more confusion down the road. It's inevitable; beginners may as well learn to use the proper terminology early on if they're really serious about pursuing dev.

One last thing to note: Pointers exist in all languages, not just C++. Call them whatever you want. At the lowest possible level, there is no way to store an "object" or an array or a string in a CPU register; all you can do is store bytes, sequentially or otherwise. Hence the universal need for pointers.

Vedran Čačić

Note: this is going to be a long discussion. I enjoy it very much, but I don't understand DEV enough to know whether it is a good etiquette to hijack a top comment like this. So, Lydia, if you feel we're not providing value to your readers, just say so and we'll find a different venue.

C++ is a fantastic language for beginners to learn because it exposes them to fundamentals that are very important to learn early on

I agree with everything in that sentence except "early on". Seriously, has the first language you've learned been C++?? I know it wasn't in my case. The concepts that are important in the early stages of programming are quite different from ones that are important in the long term, and that's fine -- in all human endeavors. That is what separates apprentices from masters.

If you knock down a beginner (who is just trying to grasp the syntax) with undefined behavior, there is a good chance they'll never get up anymore. They'll just conclude programming isn't for them. (I've seen it!) Which you might say is just fair, but I think that is the real shame. Just a clash of value systems, I guess.

it's still very much relevant today.

Absolutely. Languages are relevant for many different reasons. COBOL was relevant because of a huge library, FORTRAN because of its numeric capabilities, C because of portability, JS because it runs in a browser, Python because the programs are a joy to read, Lisp because... well, Lisp was never relevant. :-Q

C++ is mainly relevant because modern C compilers (which were goaded into compiling C++ too) are the most complex software the humankind has ever produced, by an order of magnitude. Many decades will pass before we accomplish something similar for any other paradigm. (See Rust as a perfect example of how hard it is to get such a project off the ground, despite having intelligent hardworking people and a much better paradigm.) So if we just want to get as close to the metal as possible without tying our code to a particular type of metal, there really is no choice.

But of course, that criteria mean perfectly nothing to beginners. For them, "runs in a browser" or "natural readability" are much more relevant. And we can not blame them for that. For me, the criteria was "It is hardwired in my machine, so I don't have to wait while it loads from tape", so I chose BASIC.

When drawing diagrams of objects in memory, for example, we tend to naturally use arrows (pointers).

So do a test. Take someone without C-centered education, draw such a diagram and ask them to put in words what they see. They'll use "connected to", "describes" or even "is a value of", and you might get them to produce the word "reference", but you'll never get them to say "pointer". Simply because they've never heard of that word in that context.

Unfortunately, the true meaning of "reference" has been lost.

It hasn't. Bibliographers use it all the time. Even programmers, for example when they write LaTeX documents, use \ref to refer to a label. They don't use \point. :-P It just seems so if you live in a C-centered world.

Again, it's not pedantry. Terminology needs to be precise.

Absolutely. Only, in my opinion, "precise" is precisely opposite from what you say. To be precise is to call a concept we're discussing, a reference. To use "a reference" for "an alias" is imprecise to the point of being incorrect. Nobody does that, except C++ programmers.

About passing by reference: that's a completely separate can of worms, but if you insist, we can discuss that too. There are two undeniable truths: first, everything is "pass by value", if we call that what is passed "a value". Pass by address in C is nothing more than passing the address by value, for example. The true importance of the phrase comes only when speaking of a concrete variable, say "pass x by ...". Then we want to say that ... of x is passed (by value, of course:). ... might be x's address, reference, its value, or even its name (in some old versions of ALGOL).

Second undeniable truth is that if you only know of two types of passing from Pascal, and you speak about them in the context of previous paragraph, you'll inevitably be confused here, because passing in JS is neither of those. It's only by serious language twisting "when you declare a Dog d, d is not really a dog, but a pointer to a dog" that you manage to shoehorn it into one of these buckets. But it explains nothing, precisely because of the first undeniable truth: every pass is by value if we call that what is passed "a value". But if it doesn't correspond to what people usually think when they speak about the value of the object, it's simply misleading.

Your suggestion is for us to continue shielding beginners from the truth for fear that they'll get scared away by the complexity.

That's emphatically not what I'm saying. I'm asking to use the proper terminology, "proper" being defined more broadly than Bjarne Stroustrup.

One last thing to note: Pointers exist in all languages, not just C++. Call them whatever you want.

You probably mean "pointers exist in the implementations of all languages, and that's really true if those implementations are written in C (which they usually are). But they don't have to be. You can write a Python in Java (Jython), and its implementation really has no pointers. Anywhere.

If you really think pointers exist at the lanuage level, then you're simply not thinking broadly enough. There are no pointers in PROLOG, Haskell or Turing machines. Really. :-)

At the lowest possible level, there is no way to store an "object" or an array or a string in a CPU register; all you can do is store bytes, sequentially or otherwise. Hence the universal need for pointers.

Ah, good old reductionism. It has never got us anywhere, but people still try. :-) OK, let's do this one too.

There is no "lowest possible level" (that we know of). I could as equally say that there is no way to store bytes, you can only store electrical impulses or magnetic orientations -- or even lower below, quantum states. On an even lower level, you don't store anything, you simply collapse the wave function of the memory into some observable state.

Now you'll say that this is ridiculously low, and more importantly, irrelevant for the topic. And that is completely true. But it is equally true for the modern beginner when you tell them about registers, bytes (in the context of memory), or machine instructions. It simply doesn't enter their mental model until much later. And that's a good thing. Our ability to progress depends on the always heightening the level of abstraction, leaving the details of implementation deep below. We must: there is a long journey upwards ahead of us. ;-)

Aleksandr Hovhannisyan

I agree with everything in that sentence except "early on". Seriously, has the first language you've learned been C++??... If you knock down a beginner (who is just trying to grasp the syntax) with undefined behavior, there is a good chance they'll never get up anymore.

Actually, you're kinda right; the first language I learned was Java in AP Computer Science. I only learned C++ after that in my first (or second?) semester of studying comp sci. Nowadays, I hate Java and love C++.

The irony? I actually HATED C++ at first. It almost knocked me down. Java was comparatively less frustrating; in C++, I'd frequently get compiler errors, linker errors, and all sorts of weird crap.

But this experience was valuable nonetheless. For one, I realized that learning to program isn't necessarily trivial and that it requires a good bit of self-study and hard work. So I picked up a copy of C++ Primer and began studying the language to better understand it, in an effort to avoid getting knocked down again and again.

I guess it depends on what type of thinker you are and what you enjoy in programming. I'm biased because I like to think at a low level. We had to make a fully functioning REPL + linked list program in MIPS assembly for our computer architecture class, for example. And as painful as it was, it was also an incredibly educational experience in terms of understanding stack frames and pointers.

In the long term, it's probably safe to continue using the term "reference" in JavaScript because it's become idiomatic. Plus, it is, as you say, a natural way to talk about objects—a variable "refers to" an object in memory.

About passing by reference: that's a completely separate can of worms

Actually, it's not. In pass by reference, the formal parameter is a "true" reference (alias). Hence the name (and behavior) of pass by reference.

Most modern programming languages (save for C++ and PHP, for example) don't have true references (aliases), and hence they do not have any notion of pass by reference. Java programmers, when taught that there are these two ways of passing things into functions, are immediately confused because "reference" to them has, up until this point, meant "object reference" (pointer).

You probably mean "pointers exist in the implementations of all languages, and that's really true if those implementations are written in C (which they usually are). But they don't have to be. You can write a Python in Java (Jython), and its implementation really has no pointers. Anywhere.

I've never implemented a language, or examined a language's implementation, but I'm going to venture an educated guess here and argue that you're wrong. Pointers are not just a "C thing"—they exist at the assembly level, where a pointer is literally a CPU register that happens to store a memory address (which is a number like any other).

For example, how would you store a string or array in memory if not with pointers? Let's focus on strings. C makes it abundantly clear that a "string" is really a pointer to the first character of the string (e.g., char* greeting = "Hello World"). Why is this important? Because there's no way to cram the 12 bytes of Hello World into a single memory address on a byte-addressable system. Each character is a byte, so we can only store one "character" (really a number) per sequential memory address or "bucket." So the best we can do is have a pointer to the first of those sequential memory addresses; this allows us to increment the pointer by simple integer arithmetic to get the memory address of the next character. And so on.

But it is equally true for the modern beginner when you tell them about registers, bytes (in the context of memory), or machine instructions. It simply doesn't enter their mental model until much later. And that's a good thing

This is actually a really good point—beginners simply don't have any context for understanding registers, pointers, or any of that stuff. They need experience first; only then can they reflect on what they've been doing this entire time and appreciate its complexity.

I do feel like I sort of hijacked this post, though. I tend to do that on occasion. I certainly hope it's not rude, but 🤷‍♀️.

Vedran Čačić

About beginning with C++: it seems you agree with me. Only, I wouldn't say it's "irony", it's just a normal way the things are. It would be surprising if it were different. And wouldn't it be a great shame if you weren't a programmer today, just because C++ knocked you over one time too much when you were fragile? For example, you wouldn't have this discussion with me. :-F

I realized that learning to program isn't necessarily trivial and that it requires a good bit of self-study and hard work.

Absolutely! But if you face the same circumstances on your first encounter with programming, that's not the lesson you will extract from it. Trust me, I've seen it (I teach many young people programming, usually using languages I didn't choose -- as you probably realized by now.) C++ has the highest "screw this, programming is just not for me" rate. (I'm sure Malbolge would have even higher one, but no school in my vicinity starts with that.;))

I'm biased because I like to think at a low level.

I hope I showed you that "low level" is very relative. I've seen people telling other people things like "Yeah, Django is very nice, but I like to think at a low level, how the Python beneath it actually executes -- it really helps me in my work." :-D

Yes, I see where you're coming from, but I must regretfully inform you that most of the things you've learned are by now false or at least obsolete. L1 cache is more important than registers, vectorized operations are a thing, execution is not sequential, memory access is not atomic, processors actually use quantum effects when executing some instructions, and ALUs do speculate about what's going to come next, being at some points more superstitious than my grandma. :-P

Low-level thinking might be useful when it is correct. With modern advances in technology, it's less and less so.

In the long term, it's probably safe to continue using the term "reference" in JavaScript because it's become idiomatic. Plus, it is, as you say, a natural way to talk about objects—a variable "refers to" an object in memory.

That's all I wanted you to admit. But in the meantime we've opened a bunch of other subjects... :-D

Actually, it's not. In pass by reference, the formal parameter is a "true" reference (alias). Hence the name (and behavior) of pass by reference.

I understand that. I just hoped I could avoid this line of discussion since JS is neither. (Yes, it is pass by value if you redefine value, but I hope I have explained why I think it's unsatisfactory.) We don't pass values, and we don't pass references. We pass objects themselves. It's just a false dilemma (from my perspective, though I understand yours).

Most modern programming languages (save for C++ and PHP, for example) don't have true references (aliases), and hence they do not have any notion of pass by reference.

... and so the notion is finally free to be used in the true linguistical sense. Horray! :-)

Java programmers, when taught that there are these two ways of passing things into functions

So the solution is simple: don't teach it to them. :-) In fact, you can teach it to them using the true notion of reference. In Java, you can say truthfully that primitives are passed by value, and objects are passed by reference -- it will only confuse them if they heard from some C++ programmers that "reference" means "alias". But I'm sure no-one would do that to poor Java programmers. :-]

I've never implemented a language, or examined a language's implementation,

Hm, interesting. For a low level thinker, that's really strange. May I suggest you do that sometime? I think it will be a fulfilling experience. :-) I teach a course on compiler/interpreter design, but unfortunately it's in Croatian. I'm sure you can find decent ones in your preferred language. (If you want tips, Appel cs.princeton.edu/~appel/modern/ is really good, though verbose.)

Pointers are not just a "C thing"—they exist at the assembly level, where a pointer is literally a CPU register that happens to store a memory address (which is a number like any other).

Ah, in that sense, of course. Though even that's not a given: some early versions of Fortran had no dynamic memory allocation at all. Everything was static, and so could run directly from memory. Yes, you lose various niceties like recursion (you can't have a stack without indirection, of course), and functions could call other functions only to the depth of two:-), but people actually programmed in that monstrosity 50 years ago. (I'm sure someone will say that sentence for C in 50 years.:)

And about strings: do learn about Hollerith constants some time. Loaded directly from the source, together with the length, statically. Beautiful stuff. :-D There are more things in heaven and Earth, Horatio, Than are dreamt of in your philosophy. ;-)

Aleksandr Hovhannisyan

Absolutely! But if you face the same circumstances on your first encounter with programming, that's not the lesson you will extract from it. Trust me, I've seen it (I teach many young people programming, usually using languages I didn't choose -- as you probably realized by now.)

I trust you. I wrote my professor an email the first semester we had to use C++, in which I complained about its complexity and asked why we couldn't just continue using Java. It's all pretty funny in retrospect, lol...

Hm, interesting. For a low level thinker, that's really strange. May I suggest you do that sometime?

What's mainly held me back is my fear of taking on such a daunting task :D Which I guess means I can relate to beginners more than I think.

And about strings: do learn about Hollerith constants some time. Loaded directly from the source, together with the length, statically. Beautiful stuff. :-D There are more things in heaven and Earth, Horatio, Than are dreamt of in your philosophy. ;-)

Wow, that's... actually pretty cool! I didn't even think that you could do that. After you mentioned this, I read a bit about it on the Wiki for Fortran and here. So basically the identifier/variable name would itself contain all information necessary for printing/using that string? If I understood that correctly, that's pretty clever.

Vedran Čačić

So, it seems we agree on everything after all. How nice. :-D

About that compiler course... I didn't tell you the most important thing. I teach it using Python (and a little framework of mine, just to do bureaucratic tasks like counting lines and characters for nice error messages, and buffering characters and tokens in case you want to go back in the stream). That's the only way I can produce a working compiler in 20 hours. And that's why I told you there are no pointers in it. (Yes, we use CPython, so there are pointers in the implementation of Python, but as you said, if you just mean "indirect access to memory", it's bound to appear somewhere down the ladder of abstraction. The point (yeah, bad pun:) is that there are no pointers in the source language, no pointers in the target language (we mostly compile expressions to some stack-based VM, and transpile commands to things like JS, which is pretty much the universal architecture nowadays -- se webassembly;), and no pointers in the implementation language. The people writing those certainly don't think in terms of pointers.

Of course, being a low level thinker, you'll probably say it's cheating, and you'd want to use C++ as implementation language, and (if I estimated your age correctly) something like x86 as the target. But my perspective is that you'll just spend more time (and increase the risk of giving up) while not learning anything essentially new. "I guess it depends on what type of thinker you are and what you enjoy in programming.", as you said. :-)

Wow, that's... actually pretty cool! I didn't even think that you could do that.

As they say, necessity is the mother of invention. You don't know you can do many things (like survive 4 days without food) until you have to. ;-) BTW both things (surviving 4 days without food and using Hollerith constants regularly) are extremely bad for your health. There are good reasons we don't do them anymore. Kids, don't do this at home. ;-)

Aleksandr Hovhannisyan

and (if I estimated your age correctly) something like x86 as the target

Idk if that's a good thing or a bad thing :D

(I'm 21.)

Vedran Čačić

Youth is neither good nor bad---at least that's something we old farts say to each other for consolation. ;-)

x86, on the other hand, is mostly obsolete, but that shouldn't necessarily stop you---since your aim is not to produce something useful, but to understand things better.

Evan Bacon

😳 0/3!! 😳

But I tried my hardest and i also had fun. Thanks you Ms. @theavocoder! 🙏

Eugene Karataev

3/3!
Thanks for the quiz and explanations. I really like your quizes and articles!
As mentioned in comments, references, pointers, memory addresses might be little bit confusing. That's why I like Dan Abramov's JustJavascript course which explains things little bit differently. He creates robust and thoughtful mental model of things happening in JS. Just variables, values and wires between them 🙂

Mateus Moura Forte • Edited

I didn't know about the difference between bind and call, actually I've never used call ,just bind. But know I've some idea how it work xD thanks a lot
Make more quizzes like this, plx

Saqib Ameen

2/3!

I totally loved it @theavocoder! I always get confused b/w function.prototype.call and function.prototype.bind hence, I got it wrong! But hopefully, it will help me remember for the next time.

Also, an amazing way of teaching via clear GIF explanations. Wonder how did you make them? Found super helpful in understanding.

Keep 'em coming! 🙌

aRtoo

Again your the hero that we dont need but we deserved!! GOAT!!

Vaibhav Khulbe

My score: 1/3. I think that's expected, I have construction going on right now at home...always great explanation like every time!

Keep them coming! 💪

Lydia Hallie

Nice! 🎉 And thanks!

grimeting

👋, where can i find congratz-canvas snippet?

Danni • Edited

Hi Lydia! Just dropping by to say that your quiz is fantastic, and I can't wait to see the next parts. Amazing job ❤️❤️

JavaScript Joel

Hey, I'm diggin these little quizes. Great content! 🍻

Hi @lydia,

What did you used to your GIF animations/illustrations?

Kostas Minaidis

Hey, hey, confettis FTW! Nice work Lydia.

It reminds me of some old exercises I've set up for DOM selection using JS. I've added some sound effects to spice up the game a bit. :)

Still remains under development: codepen.io/kostasx/pen/WLmdwe

Thank you for all the work that you put in making these concepts as comprehensible as possible.

Keep it up!

yopopard

3/3 :)
Thanks !
What do you use for creating your animated explanations ?

Sams Ameen

Can I just say thanks @lydiahallie . I like your visual concept and one thing I find particularly interesting about this quiz is your use of 'let' and 'const' where it really matters.

Simon Holdorf

i like da postz

Lydia Hallie

thankz 😃

Andra Gugu

Hey, what do you use for the animations?

Gaziz

0/1🤔 thank a lot. I had fun. Wait more. 👨‍💻

I'm Luis! \^-^/

0/3 and I've built so many things with Javascript! So if someone else got a 0, worry not. Or maybe I should worry.

Aus G

Regarding question #1, I really need to sit down and read more about those call() and bind() functions, they are new to me.

Alfonsan

Nice work! Keep with it!

chustedde

3/3! 😊 I really liked this - a good chance to think about some CS concepts I learned in other languages and how they apply to Javascript!

Sumedh Nimkarde

Thanks for the awesome content! Looking forward to see more of these here on DEV! 😉

Julian David

2/3, la última me puso a dudar.