Preface

Some time ago, I was looking into the knowledge points related to how to solve Ajax cross-origin problems arising from browser same-origin policy restrictions. However, when I was thinking about how to write an article to record these knowledge points, I found it very difficult to explain them clearly from an angle that ordinary people can easily understand, and it was even hard to give examples. Thinking back, this is normal. Ordinary people visiting websites do not easily encounter cross-origin problems directly, and most articles on the internet about cross-origin problems are written by front-end developers~~.

So, what is the browser same-origin policy? What is Ajax? Why does the same-origin policy lead to Ajax cross-origin access issues? Why is it always the front-end that encounters cross-origin issues? Thinking further, why and when did the distinction between front-end and back-end begin? ... Following this line of thought all the way, I found that all the above issues are closely related to Ajax. Therefore, in this article, I try to sort out the relationships among the concepts of ”Ajax”, ”same-origin policy”, and ”cross-origin” from a non-programmer's perspective (after all, I don't understand code and don't have a programmer's perspective~). It's quite challenging!

The Past and Present of Ajax

Web Pages Before the Popularization of Ajax

Before the popularization of Ajax, Web pages usually worked in a traditional synchronous request manner, which meant that when users interacted with the server, the entire page had to be reloaded. During that period, web pages basically obtained new data or refreshed content through links or form submissions: when a user clicked a link or submitted a form, the browser would send a request to the server, wait for the server's response, and then replace the entire page with the new content.

This synchronous request method had some obvious drawbacks, such as poor user experience and long loading times. In addition, this method also restricted developers from implementing more dynamic and interactive features in web pages.

At that time, web pages usually used static content and a small amount of JavaScript to achieve simple interactive effects, such as validating forms and popping up alert boxes. The content of the entire page was dynamically generated by the server, and the interaction between users and the server was mainly based on full page refreshes.

Also: Do you remember surfing the Internet many years ago, and frantically pressing the ”F5" key to refresh whenever there was a problem accessing a web page? That was because a full page refresh was required to see changes in the web page content.

The following content can be ignored by ordinary people; it is just content that I feel is necessary to record.

From a technical perspective, before the popularization of Ajax, the main methods to implement dynamic web page functions were as follows:

1. Full Page Reload

The most traditional method is that every time the page content needs to be updated, the entire page is reloaded. Although this method is simple, it is inefficient and offers a poor user experience. Every interaction requires the entire page to reload, resulting in long loading times and high server pressure.

2. Frames

Using HTML's <frame> 和 <iframe> tags, a web page can be divided into multiple independent parts (frames). Each frame can load and update content independently. Although this method can avoid refreshing the entire page, frame management is complex, and it is no longer popular in modern web page design.

3. Embedded Scripts

Use scripts embedded in HTML pages to dynamically update page content. For example, JavaScript can directly modify the content of DOM elements. This method is suitable for some simple dynamic updates, but cannot perform complex data interaction or communicate with the server.

4. Form Submission with Hidden Frames

By setting the target of the form to a hidden <iframe>, the form can be submitted and the response processed in the background without having to refresh the entire page. This method achieves asynchronous communication to some extent, but it is cumbersome to use and not as convenient as AJAX.

5. Server-Side Techniques

Using CGI (Common Gateway Interface) and other server-side scripts (such as Perl, PHP, ASP) to generate dynamic web page content, although dynamic content can be generated, each interaction still requires a page refresh.

6. JavaScript and Cookies

By manipulating cookies through JavaScript, some data can be stored on the client side to achieve limited dynamic functionality. For example, parts of the page content can be changed based on user choices. However, this method is also very limited and cannot perform complex data interaction.

7. Server Push and Long Polling

These techniques allow the server to push updated data to the client, but they are complex to implement. For example, long polling is a method of keeping an HTTP request open until the server has data to send, but this method puts pressure on server resources.

What is Ajax?

After all this talk, what exactly is Ajax?

Ajax (Asynchronous JavaScript and XML, translated as asynchronous JavaScript and XML) is a technology used for asynchronous requests and data interaction in web applications: ””It allows exchanging data with the server and updating parts of the page content without reloading the entire page. Ajax technology enables web pages to achieve more advanced interaction and dynamic effects by interacting with the server in the background.“”, which was a revolutionary change (though it took 7 to 8 years from its emergence to popularity) for traditional web pages at that time, which mainly displayed page content synchronously and required a full page refresh for dynamic content. Its core principle includes using JavaScript to initiate asynchronous requests (usually using the XMLHttpRequest object), interacting with the server, and processing the response in the background. This approach allows the page to interact with the server in the background without refreshing the entire page. At the same time, Ajax supports using XML or JSON format data in requests and responses, making data transmission more flexible and efficient.

Question: What is the relationship between JavaScript and Java?
Answer: Actually, there is no real relationship; they are just two different languages. If you absolutely have to find a connection, they share some similarities in core programming concepts and syntax. However, the main reason was to ride on the popularity of Java, because Java was very popular at that time, so it was named JavaScript (originally called Mocha, then LiveScript, and finally decided to be renamed JavaScript).

The Birth of Ajax

In 1996, Microsoft introduced the iframe in Internet Explorer 3, allowing web pages to communicate data in the background without refreshing the page. In 1999, Microsoft introduced the ActiveX object in Internet Explorer 5 XMLHTTP, which was the predecessor of modern AJAX technology.XMLHTTP object allows the browser to send and receive XML data in the background.

With the XMLHTTP introduction, other browser vendors (such as Mozilla Firefox and Safari) also began to support similar features, which eventually evolved into the standard XMLHttpRequest object. This laid the foundation for the popularization of AJAX technology.

In February 2005, Jesse James Garrett published an article titled "AJAX: A New Approach to Web Applications", proposing the concept of AJAX and naming it AJAX for the first time.

Note: AJAX is not a single technology, but a combination of several technologies:

1. JavaScript: Used to create asynchronous requests and process response data.
2. XMLHttpRequest: Used to communicate with the server in the background.
3. HTML/CSS: Used for the structure and style of the page.
4. XML/JSON: Used for data transmission and processing. Although XML is in the name, JSON is more commonly used because it is more lightweight and easier to parse.

Changes Brought by the Popularization of Ajax

The emergence of Ajax technology has greatly changed the way web applications are developed, providing users with a better experience, while also driving the emergence of more complex interactions and dynamic effects in front-end development, which can be summarized as follows:

1. Improvement of User Experience

• Instant Updates: Users can dynamically retrieve and update data without reloading the entire page. For example, results can be displayed instantly after a form submission without refreshing the page.
• Smooth Interaction: Through asynchronous requests, user operations and page responses are smoother, reducing waiting times and the inconvenience caused by page reloads.

2. Single Page Application (SPA)

• SPA Development: The concept of Single Page Application (SPA, which is a single HTML page) became popular. Once loaded, the application does not require further page refreshes; all interactions and data loading are completed through AJAX. Frameworks such as Angular, React, and Vue.js have promoted the widespread adoption of SPAs.
• Modular Loading: Pages can dynamically load modules and components as needed, rather than loading all content at once, improving the application's loading speed and performance.

3. The separation of frontend and backend

• Separation of Concerns: AJAX drove the separation of front-end and back-end. The front-end is responsible for the user interface and interaction, while the back-end provides data services through APIs. This separation makes the development process more efficient.
• API-Driven Development: The popularization of technologies such as RESTful APIs and GraphQL allows the front-end to communicate with the back-end through standardized interfaces, enhancing development flexibility and maintainability.

4. Increased Complexity and Enhanced Functionality of Web Applications

• Real-time Updates: For example, social media platforms can instantly display new content, and e-commerce websites can dynamically update shopping carts and inventory information.
• Interactive Experience: Enhances the interaction between users and applications, with features such as autocomplete, instant validation, and real-time search suggestions.

Note 1: Did we mention earlier that many years ago, if there was a problem accessing a webpage, people would frantically press ”F5” to refresh? Although "F5" is still commonly used today, its essential purpose has changed: before AJAX became popular, users frequently used the F5 key to refresh the page, usually to ensure that the page loaded the latest data or to re-trigger certain operations. Since all content on the page had to be reloaded, this method was inefficient and had a poor user experience. After AJAX became popular, because AJAX allows asynchronous data requests without refreshing the entire page, it significantly improved the user experience: users no longer need to frequently use the F5 key to refresh page content, as parts of the content can be dynamically updated via AJAX. However, browser caching mechanisms still sometimes require using the F5 key to force-refresh the page to ensure the latest resources (such as CSS, JavaScript files, or page content) are loaded.

Note 2: Before AJAX became popular, the frontend and backend were not separated: frontend developers would write the HTML and CSS structures and then hand these HTML files over to backend developers; backend developers used server-side technologies (CGI and other server-side scripts, such as Perl, PHP, ASP) to query data from the database and fill this data into the page; finally, the backend returned the page filled with data directly to the browser, which meant the browser received an HTML page already filled with data. This method is known as Server-Side Rendering (SSR).

Front-end, Back-end, and Ajax

In the previous section, we mentioned that AJAX promoted the separation of frontend and backend. So, what are the frontend and backend respectively? Why did AJAX promote the separation of frontend and backend? This section will explain them one by one.

What is Front-end?

The frontend is the part you see and directly interact with when using a website or application. Simply put, the frontend is the user interface, including text, images, buttons, forms, etc., on a webpage.

For example: when you open a shopping website, the product list, search bar, shopping cart button, etc., that you see are all part of the frontend. The job of frontend developers is to make these things look beautiful, easy to use, and responsive to your actions, such as clicking buttons, entering text, etc.

Summary in one sentence: The frontend is responsible for presentation and user interaction: it makes webpages look good, buttons clickable, and forms fillable.

What is Back-end?

The backend is the part behind the website, responsible for handling things you cannot see, such as data storage and business logic.

Continuing with the previous example: when you click to add an item to your shopping cart on a shopping website, the frontend passes your action to the backend. The backend processes this request, such as saving the product information to your shopping cart record in the database, and then returns a confirmation message to the frontend.

Summary in one sentence: The backend is responsible for processing data and logic: it receives requests from the frontend, processes data (such as saving to or retrieving data from the database), and then returns the results to the frontend.

The Practical Role of Ajax

Still using the same example: on a shopping website, when you search for products, you usually do not see the page refresh. Instead, the search results are displayed without reloading the entire page. This is AJAX at work. The frontend sends a search request to the backend via AJAX, the backend processes it and returns the search results, and the frontend then dynamically displays these results.

Summary in one sentence: AJAX is the bridge of communication between the frontend and backend: it allows the frontend to request data from or submit data to the backend without refreshing the entire page, thereby improving the user experience.

The Popularization of Ajax Accelerated the Process of Front-end and Back-end Separation

There are many reasons for the separation of frontend and backend, but one very important reason is that the popularity of AJAX laid the technical foundation for this separation and largely promoted its implementation, as shown in the following aspects.

1. Asynchronous Data Loading
   Traditional Server-Side Rendering:

In traditional Server-Side Rendering (SSR), every user action or page refresh requires the server to generate a complete HTML page and send it to the client. This method is less efficient and offers a poor user experience.
Introduction of AJAX:

AJAX allows the frontend to communicate with the server, loading or sending data, without refreshing the entire page. This asynchronous communication method greatly improves the user experience, allowing webpages to respond to user actions more quickly.

2. Implementation of Single Page Applications (SPA)
   Single Page Application (SPA):

An SPA is an application that requests resources like HTML, CSS, and JavaScript only upon the initial load, with all subsequent page updates implemented through AJAX requests. In the frontend, SPAs manage views and states using JavaScript frameworks (such as React, Vue, Angular).
The Role of AJAX:

AJAX plays a key role in SPAs. The frontend retrieves data from the server via AJAX requests and dynamically updates the page without needing to reload the entire page. This approach not only improves the user experience but also reduces server load.

3. Clear Interface Design
   Frontend-Backend Interfaces:

The separation of frontend and backend requires them to communicate through clear API interfaces. The frontend calls APIs provided by the backend via AJAX requests to retrieve data and update views.
Support of AJAX:

AJAX makes it easy for the frontend to call backend APIs, retrieve the required data, and process it, ensuring that communication between the frontend and backend is efficient and flexible.

4. Shift in Development Models
   Parallel Development:

The separation of frontend and backend allows frontend and backend teams to develop in parallel, reducing mutual dependencies and blocking. Frontend developers can use AJAX to retrieve mock data from a Mock server for development, without having to wait for the backend APIs to be completed.
Popularity of AJAX:

The popularity of AJAX technology allows the frontend to be developed and debugged independently of the backend, greatly improving development efficiency.

5. Performance Optimization
   Asynchronous Loading:

AJAX can be used to load data on demand, reducing initial page load times and improving performance. Users only load additional data when needed, rather than retrieving all data at once when the page loads.
Data Updates:

Through AJAX, the frontend can achieve partial page updates instead of reloading the entire page every time, reducing network traffic and improving response speed.

6. Better User Experience
   Dynamic Interaction:

AJAX enables webpages to achieve more dynamic and rich interactive effects. For example, form validation can be performed in real-time as the user inputs data, without needing to submit the form before displaying error messages.
Data Refreshing:

Through AJAX, webpages can automatically refresh data in the background without requiring users to manually refresh the page. This approach is particularly important in real-time applications (such as chat applications, stock quotes, etc.).

Browser Same-Origin Policy Restrictions

The beginning of the article mentioned that the AJAX cross-origin issue is caused by the browser's Same-Origin Policy. To solve it, we first need to clarify what the Same-Origin Policy is and why it is needed.

What is the Same-Origin Policy?

The Same-Origin Policy is a rule used by browsers to protect user privacy and security. It stipulates that content on one website cannot freely access content on another website unless the two websites are “same-origin”. Here, “same-origin” can be understood as coming from the same place (i.e., the same protocol, domain name, and port; important: all three must be completely identical).

Why is the Same-Origin Policy Needed?

The Same-Origin Policy is like setting up a security door for each website, allowing each website's content and data to be controlled and accessed only by itself. In this way, even if you open multiple websites at the same time, information between them will not be leaked or abused, which greatly increases your online security and allows you to use various online services with greater peace of mind.
For example:

1. Preventing Malicious Operations: Without the Same-Origin Policy, an untrusted website might exploit your login status on another website to secretly perform operations, such as posting on your social media account, purchasing items on your shopping website, or transferring money on your banking website. This is as terrifying as someone using your credit card to shop without your knowledge.
2. Preventing Data Leaks: The Same-Origin Policy also ensures that the form content you fill out on one website cannot be seen by other websites. This is like talking about private matters in a closed room where people in other rooms cannot hear, thereby protecting your privacy.

Cross-Origin Issues Caused by the Same-Origin Policy

The Same-Origin Policy restricts direct interaction by the browser between different domains, different ports, or different protocols. This restriction leads to the occurrence of cross-origin issues. The following concrete examples illustrate why the Same-Origin Policy causes cross-origin issues:

Example: Accessing Data of Another Domain from One Domain

Suppose we have two websites:

• Website A: https://www.tangwudi.com
• Website B: https://blog.tangwudi.com

In the frontend JavaScript of Website A, if you try to directly access the data of Website B via an AJAX request, for example:

fetch('http://blog.tangwudi.com/data') 
.then(response => response.json()) 
.then(data => console.log(data)) 
.catch(error => console.error('Error:', error));

The browser will block this request because their domain names are different ( www.tangwudi.com 和blog.tangwudi.com), violating the same-origin policy. This is because the same-origin policy requires the domain names to be completely identical, including the protocol (https://), domain name (example.com), and port (if any).

Example: Accessing Data of the Same Domain Using Different Ports

Suppose we have the same website, but on different ports:

• Website A: https://www.tangwudi.com
• Website B: https://www.tangwudi.com:8080

If Website A tries to access the data of Website B via an AJAX request on the frontend, for example:

fetch('https://www.tangwudi.com:8080/data')   
.then(response => response.json())   
.then(data => console.log(data))   
.catch(error => console.error('Error:', error));

Similarly, the browser will also block this request because although their domain name and protocol are the same, the ports are different. Likewise, ”http://www.tangwudi.com” and ”https://www.tangwudi.com:8080" also violate the same-origin policy.

Example: Accessing Data of the Same Domain Using Different Protocols

Suppose we have the same website, but on different protocols:

• Website A: https://www.tangwudi.com
• Website B: http://www.tangwudi.com

If Website A tries to access the data of Website B via an AJAX request on the frontend, for example:

fetch('http://www.tangwudi.com/data') 
.then(response => response.json()) 
.then(data => console.log(data)) 
.catch(error => console.error('Error:', error));

Similarly, the browser will block this request because although their domain names are the same, the protocols are different (https and http), and the same-origin policy also prohibits such cross-protocol requests.

Solutions for Ajax Cross-Origin Access

Why is There a Need for Cross-Origin?

This is because of the requirements in actual development; many times, it is necessary to request resources that are not in the same domain as the current webpage. Specific reasons may include:

Microservices Architecture: Modern Web applications often adopt a microservices architecture, where different services are deployed under different domains or subdomains. Frontend applications need cross-origin access to these services.

CDN Resource Loading: To speed up resource loading, static resources (such as images, scripts, stylesheets) are usually hosted on Content Delivery Networks (CDNs), and the domains of these resources are different from the main site.

Third-party API Calls: Frontend applications may need to call API services provided by third parties, and these API servers are usually located under different domains.

Separated Development Environments: Development and testing environments may have different domains from the production environment. During development, frontend applications need cross-origin access to backend services.

Methods of Ajax Cross-Origin Access

Common methods to solve Ajax cross-origin access issues include the following.

JSONP (JSON with Padding)

JSONP is an early method to solve cross-origin issues, by dynamically creating<script>tags to request cross-origin resources, because<script>tags are not restricted by the same-origin policy.

Example:
Suppose you have a cross-origin API http://tangwudi.com/data, you can use JSONP like this:

<script>
function handleResponse(data) {
    console.log(data);
}

var script = document.createElement('script');
script.src = 'http://tangwudi.com/data?callback=handleResponse';
document.body.appendChild(script);
</script>

In this case, the server needs to wrap the response in a callback function, for example:

handleResponse({ "message": "Hello, World!" });

Note: JSONP is only suitable for simple cross-origin situations that only support GET requests.

CORS (Cross-Origin Resource Sharing)

CORS is a mechanism supported by modern browsers that allows servers to inform the browser that cross-origin requests are allowed by setting HTTP headers.

Example:
On the server side (assuming Node.js and Express are used):

const express = require('express');
const app = express();

app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', '*'); // Allow access from all domains
    res.header('Access-Control-Allow-Methods', 'GET,POST');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    next();
});

app.get('/data', (req, res) => {
    res.json({ message: "Hello, World!" });
});

app.listen(3000, () => {
    console.log('Server running on port 3000');
});

On the client side (browser side), you can directly use AJAX requests:

fetch('http://localhost:3000/data')
    .then(response => response.json())
    .then(data => console.log(data));

Note: CORS is the recommended method for modern browsers. In scenarios where the frontend accesses the backend across origins, settings need to be configured on the backend server.

Reverse Proxy Server

By setting up a proxy on the same-origin server, requests are forwarded to the target server, avoiding direct cross-origin requests.

Example:
Suppose your frontend server is http://localhost:3000 and the API server is http://tangwudi.com.

Set up a proxy on the frontend server to reverse proxy requests accessinghttp://localhost:3000/apitohttp://tangwudi.com(for example, using Node.js and http-proxy-middleware):

const { createProxyMiddleware } = require('http-proxy-middleware');
const express = require('express');
const app = express();

app.use('/api', createProxyMiddleware({ target: 'http://tangwudi.com', changeOrigin: true }));

app.listen(3000, () => {
    console.log('Frontend server running on port 3000');
});

Then operate on the client side as follows:

fetch('http://localhost:3000/api/data')
    .then(response => response.json())
    .then(data => console.log(data));

Note: The above three methods are mainly solutions for Ajax cross-origin issues. In fact, general cross-origin access can also use the src attribute in several HTML tags for cross-origin resource sharing. For example:
<script> tags can be used to load JavaScript files across origins

<script src="https://example.com/some-script.js"></script>

<img> tags can be used to load image resources across origins

<img src="https://example.com/image.png" alt="Example Image">

<link> tags can be used to load CSS stylesheets across origins

<link rel="stylesheet" href="https://example.com/styles.css">

<iframe>tags can be used to embed cross-origin webpage content

<iframe src="https://example.com"></iframe>

和 tags can be used to load audio and video files across origins

<audio controls>
  <source src="https://example.com/audio.mp3" type="audio/mpeg">
</audio>

<video controls>
  <source src="https://example.com/video.mp4" type="video/mp4">
</video>

Does Cross-Origin Matter to Ordinary People?

Cross-origin is a concept that is difficult for ordinary people to encounter, because these are problems that need to be solved during the application development process. When the application development and testing are completed and opened to the public, it is a unified UI that has already solved the cross-origin issue, and all content and functions on this UI are normally under the same domain (of course, a few special cases are not ruled out, but even in those cases, errors would be reported in the browser's developer console, and ordinary people would not actively open the developer tools, so they still wouldn't see it).

However, although ordinary users generally do not directly see cross-origin issues, in some cases, users may encounter errors or abnormal behaviors caused by cross-origin issues. For example, some of the following possible situations are caused by cross-origin issues:

Data Failed to Load

• Manifestations: Some data on the page cannot be displayed, such as product lists, comments, news content, etc., which are blank or not updated.
• Cause: AJAX requests are blocked due to cross-origin issues, resulting in data failing to load from the server.

Functional Anomalies

• Manifestations: Certain functions cannot be used normally, such as search, form submission, liking, etc., having no response.
• Cause: These operations usually require communication with the server, and cross-origin issues may cause requests to be blocked, thereby preventing the functions from executing.

Console Errors

• Manifestations: When users open the browser's developer tools (although ordinary users rarely do so), they may see cross-origin related error messages, such as Access-Control-Allow-Origin errors.
• Cause: Cross-origin requests are blocked by the browser's same-origin policy, and detailed error messages will be displayed in the console.

Static Resource Loading Failed

• Manifestations: Page styles are messed up, images cannot be displayed, JavaScript functions fail, etc.
• Cause: If static resources (such as CSS, images, scripts) fail to load correctly due to cross-origin issues, the page may not render normally.

The Current Status of Ajax

This article uses AJAX technology as the core to connect other concepts. In reality, although AJAX is still an important technology, its usage and role have changed with the advancement of front-end development.

The Core Role of AJAX Remains Unchanged

The core concepts of AJAX—asynchronous data requests and partial page updates—remain the cornerstone of modern front-end development. Whether through native XMLHttpRequest or Fetch API, asynchronous requests are the primary way for the front end to interact with the server.

The Rise of Modern Alternatives and Tools

Although AJAX still exists as a technical concept, many modern tools and frameworks provide higher-level abstractions and more convenient ways of use:

• Fetch API: The native API of modern browsers, providing a simpler and more flexible way to make network requests. It is an improvement over XMLHttpRequest.

fetch('https://api.example.com/data') .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error('Error:', error));

• Front-end Frameworks and Libraries: Frameworks and libraries such as React, Vue, and Angular usually integrate data request methods and tools, making it more convenient to handle asynchronous data requests. For example, the commonly used axios library in React:

import axios from 'axios'; axios.get('https://api.example.com/data') .then(response => console.log(response.data)) .catch(error => console.error('Error:', error));

• GraphQL: A query language for APIs that allows clients to request the exact data they need, reducing the redundant data issues of traditional RESTful APIs. Apollo Client is a commonly used client library for GraphQL.

The Popularization of Single Page Applications (SPA)

Single-page application (SPA) frameworks, such as React, Vue, and Angular, have greatly changed the way of front-end development. These frameworks provide higher-level component-based development and state management, making AJAX calls a part of their larger ecosystem.

SSR (Server-Side Rendering) and Static Generation

Frameworks like Next.js (based on React) and Nuxt.js (based on Vue) support server-side rendering (SSR) and static site generation (SSG). They pre-fetch data during the build process, thereby reducing the need for client-side AJAX calls. These frameworks can still make AJAX calls after client-side rendering, but their usage and purpose differ from traditional AJAX calls.

Progressive Web Technologies

With the development of Web technologies, technologies like Service Workers and WebSockets provide more real-time communication and offline capabilities. These technologies extend the capabilities of traditional AJAX, enabling front-end developers to build richer and more dynamic applications.

Integration with Modern Development Toolchains

Modern development toolchains (such as Webpack, Babel, etc.) and development patterns (such as modular development, micro-frontend architecture, etc.) also affect how AJAX is used. These toolchains and patterns make code organization better and performance optimization easier, while also simplifying the complexity of data requests and processing.

Afterword

This article is so hard to write; I have to constantly clear my thoughts. Most online resources are from a programmer's perspective, where posting a snippet of code basically explains everything. However, many basic concepts that are common sense to them and don't even need mentioning are half-understood jargon to ordinary people (or non-programmers), making them more and more confused as they read on~~ So to explain it clearly, I need to sort through concepts one by one. It's so tiring, after all, I am not a professional either.

In addition, although I have tried my best to limit using code as examples (worrying that non-IT friends might not understand), for some concepts, showing a simple piece of code indeed speaks louder than a thousand words. Perhaps my knowledge accumulation is still too poor to think of simpler, more concise explanations. I can only make up for this through continuous learning in the future.

So, what is the point of writing this article? After thinking for a long time, it seems there really isn't much use: programmers don't need to read it, and it's not of much use to ordinary people either...

However, for me, if I want to get into the coding field in the future, this article will be a very good basic guide to give me a general direction.