Introduction

First, let’s briefly introduce what an Online Judge (OJ) system is. Simply put, it is a system like LeetCode that allows you to submit code for problem-solving and then lets the system check it and give you the final result. Below is a screenshot of LeetCode:

Before LeetCode became popular, the most well-known OJ was probably UVa Online Judge, also known as ACM. In Taiwan, ZeroJudge is more famous.

If you happen to have a need and want to build your own OJ, what should you do?

Read More

Introduction

In two of my previous articles, I Know You Understand Hoisting, But Do You Really Understand It? and All Functions Are Closures: Discussing Scope and Closure in JS, I talked about the differences between the scopes of let and var.

The scope of let is block, while var is function. This is a classic example:

for(var i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

It was originally expected to output 1 to 10 in order, but unexpectedly output 10 11s. The reason behind this is that the i on the third line always has only one, which is the var i declared in the for loop, and it is the same variable from beginning to end.

The classic solution is also very simple, just change var to let:

for(let i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

The reason why this works is that the above code can be seen as the following form:

{
 let i=1
 setTimeout(function() {
    console.log(i)
  })
}

{
 let i=2
 setTimeout(function() {
    console.log(i)
  })
}

...

{
 let i=10
 setTimeout(function() {
    console.log(i)
  })
}

Since the scope of let is block, there is actually a new i in each round of the loop, so there are 10 different i after the loop runs 10 times, and of course, 10 different numbers are output in the end.

Therefore, the biggest difference between var and let in this example is the number of variables, the former has only one, while the latter has 10.

Okay, now that you know the difference between let and var, let’s take a look at the main issue of this article.

In fact, this issue comes from a question raised by @getify, the author of YDKJS (You Don’t Know JS), on his Twitter:

question for JS engines devs…
is there an optimization in place for this kind of code?

for (let i = 0; i < 10; i++) {
  // no closure
}

IOW, where the behavior of creating a new i per iteration is not needed nor observable… does JS skip doing it?

If you didn’t understand it very well, you can continue to read the other tweet:

here’s a variation on the question… will JS engines exhibit much performance difference between these two loops?

for (var i = 0; i < 100000000; i++) {
   // do some stuff, but not closure
}

for (let i = 0; i < 100000000; i++) {
   // do the same stuff (no closure)
}

Simply put, when we usually use let with loops, isn’t it like we said above, there will be a new i in each round? If so, then there should be a performance difference between var and let, because let must new a new variable in each round, so let will be slower.

If the loop does not need a new i in each round, will the JS engine optimize it? This issue is mainly to explore whether the JS engine will optimize this behavior.

So how do we know? Either you are a JS engine developer, or you can look at the JS bytecode, but both of these difficulties are a bit too high. But don’t worry, there is a third way: look at the JS bytecode.

Read More

Introduction

In my blog, there are actually few tool-related tutorial articles. One reason is that these tool-related articles are all similar, and the other reason is that I am lazy and many step-by-step tutorials require detailed descriptions and rich screenshots, which is not suitable for me.

But this time I decided to write this topic because I think webpack is a tool that beginners are not easy to understand, and even if they understand it, they may not really understand it. In other words, it is a tool that is often misunderstood.

This is not a problem with webpack itself, but many beginners now start with React or Vue directly in front-end development, and they all use the CLI tools provided by them. When they need to customize some settings, they will notice: “Oh, there is a thing called webpack.”

CLI tools bring convenience, and the advantage is that beginners can quickly get started without worrying about those cumbersome settings; the disadvantage is that if beginners are not aware of the tools behind them, when the tools are broken, cannot be used, or need to be modified somewhere, it will be the beginning of a nightmare.

In order to reduce this situation, I decided to write this article, hoping to introduce everyone to the concept of webpack and modularity from the source. You must first know what a module is to understand what webpack is.

At the beginning, I want to let everyone think about their familiarity with modularity and webpack through a few questions:

1. Why do many projects (such as React) need to be built before deployment? What is this step doing?
2. Do you know the difference between require/module.exports and import/export?
3. Do you know that these two syntaxes of import and export cannot be used casually on the browser?
4. Do you know why to use webpack?
5. Do you know why webpack needs a loader?

These questions should inspire you a little bit while reading this article, and I will answer them for you at the end.

Read More

Introduction

I have always recommended a course called CS50 because it is deep, broad, and taught in a clear and concise manner. The assignments are also solid, making it an excellent course.

The course I am introducing today can be described as the “CS50 of computer hardware.”

From Nand to Tetris was created by two professors, Shimon Schocken and Noam Nisan. Like CS50, it was originally a university course that later became an online course. The course has a subtitle on its official website: “Building a Modern Computer From First Principles.” Yes, you will build a computer.

The course is divided into two parts. Part 1 is From Nand to HACK. Nand is the name of a logic gate, just like Or, And, and Xor. HACK is the computer that will be built at the end of Part 1. Therefore, Part 1 will take you from the most basic logic gate and gradually build a computer. This part is heavily focused on hardware.

Part 2 is From HACK to Tetris, which extends from the computer to software. It covers topics such as compilers and operating systems.

Read More

Introduction

Recently, the second edition of YDKJS (You Don’t Know JS) was released, called YDKJSY, where Y stands for Yet. Although the second edition is not yet complete, some of the initial chapters have already been made available on GitHub.

I read the first chapter, which talks about the history of JS. It mentioned an interesting issue:

As such, sometimes the JS engines will refuse to conform to a specification-dictated change because it would break that web content.

In these cases, often TC39 will backtrack and simply choose to conform the specification to the reality of the web. For example, TC39 planned to add a contains(..) method for Arrays, but it was found that this name conflicted with old JS frameworks still in use on some sites, so they changed the name to a non-conflicting includes(..). The same happened with a comedic/tragic JS community crisis dubbed “smooshgate”, where the planned flatten(..) method was eventually renamed flat(..).

In summary, it means that sometimes the JS specification must compromise with reality (existing old implementations). For example, the Array was originally supposed to add a method called contains, but it was changed to includes due to issues. Flatten was also renamed to flat.

There is also a term “smooshgate” that was specially marked above. When searching for this keyword, it was found that it was an event that occurred around March last year, related to the aforementioned flatten. When I saw this, my first reaction was, “Huh, why don’t I know anything?” After searching for information in Traditional Chinese, I found only this article that mentioned it: SmooshGate and this article that only touched on it: [Note] 3 types of JavaScript object property characteristics.

After carefully studying the origin and development of the matter, I found it to be an interesting topic, so I wrote this article to share it with everyone.

Read More

Introduction

In the past few years, “problem-solving” seems to have become a trend. When students majoring in computer science go for interviews with big companies, they are required to solve problems. Even non-computer science students are expected to solve problems during interviews. It seems that if you don’t solve problems, you will fall behind others and be eliminated by the company.

Actually, I have never been fond of the term “problem-solving”, mainly because of the word “solving”. I don’t know how you interpret this word, but I feel that there is a sense of “solving problems just for the sake of solving problems”, just like the tactic of solving a lot of problems. Although this tactic can be effective if used properly, I always feel that many people will end up with the mentality of “I can solve the problems I have seen, but I can’t solve the ones I haven’t seen”. If that’s the case, I don’t think it’s a good thing.

I have written an article before: What should we learn when we are learning to code?, which briefly discusses this issue.

In short, I prefer to use the phrase “programming problem-solving” to express what I want to say, rather than the term “problem-solving”.

Read More

Introduction

If there is one concept in JavaScript that is important and commonly used but often confused by beginners, it is undoubtedly “Asynchronous”. Compared to other concepts such as this, closure, prototype, or hoisting, asynchronous is used much more frequently in practical development and is often a pitfall for beginners.

Is asynchronous really that difficult?

I don’t think so. As long as you follow a correct context, you can gradually understand why asynchronous is needed and how it is handled in JavaScript.

I actually wrote about a similar topic four years ago, but looking back now, it was not well written. Therefore, four years later, I am revisiting this topic and hoping to write a better quality article to clarify the concept of asynchronous.

Before writing this article, I referred to the official documentation of Node.js and found that it actually explains asynchronous quite well. Therefore, this article will start with a similar approach to discuss this issue. If you don’t know Node.js, it’s okay, I will provide a brief introduction below.

It is recommended that you have a basic understanding of JavaScript, know how to use JavaScript to manipulate the DOM, and know what ajax is before reading this article.

Let’s get started!

Read More

About a year ago, I directly put my blog on GitHub Issues. Although few people in Taiwan do this, many Chinese developers use this method to build their blogs.

The reason why I chose GitHub Issues at that time was simple: convenience.

1. GitHub Issues perfectly supports Markdown syntax.
2. Uploading images is super easy.
3. When someone mentions your article using Issues, a reference will be automatically generated.
4. The comment system is super convenient.
5. You can use emojis.
6. You can watch the GitHub repo to receive notifications when it is updated.

In summary, I chose GitHub Issues at that time.

However, I recently discovered a big problem that I didn’t pay attention to at the beginning, which is that the SEO of GitHub Issues is extremely poor. Even if you directly search for the title of an issue on Google, you may not be able to find it.

Because this problem is quite serious, I finally moved back to Hexo.

Actually, two years ago, I had already moved my blog once, from Logdown to Hexo. But at that time, I didn’t continue to use Hexo because I thought the layout of that blog was not very good-looking.

And this time, the reason why I moved back was largely because I saw Askie Lin‘s blog. When I saw it, I was amazed and thought, “Wow, this blog is also beautifully done!” Later, I found out that it was modified using the ready-made theme Minos, so I thought I could try to switch to this theme.

After a whole day of adjustments today, I fixed a lot of things myself and tried to make the layout look the way I wanted it to. I found it quite smooth. Maybe it’s because the original code was written well, and there were no major problems in fixing it. I only changed the font size and the display of categories and article lists, and didn’t do much else.

Unless there are any unexpected circumstances, I have decided to settle down here in the future, and use GitHub as a backup place for my articles.

Long live Hexo, long live Minos 🎉

Introduction

In recent years, front-end frameworks have been flourishing, and many beginners who have just learned JavaScript have directly learned the three major frameworks (although React is not a framework, the entire ecosystem is actually no different from the framework, so I think it can be classified as a framework).

These three major frameworks are usually used to write SPA (Single Page Application). I have always believed that some basic knowledge should be possessed before learning these frameworks, especially the understanding of front-end and back-end. Otherwise, you will definitely encounter many problems that you don’t know where to start.

Therefore, this article uses a problem that I have encountered myself and that students often come to ask me as an example. You can also think about whether you can answer this question:

Suppose I have an SPA, using a library of some routers to implement routing, so /list will go to the list page, and /about will go to the about me page.

But strange, when I uploaded the SPA to GitHub Pages, the homepage is good, and when I go to /list from the homepage, it is also good, but when I refresh /list, it shows 404 not found. Why is this?

To answer this question, you must first review some basic knowledge related to front-end and back-end networks.

Read More

(The original article was written on Medium, and I’m backing it up here.)

Although I have always been clear about my preferred learning methods and paths, and have turned what I think is suitable into a course outline for teaching, few people seem to look at that outline, and it does not explain the reasons behind it in detail. Therefore, I feel it is necessary to write this article to describe what I think is a “solid” front-end learning path.

Read More