Front-end

Did you know that when you discuss SSR with your friends, it’s highly likely that your understanding of SSR differs? Let’s take a few scenarios. Which ones do you consider as SSR?

  1. Generating the view from the backend using PHP.
  2. Frontend is a React-based SPA, but if the backend detects a search engine, it switches to a different template that is specifically designed for search engines instead of the React-rendered page.
  3. Frontend is a React-based SPA, but it uses Prerender to render the page as HTML and then serves it to the search engine (regular users still get the SPA experience). The difference from the previous scenario is that the view seen by users and search engines is mostly the same.
  4. Frontend is a React-based SPA, and the backend uses renderToString to render React into a string, but there is no data. The data is fetched on the frontend.
  5. Frontend is a React-based SPA, and the backend makes API calls to fetch data for each page. After fetching the data, it calls renderToString to output HTML. On the client-side, hydration is performed to make the page interactive.

Some people believe that any view generated by the backend is considered SSR, so all scenarios 1 to 5 are SSR. Others think that the frontend must be an SPA for it to be called SSR, so scenarios 2 to 5 are SSR. Yet, some people consider hydration as the key aspect of SSR, so only scenario 5 (or 45) is SSR.

Read More

Some websites use GIFs for certain images because they are animated and appear more impressive than static images. Sometimes, the need for an animated image arises, such as in the case of stickers where animation is expected.

However, one of the well-known drawbacks of GIFs is their large file size. Especially on mobile devices with higher resolutions, larger images are required. Even if only a 52px image is displayed, a 156px image needs to be prepared, resulting in increased file size. In terms of web development, it is always better to have fewer and smaller resources to load.

Read More

Recently, there has been a series of discussions about Tailwind CSS on the Front-End Developers Taiwan Facebook group. The reason for this is another post that has been deleted. I have seen that post, but I won’t talk about what it was about because it’s not the focus of this article.

Anyway, that post sparked a lively discussion among front-end communities on Facebook, and many articles related to technology were quickly added within two or three days.

And many people are actually discussing the concept of Atomic CSS more than the tool Tailwind CSS.

Read More

If your website wants to experience new features that have not yet been officially launched by the browser, what should you do?

Usually, these features are already available, but not yet open. Therefore, browsers provide some flags that can be turned on and off. As long as the switch is turned on, you can experience the new features in advance. However, we usually cannot ask users to turn on the switch themselves.

Therefore, Chrome provides a mechanism called origin trials. You can register on the website to obtain a set of tokens. After setting it up, if the user visits your website with Chrome, the new feature will be turned on, allowing your website to use it.

This article will briefly introduce how to use this mechanism.

Read More

Although Same Site and Same Origin may seem similar, they are actually quite different. This difference affects how the browser perceives the relationship between these two websites and the permissions it grants.

This article will cover the following topics:

  1. What is Origin? What makes it Same Origin?
  2. What is Site? What makes it Same Site?
  3. What is the difference between Same Origin and Same Site?
  4. How to turn Same Site into Same Origin?

Without further ado, let’s get started!

(Before we begin, let’s answer a question. Yes, the title was inspired by the ninja Hattori.)

2022-01-20: Modified the “Examining Same Site” section to supplement the history of the scheme. Thanks to @littlegoodjack.

Read More

Introduction

I was recently tasked with generating a PDF report. There are many ways to create a PDF, such as using Word and then converting it to PDF. However, my first thought was to write it as a web page and then use the print function to convert it to PDF.

At my previous company, I saw a project that used JS to generate PDFs using PDFKit. While it had a high degree of flexibility, I found it difficult to maintain. The reason is that using this tool is like drawing a PDF, and you have to specify (x, y) coordinates to draw something. Changing a small part may require changing many lines of code.

At the time, I thought, why not just use the simplest HTML + CSS, cut the layout, and then convert it to PDF? If you don’t want to convert it manually, you can also use headless chrome to convert it. Because it is a web page, it should be easy to maintain. Moreover, because the layout is done using HTML and CSS, it should be much simpler than drawing.

It wasn’t until I later encountered web-to-PDF conversion that I realized things weren’t as simple as I thought.

Read More

Introduction

After writing CSS for a while, we should all be familiar with common properties such as display, position, padding, margin, border, background, etc. We can write them smoothly without having to look up anything.

These properties are common because they are used in many places. However, some CSS properties can only be used in specific places or under specific circumstances. I often forget these less commonly used properties, but they are actually very important in some cases.

Therefore, in this article, I want to introduce some CSS properties that I think are not easy to remember but are very useful. This is also a note for myself.

Read More

Introduction

Whenever I start a JavaScript-related project, my go-to setup is usually ESLint + Prettier. If you haven’t heard of them, let me briefly explain. Prettier is used to format your code, so you don’t have to argue with others about whether to add semicolons, whether to break { for if blocks, or how many characters per line. With Prettier, you let it decide (although there are configuration files you can adjust).

This is actually quite helpful for teams because it unifies the code format, and the basic coding style will be consistent. Although ESLint also has some formatting-related parts, it focuses more on best practices when writing code, such as declaring variables before using them and using const for variables that won’t change. This is beyond the scope of formatting.

Therefore, using ESLint with Prettier can ensure the minimum quality of the entire codebase, at least avoiding terrible formatting. The most common rule people use with ESLint is probably the Airbnb JavaScript Style Guide, which explains each rule in detail.

When I was writing code before, I suddenly thought of a place where ESLint might be suitable, so I tried it out and found that making a “usable” plugin was easier than I thought. This article records the process and experience.

Read More

Preface

This article has a little less technical content, and I would like to share with you the process of writing this series of articles and some thoughts after finishing it.

If you haven’t read this series of articles yet, the links are as follows:

Read More

Introduction

In the previous articles, we learned that the CORS protocol is essentially a security protocol. In addition to CORS, there are actually a series of things related to cross-origin, such as:

  1. CORB (Cross-Origin Read Blocking)
  2. CORP (Cross-Origin Resource Policy)
  3. COEP (Cross-Origin-Embedder-Policy)
  4. COOP (Cross-Origin-Opener-Policy)

Doesn’t just seeing this series of similar terms make you dizzy? Yes, me too. In the process of organizing this information, I found that the security issues related to cross-origin are more complicated than I thought, but after spending some time organizing them, I found that there is still a logical sequence to follow. Therefore, this article will explain why these things appear in a context that I think should be easier to understand.

In addition to the various COXX things mentioned above, there are other cross-origin related security issues that I want to mention in this article.

Before we continue, I would like to remind everyone that this article is about “security issues of cross-origin”, not just “security issues of CORS”. The things protected by the CORS protocol and their content have been introduced before. What this article is going to talk about is actually somewhat deviating from the main title “CORS” complete guide, because this is not very related to the CORS protocol, but rather raises the level again and talks about “cross-origin” itself.

So when you read the following things, don’t confuse them with CORS. Except for the first thing to be discussed later, the others are not very related to CORS.

Read More