跪拜 Guibai
← Back to the summary

Why Frontend Devs Have a Head Start in AI Agent Development

Chapter 1: Why You Should Learn AI Agents — The Evolutionary Path from "Page Slicer" to Full-Stack

Let's Start with a Story

Imagine your name is Xiao Chen, a frontend developer who has been writing Vue3 for three years. Your daily routine involves taking requirements, laying out pages, calling APIs, and fixing bugs. Occasionally, you write a Composable, use ref and reactive to manage state, and use watch to monitor changes. Life is pretty stable.

Until one day, your boss suddenly says at the weekly meeting: "We need to build a smart customer service system that can automatically answer user questions. Xiao Chen, look into it and give me a proposal in two weeks."

Your mind probably looked something like this:

1.png

Smart customer service? AI? I only know Vue3... The backend is NestJS, but Old Wang wrote that; I'm not familiar with it... AI interfaces? What's an LLM? What's RAG? Are they asking a frontend developer like me to do AI development??

You open a search engine and type "how can frontend developers build AI applications." The results are full of things like "large model fine-tuning," "Transformer architecture," and "Attention mechanism"—you recognize every character, but they make no sense when put together. You search for "AI Agent development tutorial," and the results are all Python code, Google Colab notebooks, and Jupyter environment configurations, giving you a headache.

Then you start to doubt your life choices: Is the leap from writing pages to doing AI too big? Do I have to spend six months learning Python, then another six months on machine learning, just to touch the edge of AI?

Honestly, I completely understand this confusion. When I first encountered AI Agents, I felt the same way—opening GitHub to find a bunch of Python projects, each with dozens of dependencies, and READMEs full of terms I'd never heard of. I thought: Does this have anything to do with frontend? Can someone who writes Vue even understand this?

But later, I found out I was completely wrong. The core of AI Agent development is not "training models," but "orchestrating logic." And "orchestrating logic" is something frontend developers do every day—combining components, managing data flow, and polishing user experience. Once I truly understood the essence of Agents, I realized: For frontend developers, AI Agent development is not a career change; it's a dimensional strike.

If you have similar confusion, this chapter is written for you. I'll give you the conclusion first: Frontend developers actually have a natural advantage in the AI era, and can even pick up AI Agent development more easily than pure backend developers. This isn't just motivational talk; I'll break it down point by point below. After reading this chapter, you won't feel that AI Agents are something out of reach. Instead, you'll think: "Oh, so that's all it is. I think I could do that too."

But before that, I want to help you clear up a cognitive misunderstanding. When many people hear "AI development," the image that comes to mind is a PhD sitting in front of a computer, screen full of mathematical formulas, with several GPUs in front of them, training a model for three days and nights. That image isn't exactly wrong, but that's called model research and development, not AI application development. Let's use an analogy:

What we do in this booklet is the work of a "pharmacist": using off-the-shelf AI models (the drugs), combined with tool calling, memory management, and workflow orchestration (the prescription), to create AI Agent applications that solve real problems. You don't need to understand the principles of Transformers, how to calculate loss functions, or even what "gradient descent" is—those are matters for model researchers, not application developers.

Alright, having cleared up this understanding, let's look at why frontend engineers actually have an advantage in this "pharmacist" role.

Why Frontend Has an Advantage in the AI Era

Many people think AI development is the exclusive domain of algorithm engineers, requiring Python, deep learning knowledge, and the ability to train models. This impression isn't entirely wrong—if you want to work on the model layer, such as training a large model, fine-tuning, or doing RLHF, you indeed need a strong ML background. But the problem is, 99% of AI application developers never need to touch the model layer.

Let's use another analogy: To run a restaurant, you don't need to know how to farm; you just need to know how to cook with ingredients. AI Agent development is the same: you don't need to train models yourself; you just need to "use" existing models well. Farming is the job of farmers (companies like OpenAI, Anthropic, DeepSeek), and cooking is the job of chefs (you, the application developer).

Working on AI Agents is essentially application-layer development, not model-layer development. And when it comes to application-layer development, frontend engineers have a few core skills that are a dimensional strike in the AI field.

1. Streaming Rendering: What You Write Every Day Is Exactly What AI Chat Needs

Have you ever used ChatGPT? When you type, the reply comes out word by word, not all at once. This "streaming output" effect is almost ubiquitous in AI applications—because LLM text generation itself is a process of spitting out one token after another, and word-by-word output is the most natural interaction method.

Technically, what is this effect called? It's called Server-Sent Events (SSE) or Streaming HTTP. Frontend developers should be familiar with this—when you write large file chunked uploads, WebSocket real-time messages, or progress bar polling, you are essentially handling "data streams." Data doesn't return all at once, but piece by piece, and you update the UI as it arrives.

For example, the following code should look very familiar to a frontend developer:

// Call the AI interface, read the response as a stream
// This is essentially the same thing as handling progress callbacks for large file uploads
const response = await fetch('/api/chat', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ message: 'Who are you?' })
})

const reader = response.body!.getReader()
const decoder = new TextDecoder()

while (true) {
  const { done, value } = await reader.read()
  if (done) break

  // Every time a piece of data is received, append it to the message, and the UI updates automatically
  const chunk = decoder.decode(value, { stream: true })
  // Vue3 reactivity: when messages change, the DOM updates automatically
  messages.value[messages.value.length - 1].content += chunk
}

Isn't this the frontend's most familiar pattern of "data arrives, update the DOM"? The only difference is that before, the API returned JSON, and now the AI returns a text stream. There's no essential difference. You might even find that streaming rendering for AI chat is simpler than many complex interactions in frontend projects.

In Vue3, we can easily handle this streaming data using ref or reactive. Vue's reactivity system is naturally built for this—when data changes, the UI automatically follows; you don't need to manually manipulate the DOM.

Moreover, you can encapsulate this streaming read logic into a Composable, reusable for any future AI project:

// composables/useStreamChat.ts
// Encapsulates the streaming chat logic, reusable for any AI project
import { ref } from 'vue'

export function useStreamChat() {
  const messages = ref<Message[]>([])
  const isStreaming = ref(false)

  async function sendMessage(content: string) {
    messages.value.push({ role: 'user', content, id: crypto.randomUUID() })
    isStreaming.value = true

    const aiMessage = { role: 'assistant' as const, content: '', id: crypto.randomUUID() }
    messages.value.push(aiMessage)

    try {
      const response = await fetch('/api/chat', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ message: content })
      })

      if (!response.ok) throw new Error(`HTTP ${response.status}`)

      const reader = response.body!.getReader()
      const decoder = new TextDecoder()

      while (true) {
        const { done, value } = await reader.read()
        if (done) break
        aiMessage.content += decoder.decode(value, { stream: true })
      }
    } catch (err) {
      aiMessage.content = 'Sorry, the AI response failed. Please try again later.'
      console.error('Streaming chat error:', err)
    } finally {
      isStreaming.value = false
    }
  }

  return { messages, isStreaming, sendMessage }
}

After encapsulating it into a Composable, you can use const { messages, sendMessage } = useStreamChat() in any Vue3 component to implement streaming chat with a single line of code. This is the power of frontend engineering—encapsulating complex logic and exposing simple interfaces. This ability is equally important in backend AI development scenarios—the better you encapsulate, the lower the subsequent maintenance cost.

Furthermore, Vue3's watch and computed can help you do even more. For example:

// Use watch to monitor message changes and auto-scroll to the bottom
watch(
  () => messages.value.length,
  () => { nextTick(() => { chatContainer.value?.scrollTo({ top: 999999 }) }) }
)

// Use computed to calculate the token usage of the current conversation
const tokenUsage = computed(() => {
  return messages.value.reduce((sum, msg) => sum + msg.content.length, 0)
})

These are operations you do every day when writing Vue3, and they are fully reusable in AI applications.

2. State Management: Your Pinia Experience Is Directly Transferable

An AI Agent chat interface involves quite a bit of state behind the scenes, and it's more complex than a typical CRUD page:

These state management problems can be solved with a single Pinia Store. It's what you do every day, just in a different scenario.

// A typical Agent conversation Store — see any difference from your usual Pinia Store?
import { defineStore } from 'pinia'
import { ref, computed } from 'vue'

export const useChatStore = defineStore('chat', () => {
  // Message list for the current session
  const messages = ref<Message[]>([])

  // Agent's current thinking state
  const agentStatus = ref<'idle' | 'thinking' | 'calling_tool' | 'responding' | 'error'>('idle')

  // Currently executing tool calls
  const currentToolCalls = ref<ToolCall[]>([])

  // User preference settings
  const userPreferences = ref<Record<string, any>>({})

  // Multi-session list
  const conversations = ref<Conversation[]>([])

  // Computed property: estimated token usage for the current session
  const estimatedTokens = computed(() => {
    return messages.value.reduce((sum, msg) => sum + Math.ceil(msg.content.length / 4), 0)
  })

  async function sendMessage(content: string) {
    messages.value.push({ role: 'user', content, id: crypto.randomUUID() })
    agentStatus.value = 'thinking'

    try {
      const response = await fetch('/api/agent/chat', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          messages: messages.value,
          preferences: userPreferences.value
        })
      })

      // Read the response as a stream, update the UI word by word
      const reader = response.body!.getReader()
      const decoder = new TextDecoder()
      const aiMsg = { role: 'assistant' as const, content: '', id: crypto.randomUUID() }
      messages.value.push(aiMsg)

      agentStatus.value = 'responding'
      while (true) {
        const { done, value } = await reader.read()
        if (done) break
        aiMsg.content += decoder.decode(value, { stream: true })
      }
      agentStatus.value = 'idle'
    } catch (err) {
      agentStatus.value = 'error'
      console.error('Agent call failed:', err)
    }
  }

  return {
    messages, agentStatus, currentToolCalls,
    userPreferences, conversations, estimatedTokens,
    sendMessage
  }
})

See? Isn't this just routine Pinia operations? The only difference is that before, you were calling CRUD REST APIs, and now you're calling an AI Agent API. The core of state management hasn't changed; only the data source has. Use ref where you need ref, computed where you need computed, watch where you need watch—all things you've been writing for three years.

Moreover, Pinia's $subscribe and $onAction are particularly useful in Agent scenarios. For example:

// Monitor Agent state changes and automatically log them (for easy debugging)
const chatStore = useChatStore()

// Log whenever agentStatus changes
chatStore.$subscribe((mutation, state) => {
  if (mutation.storeId === 'chat') {
    console.log(`[Agent] Status change: ${state.agentStatus}`, {
      messageCount: state.messages.length,
      toolCalls: state.currentToolCalls
    })
  }
})

// Intercept the sendMessage action and log the duration of each request
chatStore.$onAction(({ name, after }) => {
  if (name === 'sendMessage') {
    const start = Date.now()
    after(() => {
      console.log(`[Agent] sendMessage duration: ${Date.now() - start}ms`)
    })
  }
})

These advanced Pinia features are very practical for debugging and monitoring Agent applications. You don't need to introduce any extra monitoring tools; Pinia's built-in APIs can handle it. This is the benefit of "using familiar tools for new things"—you don't have to learn a new framework; you just need to apply old tools to new scenarios.

3. User Experience: Frontend Developers Know Best What Users Want

What do AI applications fear most? They fear users not knowing what the AI is doing.

Have you ever seen an app where nothing happens after you click a button? Makes you want to throw your phone, right? AI chat is the same. If a user sends a message and sees nothing for 5 seconds, their first reaction isn't "the AI is processing," but "is my internet disconnected? Is the system down?"

Frontend engineers deal with user experience every day. You know how to handle these things with your eyes closed:

A pure backend engineer might think these details are "good enough if they work," but a frontend developer knows—good experience makes users willing to use it; users willing to use it gives the product value. And the user experience of AI applications is something the entire industry is still figuring out. By entering now, you're exactly at the "pioneering" stage. Every experience optimization you make could become an industry standard.

For example, the "thinking process visualization" in many current AI chat products is very crude—either showing just a "Thinking..." or nothing at all. But if you can make it look like this:

User: Help me analyze last month's sales data Agent: [1/4] Understanding your request... ✓ [2/4] Querying database... Found 847 records ✓ [3/4] Analyzing data trends... Found 3 anomalies ✓ [4/4] Generating analysis report... ▊

Seeing this, the user feels reassured—"The Agent is working, it's not stuck." And the checkmarks after each completed step give a sense of "progress is being made." Frontend developers are naturally more sensitive to these details than backend developers. Because frontend developers interact with users every day and know what kind of feedback reduces user anxiety.

Furthermore, the Agent's "thinking steps" can actually be made interactive. A user clicking on a step could expand it to see detailed information—for example, the "Querying database" step could expand to show the executed SQL statement, the number of records returned, and the time taken. This information might be useless to regular users but is very useful for developer debugging. And naturally integrating "debugging information" into the "user interface" is precisely a strength of frontend component-based design.

4. Component-Based Thinking: The Agent Frontend Is Just a Combination of Components

Vue3's component-based thinking is a match made in heaven for the frontend architecture of AI Agent applications. Think about it: what components does an Agent application's frontend roughly need? Let's break it down:

ChatPanel ← Chat panel, the core interaction area ├── MessageBubble ← Single message bubble (User/AI/System) │ ├── User message: right-aligned, blue background │ ├── AI message: left-aligned, includes Markdown rendering │ └── System message: centered, small gray text ├── ThinkingSteps ← Agent thinking step display │ ├── Step list: Searching → Analyzing → Generating │ └── Status icon per step: In Progress / Done / Failed ├── ToolCallCard ← Tool call result card │ └── Collapsible, shows tool name, parameters, return result └── MessageInput ← Input box ├── Text input (supports Shift+Enter for newline) ├── File upload button (images, PDFs, etc.) └── Send button SidePanel ← Sidebar ├── ConversationList ← Historical conversation list (searchable, deletable) ├── AgentSettings ← Agent configuration panel │ ├── Model selection (GPT-4 / Claude / DeepSeek) │ ├── Temperature slider │ └── System Prompt editor └── KnowledgeBase ← Knowledge base management entry Dashboard ← Dashboard ├── UsageStats ← Token usage statistics (Today / This Week / This Month) └── ConversationLogs ← Conversation logs (for debugging and auditing)

How is this any different from writing a backend management system? It's all component decomposition, data flow, and state management—the exact same pattern. Each component receives props, emits events, and shares global state through Pinia. You can completely transfer your previous experience writing backend management systems to the UI development of AI Agent applications.

Moreover, because the UI pattern for AI chat is relatively fixed (message list + input box), you could even write a universal Agent UI component library, reusable for any future AI project. One set of components for all AI projects—isn't that better than writing CRUD pages from scratch every time?

Speaking of component libraries, there are already some ready-to-use AI chat components in the Vue3 ecosystem, such as Vue Chat UI and Naive UI's Chat component. But I suggest you write it yourself from scratch first—because only by writing it yourself will you know the details of streaming rendering, the pitfalls of Markdown rendering, and the edge cases of message scroll positioning. After you've written it yourself once, using an off-the-shelf component library will allow you to understand what they do internally, and you'll be able to troubleshoot issues yourself.

There's another detail that frontend developers might not realize: Markdown rendering is a hard requirement in AI chat. The content returned by LLMs often includes code blocks, tables, lists, bold text, and links. The message bubble component you write needs to support Markdown rendering. And frontend developers are very familiar with Markdown rendering—marked + highlight.js, or just use markdown-it, done in three lines of code. You've used it countless times in tech blogs and documentation sites.

// AI message bubble component — supports Markdown rendering
// MessageBubble.vue
<script setup lang="ts">
import { marked } from 'marked'
import { computed } from 'vue'

const props = defineProps<{ message: ChatMessage }>()

// Use marked to convert Markdown to HTML
const htmlContent = computed(() => {
  if (props.message.role === 'assistant') {
    return marked(props.message.content, { breaks: true })
  }
  return props.message.content
})
</script>

<template>
  <div :class="['message-bubble', message.role]">
    <div v-if="message.role === 'assistant'" v-html="htmlContent" />
    <div v-else>{{ message.content }}</div>
  </div>
</template>

See? Markdown rendering, code highlighting, dark mode adaptation—these are things frontend developers have done countless times, and they are all needed in AI chat. And frontend developers do these things much faster and better than backend developers. Because frontend developers are closest to the users and know best what kind of interactive experience is good.

Summary

The frontend development of AI Agent applications is essentially these four things: "streaming data rendering + state management + user experience optimization + component-based decomposition." And in these four areas, frontend engineers have accumulated years of experience. So, don't think that being a "page writer" means you can't do AI—on the contrary, what AI applications lack most are frontend developers who can deliver a great user experience. Your skill set is very scarce in AI application development.

AI Agents Are Not Magic, Just "Programs That Can Do Things on Their Own"

When talking about AI Agents, many people picture scenes from sci-fi movies: an all-powerful AI that can chat with you, book flights for you, write code for you, and even fall in love with you. Frankly, this imagination isn't entirely wrong, but it's still a bit far from our current technological reality.

The AI Agents that can be implemented today are essentially just "programs that can do things on their own." The difference between them and regular programs is that regular programs only execute according to the if-else logic you write, whereas an Agent can "think" for itself about what to do next.

Let's use an analogy. Think of a regular program as an "obedient robot"—you give it a remote control; press "forward" and it goes forward, press "left turn" and it turns left. If you don't press anything, it doesn't move. An Agent is a "smart robot"—you say, "Go to the kitchen and get me a bottle of water," and it knows on its own: first identify where the "kitchen" is, then plan a route to get there, open the fridge, get the water, and come back.

Let's compare with more specific scenarios:

Scenario Regular Program AI Agent
User asks "What's the weather like in Beijing tomorrow?" You have to hardcode the keyword "weather" and then call a weather API. If the user phrases it differently, like "Is it hot in Beijing tomorrow?", it won't be recognized. You'd have to write a huge keyword matching table; if the user's phrasing changes, the program breaks. The Agent understands the user's intent, decides for itself "I need to check the weather," then calls the weather API, and finally replies to the user in natural language. No matter how the user asks, as long as the intent is "check weather," the Agent can handle it.
User says "Book me a flight to Shanghai for tomorrow morning, the cheaper the better." You have to write a form for the user to fill in: departure city, destination, date, time preference, price range. Then submit step by step. The user has to understand your form logic, not the other way around. The Agent understands "tomorrow," "to Shanghai," "morning," "cheap," automatically extracts the parameters, calls the flight API, and returns the results. If information is missing (like the departure city wasn't stated), the Agent will ask the user to confirm.
User says "Help me write a report on last week's sales data and email it to my boss." You have to write three separate subsystems: a data query interface, a report template renderer, and an email sending interface. And each step requires manual triggering by the user, with no connection between the processes. The Agent queries the database itself → analyzes the data → generates the report → calls the email API to send it. The entire process is automated. The user just says one sentence, and the Agent plans and executes the steps itself.

See the difference? Regular programs are "dead"—they do exactly what you write. An Agent is "alive"—it can understand user intent, decide for itself what to do, and then call tools to execute.

So how does an Agent "think for itself"? Actually, when you break it down, it's just four core components, all indispensable:

The Four Core Components of an Agent

1. Brain (LLM — Large Language Model): Responsible for understanding user intent and making decisions. Examples include ChatGPT, Claude, DeepSeek, Tongyi Qianwen. You send it what the user said, and it tells you "what the user wants" and "which tool to call."

2. Tools: The Agent's hands and feet. They can check the weather, send emails, search databases, call APIs—anything that can be done via code can be wrapped as an Agent tool. Tools define the boundary of the Agent's capabilities; the more tools, the more powerful the Agent.

3. Memory: Short-term memory is the conversation history (what was just said), and long-term memory is knowledge stored in a database (user preferences, historical summaries). With memory, the Agent can remember what you said before, so it doesn't act like it's meeting you for the first time every time.

4. Planning: Complex tasks need to be broken down into steps. For example, "Help me write a competitive analysis report"—the Agent needs to first search for competitor information, then organize the data, then generate the report, and finally output it. It has to plan for itself "what to do first, what to do next."

Put these four components together, and you have a working Agent. Doesn't sound so mysterious, does it?

Moreover, implementing a minimal version of an Agent requires far less code than you might think. Let's write one directly:

// A simplest AI Agent, less than 50 lines of code
// Function: User asks about the weather, Agent automatically calls the weather API to answer
// Before running: npm install openai

import OpenAI from 'openai'

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY })

// Step 1: Define the tools the Agent can use
// Each tool includes: name, description, parameter definition (JSON Schema format)
const tools = [
  {
    type: 'function' as const,
    function: {
      name: 'get_weather',
      description: 'Get weather information for a specified city',
      parameters: {
        type: 'object',
        properties: {
          city: { type: 'string', description: 'City name, e.g., "Beijing"' }
        },
        required: ['city']
      }
    }
  }
]

// Step 2: Implement the actual logic of the tool
// In a real project, this would call a real weather API
async function getWeather(city: string): Promise<string> {
  // Simulate returning weather data
  // In production, replace with: fetch(`https://api.weather.com?city=${city}`)
  return `${city} is sunny today, 25°C, humidity 60%, suitable for going out`
}

// Step 3: Agent main loop — this is the core logic of the Agent
async function agentRun(userMessage: string) {
  const messages: any[] = [{ role: 'user', content: userMessage }]

  // Send the user message to the LLM, let it decide whether to call a tool
  const response1 = await client.chat.completions.create({
    model: 'gpt-4',
    messages,
    tools  // Tell the LLM what tools are available
  })

  const toolCall = response1.choices[0].message.tool_calls?.[0]

  // If the LLM decides to call a tool
  if (toolCall && toolCall.function.name === 'get_weather') {
    // Parse the parameters extracted by the LLM (e.g., city: "Beijing")
    const args = JSON.parse(toolCall.function.arguments)
    const weatherResult = await getWeather(args.city)

    // Send the tool execution result back to the LLM to generate the final reply
    messages.push(response1.choices[0].message)  // LLM's "I want to call a tool" decision
    messages.push({
      role: 'tool',
      tool_call_id: toolCall.id,
      content: weatherResult  // The result returned by the tool
    })

    const response2 = await client.chat.completions.create({
      model: 'gpt-4',
      messages
    })

    return response2.choices[0].message.content
  }

  // LLM thinks no tool is needed, return its reply directly
  return response1.choices[0].message.content
}

// Try it out
const answer = await agentRun('What is the weather like in Beijing today?')
console.log(answer)
// Output: "Beijing's weather is nice today! Sunny, 25°C, humidity 60%, perfect for going out~"

See? With just a few dozen lines of code, an Agent that can automatically call tools is set up. No magic, no black boxes, just a three-step cycle of "LLM makes a decision → Agent executes an action → LLM generates a reply." This cycle is the core working principle of an Agent. All the chapters that follow, covering "tool calling," "workflow orchestration," and "multi-agent collaboration," are essentially extensions and variations of this cycle.

Of course, this example is too simplistic. In a real project, you have to handle many details:

But these details will be dissected and explained in every subsequent chapter. For now, you just need to remember one thing: The essence of an Agent is very simple: it's about giving an LLM the ability to "do things." It's not magic; it's just a program—a program you are fully capable of writing.

Oh, and did you notice the definition of the get_weather tool in the Agent code above? Pay attention to its parameter format:

{
  type: 'function',
  function: {
    name: 'get_weather',
    description: 'Get weather information for a specified city',
    parameters: {
      type: 'object',
      properties: {
        city: { type: 'string', description: 'City name, e.g., "Beijing"' }
      },
      required: ['city']
    }
  }
}

This format is called JSON Schema, which is the Function Calling specification defined by OpenAI. You don't need to handwrite this JSON, but you need to understand its meaning—it tells the LLM: "Hey, you have a tool called get_weather you can use; it requires a city parameter, which is a string type." Seeing this description, the LLM knows that when a user asks about the weather, it should call this tool and pass the city name as a parameter.

This mechanism is the underlying principle that allows AI Agents to "do things." It's not some magical black box, but a clearly defined, well-formatted interface contract. Your job as a developer is to define the tools well, implement them well, and then send the tool list to the LLM. The LLM will decide for itself when to use which tool.

Tech Stack Choice: Why Vue3 + NestJS + TypeScript Is a Killer Combination?

Nine out of ten AI Agent tutorials on the market use Python. There's nothing wrong with that per se; the Python ecosystem is indeed the most mature in the AI field—frameworks like LangChain, LlamaIndex, and AutoGen were all Python-first. But the problem is—you are a frontend developer; what you know best is JavaScript/TypeScript, not Python.

Making you learn Agent development while simultaneously learning Python, plus Python's web frameworks (FastAPI, Flask), plus Python's async programming (asyncio), plus Python's type system (Pydantic), plus Python's deployment methods (Gunicorn, Uvicorn)... this learning curve is as steep as a cliff. And after learning it all, the Python code is disconnected from your existing frontend projects—you can't easily use TypeScript for the frontend and Python for the backend in the same project, or rather you can, but the maintenance cost is too high, requiring two sets of type definitions.

So in this booklet, we've chosen a most frontend-friendly tech path:

Frontend: Vue3 (Composition API + TypeScript + Pinia) └── You're already using it; no extra learning needed, just use your familiar tools Backend: NestJS (Node.js enterprise-grade framework) └── Uses TypeScript, the same language as the frontend; its decorator style is like Vue3's

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

糖墨夕

More content synced on the public Number