In the past, when I wanted to deploy a simple service, I would go to Heroku because it was simple and free, although there were some usage restrictions, overall it was very convenient, and there were even some simple databases available. For static web pages, I would choose Netlify or GitHub Pages, both of which are simple and convenient options.

However, Heroku stopped offering free plans after the end of 2022, so many people were looking for alternative solutions, including Render or fly[dot]io, which became popular choices for many. I used to have three or four projects on Heroku myself, but after the changes at Heroku, I never touched them again.

Recently, I received an email from the founder of Zeabur hoping to collaborate with me to promote this platform. After trying it out myself, I found the experience to be quite good, so I decided to write this article to introduce it.

Read More

Introduction

If you want to store something in the front-end of a website, which means storing it in the browser, there are basically a few options:

1. Cookie
2. LocalStorage
3. SessionStorage
4. IndexedDB
5. Web SQL

The last two are rarely used, and the last one, Web SQL, was declared deprecated a few years ago. Therefore, when it comes to storing data, most people mention the first three, with the first two being the most commonly used.

After all, when storing data in the front-end, most data is expected to be stored for a period of time, and cookies and localStorage are designed for this purpose. However, sessionStorage is not, as it is only suitable for storing very short-term data.

I don’t know if your understanding of sessionStorage is the same as mine, so let me explain my understanding:

The biggest difference between sessionStorage and localStorage is that the former only exists in one tab. When you close the tab, the data is cleared, so a new tab will have a new sessionStorage, and different tabs will not share the same sessionStorage. However, if it is the same website, the same localStorage can be shared.

But let me ask you this: Is it possible that in a certain scenario, I store something in sessionStorage in tab A, and then a new tab B can also read the sessionStorage in tab A?

You might think it’s impossible, and I used to think so too, as did my colleagues.

But it turns out that it is possible.

Read More

Preface

I wrote this article because I believe that many people have encountered this problem. In summary, when using console.log to print an object, the printed value is different from what you expected. Let’s take a look at the code below:

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

This is a series of three articles that I call the Session and Cookie Trilogy. The goal of the series is to discuss this classic topic from shallow to deep, from understanding concepts to understanding implementation methods. This is the last article in the series, and the complete links to the three articles are as follows:

1. Plain Talk on Session and Cookie: Starting with Running a Grocery Store
2. Shallow Talk on Session and Cookie: Let’s Read RFC Together
3. In-depth Session and Cookie: Implementation in Express, PHP, and Rails

The first article talks about Session and Cookie in plain language without too many technical terms. The second article directly looks at the three RFCs of Cookie to understand what Session is, and also supplements some knowledge related to Cookie. This article will delve into Session and take a look at three different Session implementation methods.

These three are Node.js Web framework Express, PHP, and Ruby on Rails. I chose these three because their implementation of Session mechanism is different, and I think they are suitable objects for reference.

Read More

Introduction

This is a series of three articles, which I call the “Session and Cookie Trilogy”. The goal of this series is to discuss this classic topic from shallow to deep, from understanding concepts to understanding implementation methods. This is the second article in the series, and the complete links to the three articles are as follows:

1. Plain Talk on Session and Cookie: Starting with Running a Grocery Store
2. A Brief Discussion on Session and Cookie: Reading RFC Together
3. In-depth Session and Cookie: Implementation in Express, PHP, and Rails

Read More

Introduction

There are many HTTP Status Codes that we are all familiar with, such as 404 Not Found, 500 Internal Server Error, and 200 OK, among others.

Among the many status codes, there is one that is clearly meant to be humorous: 418 I’m a teapot.

But did you know that it is not part of the HTTP standard, so it is not a standard HTTP status code? You might say, “I’ve read the RFC, how can it not be?” But that RFC has nothing to do with HTTP, and many people have not noticed this.

I didn’t notice this at first either, and I thought 418 was part of the HTTP standard until someone posted an issue on Node.js’s GitHub in August 2017: 418 I’m A Teapot.

The issue mentioned that they wanted to remove support for 418, and when the author of the issue was told that Go was doing the same thing, they also posted an issue on Go.

At the time, the request to remove the 418 status code actually caused quite a stir, and most people were actually against removing this status code. There was even a save418.com created to try to save 418.

Recently, I spent some time studying the whole thing, and in the process of organizing it, I found that whether you are for or against it, the reasons behind it are worth thinking about, so I summarized it into an article to share with everyone.

Read More

Preface

A few weeks ago, I encountered some problems related to cookies at work. Before that, I thought to myself: “Cookies are just like that. Even if some attributes are not familiar, just search for information online. There are no difficult problems related to cookies, right?”

However, the fact proved me wrong. I really encountered a cookie problem that took me a long time to solve.

I believe that many people are eager to try it when they see this. So let me ask you first:

Under what circumstances will cookies not be written?

Obvious syntax errors don’t need to be mentioned. In addition to this, you may answer: writing cookies for a completely different domain. For example, your webpage is on http://a.com, but you insist on writing cookies for http://b.com. Of course, cookies cannot be written in this situation.

Or, you may answer: adding the Secure flag to cookies that are not on https. Yes, cookies in this situation cannot be written either.

Can you think of anything else?

If you can’t think of anything, let me tell you!

Read More

Preface

Recently, I was researching some things related to HTTP Cache, and I found myself confused by the different headers such as Pragma, Cache-Control, Etag, Last-Modified, Expires, etc. After reading many reference materials, I gained a deeper understanding. I thought that if I could understand Cache from a different perspective, it might be easier to understand what these headers are doing.

In the previous research materials, many articles explained the functions and parameters of each header one by one. However, I think that too many parameters can easily confuse beginners. Therefore, this article attempts to guide the usage scenarios and purposes of each header step by step through different questions. Also, because this article is for beginners, not all parameters will be discussed.

In fact, there are different opinions on Cache on the Internet. If there are any doubts, I will try to follow the standards written in the RFC. If there are any errors, please correct me. Thank you.

Read More