面向后端开发人员的实用前端指南

介绍

我是一名后端开发人员……普通的那种……擅长数学但美学很糟糕。我所做的任何设计尝试总是导致看起来无聊的通用垃圾。我尝试使用几十种工具，但最终结果总是看起来像是用

我意识到了这一点，所以我放弃了尝试。我会为你写一份文档，但前提是你给我一个现成的 $\LaTeX$ 样式文件。我会写一篇博客，但只能写，让别人来担心视觉吸引力。我会准备一份演示文稿，但前提是组织者提供。我永远不会尝试设计任何东西，无论是按钮还是登录表单。

然而，我不能就这样剃光头，退居后端“JSON API”的避难所——我仍然需要为我的宠物项目编写前端并构建供内部使用的仪表板。但尝试进入前端世界是非常痛苦的——数十个框架、库、哲学。在过去的 8 年里，我一直听到“React”或“Angular”或“Node”这些词，但我太害怕真正尝试去理解它们。学习“C++”或比这更容易。

尽管如此，我还是强迫自己学习它，现在我想成为一个普罗米修斯（我不确定是否已经有一个同名的“JS”框架），并将这些知识带给我的人——后端开发人员。

作为奖励，我附上了关于选择哪种前端框架的最终建议。我自己很长时间以来都患有决策障碍，这将帮助你克服它，并开始构建东西而不用过多考虑。

绝对基础

在讨论框架之前，让我们先从最基础的部分开始，以确保我们的观点一致。如果您愿意，可以跳过此部分。

最小网页

一个最小的网页由一个扩展名为“.html”的文本文件和内容标签组成：

    
Hello World!

要添加格式，您可以添加样式属性：

    
Hello World!

或者如果你有很多格式，请将“id”添加到你的内容中并从“

    
Hello World

    

This will create static pages that do not change and do not react to any events. To add some interactivity, like checking if you left a form field empty or entered a valid email, you will need `JavaScript`.

Running JavaScript

Before using any programming language you must first install it on your computer. For `C/C++` you need to install a compiler like `GCC` or `Clang`, for `Python` you need to install a `CPython` interpreter.

To run `JavaScript` you only need a web browser --- all modern web browsers can run `JS` code. It is as simple as opening a web browser and going to pressing `F12`. This will open a `JS` console:

You can also create a text file with extension `.html` and put a `

However, for safety reasons, the browser console has no access to your file system and lacks some other features that would make it possible to use `JS` to, at least, achieve the functionality of other scripting languages like `Python` or `Ruby`. So, there is a second way to run `JS` code on your computer --- installing `Node.js`. It is essentially a `JS` interpreter which can do stuff like reading and writing files:

//$ node
//Welcome to Node.js v23.3.0.
//Type ".help" for more information.
> console.log('Creating a new directory');
> fs.mkdirSync('new_dir'); // access filesystem using fs

With `Node.js` you can run `JS` code in the server or in your `Docker` container without having to install a web browser. We will see below that this is very useful.

Classical stack

Combining the sections above we can create a web page using the classical `HTML+CSS+JS` setup.

They can be combined in a single `.html` file with 3 sections: content itself, styles, and scripts:

    
    
Hello World
    Say Hello

    

    

You can see that we have a button that triggers a function `sayHelloWorld()`, which is defined inside `

**styles.css**

#mytext {color:red; font-size:20pt}
button {font-size: 40pt}

**scripts.js**

function sayHelloWorld() {
    console.log('Hello World');
}

The biggest problem with this setup is that if you look at the `HTML` element, for example, the ``, you cannot know which style it has and which scripts are listening to it unless you look at the other two files. Similarly, if you look at the `.js` file, you see a function `sayHelloWorld()` but have no idea whether it is needed or not, or if some element is calling it or not, without looking at the `.html` file. This goes against the so-called principle.

Anyway, this setup has been used on the Web for several decades.

Client-side vs. Server-side

Great! We have covered the basics. Now let's talk about the main dilemma that underlies all discussions regarding the choice of a frontend framework, and the architecture of your app in general. Before we start, let's clarify some terminology: means the browser or an app in which the users consume your content, and is usually the backend server that stores the login information, has access to database, and overall serves as the backbone of the entire app. Now we are ready to dive deeper.

Classical HTML generation

In any non-trivial web app that displays any kind of data we will need a way to generate `HTML` scripts automatically. Otherwise, whenever the data is updated, somebody will have to manually update the `HTML` tags.

Since `HTML` is a simple text file, it can be easily created by any scripting language as a string. There are many libraries that do this. For example, with `Jinja2` library we can write all elements of a list `mylist = [1,2,3,4,5]` into table rows using a language that resembles `Python`:

    {% for item in mylist %}
        
    {% endfor %}
 
 {{ item }} 
 

Of course, the browser would not understand this --- you will need to this `Jinja2` script into actual `HTML` by running special commands in `Python`, which will render an `.html` file:

    
 
 1 
 
    
 
 2 
 
    
 
 3 
 
    
 
 4 
 
    
 
 5 
 

This feature is so crucial that it even has a special name --- . I want to stress one thing: such `HTML` generation from a template happens in the server in a language of your choice (`Python/Ruby/Java/C#`), usually a language your backend code is written in. Browsers do not understand these languages natively --- they only understand `JS`, so we send them a pre-rendered `HTML` file. This will become important later on.

JSON vs HTML API

In the previous section we saw how backend can generate `HTML` scripts and fill them with the data from database and other information. For example, if the user presses the button on some social media post, the backend must update the content of page to include that new post there. This can be done in two ways:

**1)** Backend has an `HTML` template ready with some `Jinja2` script and renders it with the latest query result from the database:

    {% for post in liked_posts %}
        
    {% endfor %}
{{ post.author }}
{{ post.text }}

Here the rendered `HTML` is sent directly to the frontend together with the `CSS` styles and `JS` scripts. The browser simply displays what the backend has already prepared and is not aware of the types of data or any logic on the page.

**2)** Backend sends the `JSON` that specifies the query result from database 's `liked_posts` table in a format that browser would understand:

{
    liked_posts: [
            {author: "Apple", text: "Think different"},
            {author: "Nike", text: "Just do it"}
        ]
}

The browser runs special `JS` functions that request such `JSON`, and when they receive it, they use extract data from it and generate `HTML` from it on the browser itself:

Server-side rendering

Note that in `JSON API` architecture the browser knows a lot about the data it receives --- it sees the different fields, it can perform programming tasks on it like reversing strings, multiplying, repeating, reusing the author name in several places etc.

This is really useful if you need a complex interactive user interface but this is slightly less secure because the browser is not in your hands --- it belongs to a user who can be malicious.

Moreover, if the user's computer is weak, running all these scripts in the browser will slow down the entire web app, unlike pre-rendered `HTML` which is a simple text file that will run smoothly in most computers.

Also, the search engine crawlers do not usually wait for the web page to load all of its scripts, and if the page has zero content on it to begin with, the search engine optimization suffers as a result.

There is a modern trend called that runs `Node.js` on the server and pre-renders some `HTML` pages using `JS` directly in the server. This kinda solves the problems above, but it also bites a slice of the backend's pie. If we try to visualize the three approaches, it would be something like this (assuming backend is in `Python`):

In SSR the `Python` backend has access to database and maybe stores login information, but everything else is done in `JS`. The diagrams are very simplistic, but in SSR there is also `JS` on the client side, making the entire web application 95% written in `JS`. Some libraries took the next logical step and covered the entire backend in `JS` using frameworks like `Express.js`, but I won't be talking about the `JS` backend in this article.

Build step

These `JS` scripts are usually not written manually but are compiled by some higher level `JS` library or framework. This build step (i.e. compilation of higher level code into `HTML+JS`) is done in server using a running `Node.js` instance.

By design, all the `JS` dependencies are installed into a virtual environment (similar to `virtualenv` in Python or `rbenv` in Ruby) that is stored directly in the work folder in a subdirectory called `node_modules`. It usually takes up around 200MB of space and should be `.gitignored`.

Once you run a build command that usually looks like `npm run build`, it will generate the static `HTML+JS` files. Now you have 2 options to serve these static files to the client's browser:

Using your backend's FileResponse which simply scans for the generated files in the static directory, resolves the relative paths, and sends the files to the client.

Using Node.js's serve functionality like npx serve mydir which will run a server in a separate port, independently from your backend.

Overall, it looks kinda like this:

Option 1 has a very intuitive setup --- you can bind your backend's router and respond to certain URLs with these files.

@app.get("/")
def index():
    return FileResponse("dist/index.html")

Option 2 is popular for some reason, although it is more complicated. In this setup you only expose the frontend port to the client, and it will serve the static `HTML+JS` app without any need for the backend. And only when it needs to fetch data from the backend, will the frontend connect to the backend itself, abstracting away this functionality from the browser. Of course, to do so the frontend now will need its own router. Basically, this is frontend trying to do what backend should be doing.

Components

So far, we have covered the basics of how the working frontend code can be written and where it is located. We have seen how `HTML` can be automatically generated but, up till now, we assumed that the `JS` part is written manually. This is very often not the case in the real life frontend development. Manually writing `JS` scripts is cumbersome and your code structure gets very messy very fast. Moreover, if you need to reuse scripts, you will have to old-school copy and paste them. So, since the very beginning, developers used some sorts of libraries to make `JS` development easier and more structured.

JQuery

In the early days, using vanilla `JS` to find and modify elements or to send `AJAX` requests to the server was very cumbersome. Thus, many developers used `JQuery`, which was a neat syntactic sugar on top of the vanilla `JS`. Many add-ons have been written in `JQuery`, like `Datatables` (interactive tables with search, pagination, sorting out of box), or animated clocks, or counters etc. Using such components pre-written by someone else was really easy --- just download the code and add it to your `HTML` page under `

But in Bootstrap you do not write a single line of `JS` yourself, just put the necessary classes:

Show/hide

Bootstrap was a revolution in frontend development, and many libraries followed its approach, like `PicoCSS` or `TailwindCSS`. It super-powered the `HTML` by just adding classes to it, but it couldn't create custom `HTML` elements and had to rely on native `HTML` elements.

Custom Button


Custom Button

This means that you couldn't really create easy-to-use complex components like `` or ``.

JSX and the likes

Around the same time another approach to writing frontend appeared --- using scripting capabilities of `JS` to develop components of any complexity and then simply compile them into `HTML` (also known as the ). To be able to do this, `React.js` (and other similar libraries) found a way to write `HTML` components inside the `JS` code. There are multiple ways to do this, but I will show just one of them, called `JSX`, which works like this:

function btn() {
    // inside this JSX function we can write HTML and JS together
    return (
        Custom Button
    );
}

and then use it inside a main `JSX` function:

function App() {
    return (
        

              // custom component  defined in btn() function
        
    );
}

The web browser would not understand this `` element, so the final step is to compile this `JSX` code into `HTML+JS`. The result will be something like:

The principle is very similar to compiling scripts to machine code. The end result will not be human-readable, and the resulting `HTML` will contain lots of `

However, this approach didn't really catch on yet.

JS component libraries

For those people who hesitate using libraries like `React.js`, there are `JS` libraries that provide pre-compiled components like `Chart.js` which you can use to create charts with vanilla `JS`:

This is really helpful if you need an interactive chart but don't want to go fully into frontend `JS` area. However, you will need to have your data in `JSON` format, because such libraries usually do not read data from `HTML`.

Frontend libraries

Finally, let's have a very brief overview of the most popular frontend libraries and frameworks. By library we mean something that can render `JS` and `HTML` with custom components. By framework we mean everything in the library plus a frontend router and state management (i.e. ability to store global variables in the frontend).

React.js

Uses `JSX` to add `HTML` into `JS` functions:

function App() { return 
Hello world!
; }

which is not the most intuitive way to write dynamic pages.

It is a library and supports numerous 3rd party tools for routing and state management. That is why it is too flexible and less intuitive for beginners.

Not recommended.

Vue.js

Uses to add `JS` into `HTML`:

    
Hello, {{ name }}!

which is very intuitive.

It is a framework with `Vue Router` for routing and `Pinia` for state management. These are very often an overkill for backend developers, so keeping logic outside `Vue` would be wise.

It has a great community and ready-made component libraries for easily building stunning user interfaces --- `PrimeUI` and `Vuetify`.

Recommended if you need beautiful UI.

Svelte

A new kid in the block. Uses Single File Component system, where you write styles, scripts, and `HTML` content in one file. Very easy to use.

Uses like `Vue.js`.

Hello, {name}!

It is a minimal framework. And you will find yourself writing a lot of vanilla `JS` code to achieve some functionality that is easy in `Vue.js`

Not recommended.

Alpine.js

a minimal library that has no build step --- the entire library is a single 15 KB `JS` file.

Uses like `Vue.js` and `Svelte` but you can write `JS` directly inside `HTML` attributes without any `

It markets itself as a modern replacement for `JQuery` and it is really cool for adding a little bit of interactivity without a complicated user interface.

Recommended if you need a little bit of interactivity and handling JSONs.

HTMX

a library that promotes having all logic in the backend and requesting `HTML` instead of `JSON`.

Promotes using any backend-side templating library like `Jinja2` to generate required `HTML` and then send this `HTML` snippet to the client without any `JS`.

and the backend sends not a `JSON` but an `HTML` snippet:

# on GET request to /api/name return HTML
@app.get("/api/name", response_class=HTMLResponse)
def api_name():
    return "
Hello, World!
" # instead of {"name": "World"}

Supports all `HTTP` verbs (`GET/POST/PUT/PATCH/DELETE`).

Recommended if you don't need `JSON` data.

Which framework to choose?

I will try to be as simplistic and dismissive as possible, because if I went into an objective analysis of pros and cons, you wouldn't get any useful information aside from "it depends". I will be biased towards the least movements necessary to set up a user interface and to avoiding build step if possible. So, here is my ultimate recommendation:

Conclusion

In this blog post I wanted to share everything that I learned about frontend as a backend developer. It seems that this stuff is overly complicated and intimidating, although, upon digging, I realized that there is a logic and structure to it. I hope that I could convey my understanding to you, and that you found this post useful.