V3: [JavaScript] Roadmap to Launch

[SleeplessByte]

This issue is to track the JavaScript v3 roadmap. If you intend to _help_ with this track, please read this entire document, and find the section about "How can you help".

---

I have been working on the JavaScript v3 track by compiling a list of JavaScript specific concepts, transition documents from various languages and starting writing exercises. The concepts can be found here. Important things are to consistently realise, mention and reiterate that JavaScript types do _not_ include "types" such as Array and Date. Prototype-based programming _is_ different than class-based programming.

Folder structure

Specifics for javascript concepts can be found in the /info folder. There are other special folders such as /keywords, which take the keyword, and explain what they do, as they are language-specific (mostly), and the /objects folder which would be /types in many other languages: it lists the global objects available.

Concept exercises

The concept exercises in the JavaScript track are a work-in-progress and can be found in /exercises/concept. Important _types_ of concepts to target are things that only exist in object-oriented programming (for people coming from non-oop languages), functions as a first class citizen (for people coming from non-functional languages), and javascript specifics:

• prototype based inheritance
• event loop
• sameness
• destructuring
• duck typing

It is important to understand we _never_ explain a specific type or syntax as a concept, but teach the more "abstract" concept around it, using the type(s) or syntax(is).

A list of exercises that we _must_ have is compiled below, and is not at all a complete list:

• [x] [/numbers][concept-numbers]: "numbers", "type-conversion"
• [x] [/strings][concept-strings]: "string"
• [x] [/promises][concept-promises]: "promises"
• [x] "arrays", "array-analysis", "array-transformations", "array-destructuring"
• [x] "booleans"
• [ ] "nullability"
• [ ] "errors"
• [x] "callbacks", "closures"
• [ ] "recursion"

⚠ Note ⚠: The idea here is to use a concept name for the folder, but perhaps use some sort of "progression", so they will naturally become a sort of path to traverse. In this example, the numbers exercise only teaches basic number usage, and doesn't look into more advanced subjects. I would expect to see

• numbers-advanced for mathy usage that is non-basic,
• numbers-irrational showing how to do irrational / complex / whatever numbers,
• numbers-precision which would explore binary representation and floating points,
• numbers-arbitrary-precision which would explore bigints and/or how to do that with decimals.

It's only important that it's reasonably easy to _find_ the exercise. It's okay if the name isn't perfect. We will iterate on this.

Concept interpretation

Here is how I've interpreted the following concept-keywords. This should be synced across tracks.

| concept | interpretation |
|----------|----------------|
| numbers | Know of the existence of the number type and (for this language) see that it's whole numbers, and floating points. Know of basic operators such as multiplication. Know where it's documented, or at least how to search for it. |
| strings | Know of the existence of the string type. Know of some basic functions (like looking up a character at a position, or slicing the string). Know where it's documented, or at least how to search for it. |
| promises | Know of the Promise construct (future type in some other languages), chain-ability, and .then. Know where it's documented/how to search. |
| arrays | Know of the Array construct (array type in some other languages). Know of some basic functions. |
| errors | Know how to create an error, how throw it and how to catch it |
| callbacks | Know how to use a function as a first-class citizen, that is, pass it into a function as a value, and call it somewhere inside that function. Know that you can pass in values and retrieve out return values. |
| recursion | Know how to call a function from itself |
| type-conversion | Know that there exist functions that can convert between "types" (objects of a prototype) and types (primitives). |

This also indicates that for example basic-strings does not include knowing that JavaScript strings aren't strings in the compsci sense as in, they are made up of UTF-16 codepoints, and therefore there are a lot of catches with this. basic-numbers does not talk about the % operator and how it's _remainder_ and not _modulo_, or the fact that binary operations on negative numbers are ... weird.

How can you help?

This track

There are files in the /info, /keywords and /objects folders which are either empty or stubs. They need to be written. You can use the already filled-in ones to see what we're looking for.

Globally

There are concepts missing.

Exercises

We need two types of exercises. The concept ones, as explained above -- you can chose to pick one from the list above or suggest, in this issue, one that's not listed. The other ones are the practise ones, which are like the v2 exercises.

Analyzers

TBD

[Calamari]

Do we also teach about async-await? Maybe in a more advanced promise concept exercise?

[paparomeo]

Regarding the callback concept: should we refer to it as "higher-order functions"? It feels as the broader concept, since a function as a first-class citizen goes beyond callbacks, although callbacks as an asynchronous programming mechanism certainly deserves to be treated as its own concept.

[paparomeo]

Asynchronous programming in JavaScript is probably one of the hardest concepts for beginners to grok. Would a general concept for asynchronous programming make sense divided into:

• asynchronous programming
  
  
  
  • async/await
  
  
  • promises
  
  
  • callbacks
  
  

Also async/await> simpler than promises > simpler than callbacks. Does it make sense to introduce it in that order, rather than how it historically evolved?

[Calamari]

I agree with @paparomeo about the difficulty of the concepts, and think it is a good idea to use that order.
I also think, that could apply well to classes as well. Since for most people it is easier to grasp what a class is than what prototype inheritance means. So in modern JS we might also first introduce the new concept class and in later exercises explain what it really transpiles to.

[Calamari]

@SleeplessByte I also have a question about those folders: What are they for? I mean what are the files in them being used for in v3? I think it would help to know, since I would not be sure what to write in them. Plus I would just link to MDN since there are pretty good explanation of (almost?) all of them.

[SleeplessByte]

re: @paparomeo @Calamari

_My commentary here is to be taken at face value. I absolutely am very delighted by the input by both of you. Please keep doing it ❤️ and don't read in-between the lines, because there is nothing there._

Considering callback vs hoc

higher-order functions is a way broader _and complex_ concept than a callback. In order to be able to use a callback (not pass in a callback), you absolutely don't need to understand functions are first-class citizens. It is important to differentiate, because there are languages where functions are _not_ first-class citizens. Some might have callbacks and no hocs, or vice-versa. This means I would want to split them out for people coming from those languages.

Do I want hoc as a concept-exercise: hell yeah :heart:, but it will be AND, not OR.

Asynchronous

In general I would love to see multiple concept exercises in the asynchronous space. I only created the promise exercise, because I had an idea for it. As listed in the road-map but also in the not so old README.md.old, there are subjects such as the event loop to consider. We will 💯 % not have a single async-concept exercise, as there is already a promise-concept exercise. The concept is just way too big. However, I'd love to see various practice-exercises using a-synchronicity.

So in short: yes, we'll have multiple concept exercises regarding async.

A few more comments:

• async/await is absolutely not simpler than Promise (or harder). It's an abstraction and imo a silly one at that. I wouldn't want to _order_ async/await before promise OR vice-versa, and we don't need to. The unlocks are a 🌲 tree, so we can have multiple "roads" to gain understanding in this particular part of the track.
• callbacks are not _necessarily_ , but I understand why you'd place them there. Many many forms of callbacks are synchronous, so this is maybe not the best place to put them. Across languages, support for callbacks is varied; think about subroutines, lambda expressions, blocks, or, as in we do here, function pointers.
• I think we want to have _less_ ordered-guidance, and only have prerequisite. A student should be able to choose for themselves which path they take, and we can give recommendations. You absolutely need to know about promise before you learn async/await, or we can't rely on the concept. You dont need to know about callback before you learn async/await, _unless that exercise uses callback_. Does that make sense?

Classes vs Prototype-inheritance

I also think, that could apply well to classes as well. Since for most people it is easier to grasp what a class is than what prototype inheritance means

But that's not what we'll be considering here. We're not ordering the track in a linear fashion, so we don't need to consider this at all. That said:

• _using_ the class keyword is easier than _understanding_ it's actually syntactic sugar for prototypal inheritance. Thinking that you're not using prototypes when you're using class is actually a (imo big) issue.
• I absolutely agree that we should have a concept exercise introducing classes and at least one but probably multiple about prototypal inheritance. However, I don't think there is necessarily a hierarchy in them.

So in modern JS we might also first introduce the new concept class and in later exercises explain what it really transpiles to.

Transpilation is specifically source-to-source transformation/compilation. This is important. The class keyword does not magically do this in JavaScript. It is only transpiled by a transpiler/compiler such as babel or tsc and only if the target is es5 or earlier.

Again, yes I agree that class is probably better to introduce before going "oh but AkCtUaHlLy it's prorotypes", but we're not making a linear path right now. So we don't need to think about ordering at all. Later, when we are defining the "pathways", this will become important and I'll gladly take your advice. However, that part of v3 is still in flux.

Folders

The folders' contents for JavaScript are to build a wiki-esque style information bank to be used by _us_, and so we can link and copy in our exercises to it. The information further up defines it on a language-agnostic level, whereas this is the JavaScript specifics.

Plus I would just link to MDN since there are pretty good explanation of (almost?) all of them.

We're not looking to create files to just link back to MDN, as this resource will live on the exercism repo's and sites. MDN has a lot of _valuable_ information, but also lacks quite a bit. See it as we're building a learning resource, whereas the information comes from our combined knowledge, and other sources such as javascript.info, MDN and wikipedia.

[paparomeo]

Thank you for the clarifications @SleeplessByte!