As a front-end engineer who deals with web pages every day, it is quite reasonable to be familiar with the use of DevTools. Whenever there is an issue with an API, I just press the shortcut to open DevTools, switch to the Network tab, find the red line, right-click to copy it as cURL, and paste it into the group chat for the backend team to troubleshoot.
But I wonder if anyone has encountered situations where DevTools are not sufficient. What should we do then?
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.
As a front-end engineer, it is natural to know a lot about front-end-related knowledge, such as HTML or JS-related things, but those knowledge is usually related to “use”. For example, I know that when writing HTML, I should be semantic and use the correct tags; I know how to use JS. However, some knowledge related to web pages, although related to web pages, is not something that front-end engineers usually come into contact with.
What I mean by “some knowledge” actually refers to “knowledge related to information security”. Some concepts commonly found in information security, although related to web pages, are things that we are not familiar with, and I think understanding these is actually very important. Because you must know how to attack in order to defend, you must first understand the attack methods and principles before you know how to defend against these attacks.
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:
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.
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.
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:
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.
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:
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.