Retrospection of Udacity Intermediate JS Nanodegree

With Some Regrets

9 min readJul 9, 2021

Link to Course Page / Reading this article in Korean

I joined Udacity’s Intermedia javascript Nanodegree program on April 3rd, 2021, and finished it on June 20th, 2021. The first part took not so long, only about a week, so I thought, “Hmm, this will be easy to finish. Maybe I can finish it in 3 weeks?” Unfortunately, that was a very naive thought. As time goes by, other fun things (books that are not related to the work, drinking, etc.) keeps distracting me from focusing on the course, so it was barely possible to finish the course two days before the end of the term.

The most basic reason why I started to take the course was that my current company supports the fee (How simple!). However, I heard a little warning that the enterprise license paid to Udacity is quite high so please be careful about taking the course. I love this kind of word. If money relates, even though it’s not mine, that can provide you some degree of being productive.

The other reason is that I want to rethink the theoretical concepts of JS. This may sound like an excuse, but as I was busy closing the Github issues to keep the project up and running, I sometimes didn’t deep dive into the theory and obsessed with the due date. “I’ll recap it in the future!”— Nothing happens in the end. And if you keep involved in maintaining one project for more than a year and be used to the architecture, you can easily figure out where to fix or create without any deep thinking. That made me feel bad because I felt like I’m a perfectly tailored developer to this project. Without a specific framework or library, I wanted to have a lovely time with vanilla JS.

This program consists of three parts: Object-oriented Javascript, Functional Programming, and Asynchronous programming. All the code lines that I’ve seen in the past were helpful while taking the course. But while I was reminding of the code lines, I realized that the OOP concept was the thing that I didn’t encounter that much in work compare to FP or AP. In contrast, the FP & AP part was not hard to finish because I spent enough time with it during the work.

Inner Thoughts

Object-Oriented JS

I learned about OOP while studying Java at the university. Still, I didn’t really have a chance to actually apply this paradigm to JS in work, especially using or tweaking ‘prototype’ directly or applying the mixin pattern. So I just made modular function React components(i.e., route, container, elements, etc.) on the front-end side and combine them.

JS books talk about OOP a lot, I didn’t actually see that much in the codebase from work, so I’ve been rethinking about the relationship between ‘the concept, which is easy to be confused and a great topic to be discussed in a book or a lecture’ and ‘the concept which actually being used a lot in the real work.’ Or, maybe because I was in the part that uses external npm libraries to implement the user end web services rapidly. I don’t know. But at least I saw module patterns quite a lot.

For me, the prototype was hard to understand at first because it said that OOP in JS could be implemented using the prototype, and this prototype-based language is different from class-based languages like Java, but, nowadays, you can use a class in JS, thanks to the improvement of specification. Oh, by the way, be careful because the class in JS is the syntactic sugar of a prototype with some differences! So I could not be relieved at any steps of the thinking process and kept anxious about what would be the next obstacle. In the past, it was a little bit hard to understand why people who used to using Python, C, C++, or Java attack JS cuttingly, but now I can understand.

Sometimes, I don’t get the meaning of doing object-oriented programming with JS which is made of objects except for primitive values. It sounds like I’m doing programmer-oriented training to be a programmer even though I’m already a programmer. Okay, enough complaints.

When I was reading Kyle Simpson’s ‘You Don’t Know JS — This & Object Prototype,’ from the early part of Ch6, there’s a paragraph:

It’s a common reaction at this point to wonder why it has to be so complex to do something seemingly so simple. Now that we’ve pulled back the curtain and seen just how dirty it all gets, it’s not a surprise that most JS developers never dive this deep, and instead relegate such mess to a “class” library to handle it for them.

So he bravely dives into the world of prototypes. Chapter 4 & 5 explains how the developers suffered from OOP JS, and chapter 6 teaches us about how to think in a JS’s object prototype way. I couldn’t understand why he refused to apply the way of thinking about other OOP languages to JS when I first read this book two years ago, but I’m relieved that I am now slowly starting to understand the argument.

It is important to think about the difference between class-based inheritance and prototype-based inheritance. The biggest difference is that whether it is possible to extend the property during the runtime or not. It is possible in prototype-based inheritance, so it has a high possibility of confusion if any unpredictable extension happens. But I would not say it is good evidence for treating prototype as a root of evil because you can get architectural flexibility.

When you study OOP in JS, maybe this way of thinking can be helpful to keep on track: people from other countries, mainly from class-based language countries keep bringing in some of their familiar concepts to JS specification.

Immutable Data Structure

I swear I took the data structure class in my sophomore year but cannot remember the immutable data structure. Maybe I was not interested in the ds at that time. (Now you can see the harmfulness when you’re taking an uninterested class.) In the functional programming section, there’s an explanation about the Immutable.js library, and it includes the pros of immutable data structure, but I couldn’t fully understand why it is good.

For making up for my ignorance, I did show a video of JSConf about functional programming by Anjana Vakil and published an article by dictating the video content into text. I like her friendly way of talking. While we exchanged emails to get an approval of translation, she kindly suggested tweeting about my article and asked me if I have a tweeter handle. Unfortunately, I don’t, but I already appreciated the approval. Recently she recorded a workshop video about FP, and you can see it on FE Masters.

Task Queue: Macro & Micro

You cannot talk about asynchronous programming without mentioning the event loop. But the jargon was floating around my brain. There is a task queue, and the timings when a general synchronous code, setTimeout, or promise differ from each other. That’s it. That is what I knew. If you see the presentation slide or articles about the event loop, it’s often presented as the infinity symbol(∞) because it’s literally endless. However, I didn’t know that “macrotask queue” and “microtask queue” serve different roles. (I recently googled for DSLR lens, so ‘macro’ and ‘micro’ were not hard to understand, though.)

The microtask queue deals with promise(or async & await) tasks while the macrotask queue deals with the whole tasks except the promise ones. When the JS engine’s call stack is empty, the oldest task(i.e: script) in the macrotask queue executes, the microtask queue runs all its tasks, a task in the microtask queue finishes and the browser renders its content. The event loop iterates this process infinitely. More detailed explanations can be found on the Javascript.info site. Personally, I love this site because of its elegant explanation of the tricky JS concepts.

Promise & Async/Await Usage

I had a weird stereotype of ‘it looks just bad if you mix Promise with async/await in the codebase. Be consistent,’ which makes me stick to use async/await only. Sometimes, however, it looks okay and even better at controlling the flow. For example, if you need to deal with ‘resolve’ or ‘reject’ in the middle of the code blocks, then Promise will be a better choice. Being so stiff is not helpful in this case, too.

Things I used in Projects

HTML details & summary element: I once saw an article about making a modal component using those two elements from a dev newsletter, like this. In the second project, I wanted to make a full-page image gallery with a modal, and this article came up in my mind, so I used those two elements. The implementation was so convenient. (One big caveat: IE doesn’t support those.)
JS Modules: There’s a need to organize JS files in a modular way, but I was too lazy to set up webpack, babel, or whatever for bundling. I used script tag with module type attribute to include those modules in my index.html file. MDN provides great documentation.
Fetch API: I was also lazy to set up any packages or tools for fetching API, so I just used native fetch API. IE doesn’t support this, too. According to MDN, the difference between XMLHttpRequest and Fetch API is that Fetch API “provides a better alternative that can be easily used with other technologies such as Service Workers.”

Others

What I Liked

When you submit a project, you get feedback and pass or fail results. The feedback was quite helpful, and the response time was swift. I always did the project on the weekends, but the reviewer submits the feedback no later than one hour. The project rubrics are also very clear, so there’s no need to spend time to figure out what the reviewer really wants to see in my project.
Between the lectures, there are many quizzes and a final project, so it’s a more efficient way of learning programming rather than just reading the book and doing some projects by yourself. Therefore, I recommend this course to someone who doesn’t want to spend much time thinking about making it a practice.
Each chapter consists of videos and text for summarization on one page, so it’s less distractive than going back and forth between the presentation slide and videos.

What I Didn’t Like

It seems like typos are more easily found in the latter parts compared to the very first part. I submitted some typos to the feedback system but still doesn’t get any responses. I hope the other more popular nanodegree programs have fewer typos.

Tips

Nanodegree programs are always on sale. Do not rush to enroll when you see something like “75% discount” on the course page. Those events always come back.
If you get stuck while doing the project, go to the project template Github repo and refer to the issues opened by other students in the past. There’s some outdated code on the repo. If you’re used to fixing them, it’s okay, but some might take a while to figure the solution by themselves.
I saw a post on Reddit that the nanodegree fee is rising continuously, but the scope of student support is shrinking. Other MOOC services or online programming learning platforms offer similar kinds of lectures, so I’m not sure if it’s still worth taking the course even when the fee is higher than the budget. But if you want to get 1:1 feedback from the projects, then maybe this course might be better than other platforms which don’t support feedbacks.
There’s an estimated learning time written on each module, but please multiply about 1.5 to the written time and think of it as real-time to complete the module when it is a new subject to you.

Closing

I didn’t fully commit my 3 months to the course, but it was a great opportunity to reflect on the concepts I haven’t thought about deeply. I recommend this program to people who want to spend time like me! Happy coding 👩‍💻✨