sanbuphy
47377646df
refactor(demos): improve variable box, scope, and type annotation demos style(demos): update visual styles and animations for better UX docs(browser-as-os): restructure content with tables and practical examples feat(demos): add new TypeScript and runtime environment demos
705 lines
21 KiB
Markdown
705 lines
21 KiB
Markdown
# 前端框架深度指南
|
||
|
||
::: tip 前言
|
||
你已经学会了 HTML、CSS 和 JavaScript 基础，能做出简单的网页了。但随着网页功能越来越复杂，你可能会发现：用原生 JavaScript 写代码变得很难维护，改一处要动很多地方，多人协作时经常冲突。
|
||
|
||
这就是我们需要前端框架的原因——它让代码更有条理、更易维护、更高效开发。在 vibecoding 里，AI 会帮你写大部分代码。但你至少得能看懂不同框架的代码风格，知道它们的优缺点，这样 AI 才能帮你选择最合适的技术栈。
|
||
|
||
读完这篇，你就能：
|
||
- 理解前端技术为什么要不断演进
|
||
- 知道 Vue、React、Svelte、Angular 各有什么特点
|
||
- 懂得"数据驱动"、"组件化"这些核心概念
|
||
- 能根据项目选择合适的框架
|
||
:::
|
||
|
||
**这篇文章会带你学什么？**
|
||
|
||
| 章节 | 内容 | 学完能干嘛 |
|
||
|-----|------|-----------|
|
||
| **第 1 章** | 为什么要关注前端演进 | 明白技术演进是为了解决什么问题 |
|
||
| **第 2 章** | 静态网页时代 | 了解最早期的网页开发方式 |
|
||
| **第 3 章** | jQuery 时代 | 理解"命令式"编程的痛点 |
|
||
| **第 4 章** | Vue/React 时代 | 掌握"声明式"和"数据驱动"思想 |
|
||
| **第 5 章** | 渲染策略 | 知道 CSR、SSR、SSG 的区别和适用场景 |
|
||
| **第 6 章** | 工程化工具 | 理解 Webpack、Vite 等构建工具的作用 |
|
||
|
||
每一章都从"为什么需要这个技术"开始，让你理解技术演进背后的逻辑。
|
||
|
||
---
|
||
|
||
## 1. 为什么要关注前端演进史?
|
||
|
||
::: tip 🤔 核心问题
|
||
**为什么网页越来越复杂？前端技术为什么要不断演进？** 这个问题会带你理解从简单网页到现代 Web 应用的技术演变之路。
|
||
:::
|
||
|
||
### 1.1 从"电子海报"到"桌面应用"
|
||
|
||
想象一下你在街上看到的**海报**：
|
||
|
||
- ✅ 有内容（文字、图片）
|
||
- ✅ 有设计（颜色、排版）
|
||
- ❌ 但你跟它说话，它不会回应
|
||
- ❌ 你点击某个地方，不会发生什么
|
||
|
||
**最早的网页**就是这样的"电子海报"：只能看、不能改、内容固定。
|
||
|
||
**现代网页**完全不同了。它们像**桌面应用**（VS Code、Figma）：
|
||
|
||
- ✅ 可以编辑文档、画图、玩游戏
|
||
- ✅ 实时响应你的每个操作
|
||
- ✅ 甚至可以离线工作
|
||
|
||
**这种转变的核心原因：网页的功能越来越复杂，需要更高效的技术和开发方式。**
|
||
|
||
### 1.2 一个生活的比喻：盖房子
|
||
|
||
前端技术的演进，就像盖房子方式的进化：
|
||
|
||
| 时代 | 🏠 盖房比喻 | 实际特点 | 优缺点 |
|
||
|------|-----------|---------|--------|
|
||
| **2000s** | **贴海报** | 静态网页，写好 HTML 就行 | ✅ 简单 ❌ 不能互动 |
|
||
| **2010s** | **请工人手动装修** | jQuery 时代，手动操作每个元素 | ✅ 能互动 ❌ 代码乱、难维护 |
|
||
| **2020s** | **用乐高搭房子** | Vue/React 时代，组件化开发 | ✅ 高效、可维护 ❌ 学习曲线 |
|
||
|
||
::: tip 💡 从表格中你能看到什么？
|
||
|
||
**阶段一 → 阶段二**：从"不能动"到"能动"。这是质的飞跃——网页开始有交互，但代价是代码变得混乱。
|
||
|
||
**阶段二 → 阶段三**：从"能用"到"好用"。组件化让代码像积木一样可复用，大幅提升开发效率。
|
||
|
||
**核心思想**：技术演进不是"为了新而新"，而是为了解决上一个阶段的痛点。
|
||
:::
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 2. 第一阶段：静态网页与"切图"（2000s）
|
||
|
||
::: tip 🤔 核心问题
|
||
**最早的网页是什么样的？为什么那时候不需要框架？** 理解这个阶段的局限性，才能明白后来技术演进的必要性。
|
||
:::
|
||
|
||
<FrontendEvolutionDemo />
|
||
|
||
### 2.1 这个时代是什么样的？
|
||
|
||
**开发方式**：
|
||
|
||
- 写几个 HTML 文件
|
||
- 内嵌一些 CSS 和 JavaScript
|
||
- 直接把文件拖到浏览器就能看效果
|
||
- 上传文件夹到服务器就完成部署
|
||
|
||
**特点**：
|
||
|
||
- ✅ **优点**：简单直接，没有学习成本，写完就能跑
|
||
- ❌ **缺点**：无法实现复杂交互，代码一多就乱
|
||
|
||
::: details 查看当时的项目结构
|
||
|
||
```
|
||
project/
|
||
├── index.html
|
||
├── login.html
|
||
├── css/
|
||
│ ├── bootstrap.css
|
||
│ └── custom.css
|
||
├── js/
|
||
│ ├── jquery.js
|
||
│ └── app.js
|
||
└── images/
|
||
```
|
||
|
||
**遇到的问题**：
|
||
|
||
1. **全局变量污染**：所有变量都在全局命名空间，容易互相覆盖
|
||
2. **依赖管理混乱**：必须按正确顺序加载 JS 文件，否则会报错
|
||
3. **代码难以复用**：想复用某个功能，只能复制粘贴
|
||
:::
|
||
|
||
### 2.2 "切图"是什么？
|
||
|
||
你可能听说过"切图"这个词。它是早期前端的主要工作：
|
||
|
||
**什么是切图？**
|
||
|
||
设计师用 Photoshop 设计好页面 → 前端把设计切成小图片 → 用 HTML 把图片拼成页面
|
||
|
||
**为什么这么慢？**
|
||
|
||
网页上的每张小图片，浏览器都要发一次**网络请求**。请求越多，加载越慢。
|
||
|
||
👇 **动手试试看**：观察图片请求对加载性能的影响
|
||
|
||
<SliceRequestDemo />
|
||
|
||
::: tip 💡 雪碧图（Sprite）
|
||
|
||
为了减少请求数，出现了"雪碧图"技术：把很多小图合成一张大图。
|
||
|
||
优点是请求数变少，缺点是制作和维护都很麻烦。
|
||
|
||
这个阶段的教训：**请求太多是性能大敌**。
|
||
:::
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 3. 第二阶段：jQuery 时代 - "手动搬砖"（2010s）
|
||
|
||
::: tip 🤔 核心问题
|
||
**为什么需要 jQuery？它解决了什么问题，又带来了什么新问题？** 理解 jQuery 的局限性，才能明白 Vue/React 的价值。
|
||
:::
|
||
|
||
### 3.1 为什么需要 jQuery？
|
||
|
||
随着网页变复杂，原生 JavaScript 的问题暴露出来：
|
||
|
||
- ❌ **API 繁琐**：简单的操作也要写很多代码
|
||
- ❌ **浏览器兼容**：不同浏览器的 API 不一样，要写很多兼容代码
|
||
- ❌ **选择器弱**：找元素很麻烦
|
||
|
||
**jQuery** 诞生了。它让 JavaScript 变得简单：
|
||
|
||
```javascript
|
||
// 原生 JavaScript（繁琐）
|
||
const element = document.getElementById('title')
|
||
|
||
// jQuery（简洁）
|
||
const element = $('#title')
|
||
```
|
||
|
||
### 3.2 jQuery 的思路：亲手改页面
|
||
|
||
jQuery 的核心思路是**命令式**：你告诉浏览器"怎么做"。
|
||
|
||
```javascript
|
||
// 找到标题元素
|
||
$('#title').text('新标题')
|
||
|
||
// 找到按钮并禁用
|
||
$('#submit-btn').attr('disabled', true)
|
||
|
||
// 找到列表并添加一项
|
||
$('ul').append('<li>新项目</li>')
|
||
```
|
||
|
||
**问题**：你需要记住页面上有哪些元素，每次数据变化都要手动更新所有相关元素。
|
||
|
||
👇 **动手试试看**：对比 jQuery 和数据驱动的方式
|
||
|
||
<JQueryVsStateDemo />
|
||
|
||
::: warning ⚠️ jQuery 的痛点
|
||
|
||
想象你在做一个购物车：
|
||
|
||
```javascript
|
||
// 用户点击"添加到购物车"
|
||
function addToCart() {
|
||
cartCount++ // 数据变化
|
||
|
||
// 你要手动更新所有相关地方
|
||
$('#cart-count').text(cartCount) // 右上角小红点
|
||
$('#cart-page-count').text(cartCount) // 购物车页面
|
||
$('#checkout-price').text(calculatePrice()) // 结算按钮
|
||
|
||
// 如果漏了一个地方，页面就不一致了！
|
||
}
|
||
```
|
||
|
||
**这就是"手动搬砖"的代价**：容易出错，难以维护。
|
||
:::
|
||
|
||
### 3.3 移动端普及：响应式设计的出现
|
||
|
||
这个阶段还有一个重要变化：**手机和平板开始流行**。
|
||
|
||
网页必须适配不同屏幕。这需要**响应式布局**：同一套 HTML/CSS，自动根据屏幕宽度变换布局。
|
||
|
||
**响应式布局的核心：媒体查询（Media Query）**
|
||
|
||
```css
|
||
/* 电脑屏幕（大于 640px） */
|
||
@media (min-width: 640px) {
|
||
.container {
|
||
display: flex;
|
||
}
|
||
}
|
||
|
||
/* 手机屏幕（小于 640px） */
|
||
@media (max-width: 640px) {
|
||
.container {
|
||
display: block;
|
||
}
|
||
}
|
||
```
|
||
|
||
👇 **动手试试看**：调整浏览器宽度，观察响应式布局的效果
|
||
|
||
<ResponsiveGridDemo />
|
||
|
||
::: tip 💡 响应式就像"智能相框"
|
||
|
||
想象你在不同房间看同一张照片：
|
||
|
||
- 在**大客厅**（电脑屏幕），照片可以摆大一些，旁边还能放其他装饰品
|
||
- 在**小卧室**（手机屏幕），照片需要缩小，其他装饰品要收起来
|
||
|
||
**响应式布局**就是"智能相框"，它会自动根据房间大小调整展示方式。
|
||
:::
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 4. 第三阶段：从"手动搬砖"到"数据驱动"（Vue/React）
|
||
|
||
::: tip 🤔 核心问题
|
||
**为什么需要 Vue/React？它们和 jQuery 的本质区别是什么？** 理解"声明式"和"数据驱动"，是掌握现代前端框架的关键。
|
||
:::
|
||
|
||
### 4.1 为什么需要新框架？
|
||
|
||
jQuery 时代的问题积累到一定程度：
|
||
|
||
- **代码一多就乱**：到处都是 DOM 操作，难以维护
|
||
- **容易出 bug**：漏更新一个地方，页面就不一致
|
||
- **协作困难**：多人修改同一个文件，容易冲突
|
||
|
||
**Vue / React** 的核心思路：**只改数据，页面自动更新**。
|
||
|
||
### 4.2 Vue/React 的思路：声明式 UI
|
||
|
||
**jQuery（命令式）**：
|
||
|
||
```javascript
|
||
// 你要告诉浏览器每一步怎么做
|
||
$('#title').text('新标题')
|
||
$('#title').css('color', 'red')
|
||
$('#title').show()
|
||
```
|
||
|
||
**Vue（声明式）**：
|
||
|
||
```javascript
|
||
// 你只需告诉浏览器"要显示什么"
|
||
data() {
|
||
return {
|
||
title: "新标题",
|
||
color: "red",
|
||
visible: true
|
||
}
|
||
}
|
||
```
|
||
|
||
👇 **动手试试看**：对比命令式和声明式的区别
|
||
|
||
<ImperativeVsDeclarativeDemo />
|
||
|
||
::: tip 💡 命令式 vs 声明式
|
||
|
||
就像画一幅画：
|
||
|
||
- **命令式**：你告诉画家"拿起笔，蘸红颜料，在坐标（10,10）画一个圈"
|
||
- **声明式**：你直接给画家一张照片，"给我画成这样"
|
||
|
||
Vue/React 就是"声明式"：你描述"页面长什么样"，框架负责"怎么把它画出来"。
|
||
:::
|
||
|
||
### 4.3 组件化：像搭乐高一样写页面
|
||
|
||
**Vue / React** 最强大的特性是**组件化**：把页面拆成一个个独立的"积木"。
|
||
|
||
想象一下你在搭乐高：
|
||
|
||
- 你不需要"从头开始雕刻每一块积木"（从头写 HTML/CSS）
|
||
- 你只需要"按说明书把积木拼在一起"（把组件组合起来）
|
||
- 每个积木都是**独立的**，你可以在不同的套装里**重复使用**
|
||
|
||
**组件的好处**：
|
||
|
||
- **复用**：写一个"商品卡片"组件，可以用 100 次
|
||
- **封装**：组件内部的状态不影响别人
|
||
- **维护**：修改一个组件，所有用到它的地方都会更新
|
||
|
||
::: info 💡 识别技巧
|
||
- 看到 `<ComponentName />` → 这是一个组件
|
||
- 看到 `import xxx from './xxx.vue'` → 在导入一个组件
|
||
- 看到 `props: {...}` → 组件接收的参数
|
||
- 看到 `emit('xxx')` → 组件向父组件发送事件
|
||
:::
|
||
|
||
### 4.4 SPA：单页应用的诞生
|
||
|
||
**Vue / React** 时代还有一个重要变化：**从 MPA 到 SPA**。
|
||
|
||
**MPA（Multi-Page Application）**：
|
||
|
||
- 点一个链接 → 整页刷新 → 显示新页面
|
||
- 就像**翻书**：每翻一页都要把旧书合上、去书架拿新书
|
||
|
||
**SPA（Single-Page Application）**：
|
||
|
||
- 点一个链接 → 只刷新内容区域 → 页面不刷新
|
||
- 就像**同一本书里换章节**：只擦掉旧内容、写上新内容
|
||
|
||
👇 **动手试试看**：体验 MPA 和 SPA 的区别
|
||
|
||
<RoutingModeDemo />
|
||
|
||
**SPA 的优点**：
|
||
|
||
- ✅ **体验丝滑**：页面切换快
|
||
- ✅ **状态好管理**：输入的内容、滚动位置都在
|
||
- ❌ **首屏可能慢**：需要先下载 JavaScript
|
||
- ❌ **SEO 要额外处理**：搜索引擎可能抓不到内容（需要 SSR/SSG）
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 5. 渲染策略：从 CSR 到 SSR/SSG
|
||
|
||
::: tip 🤔 核心问题
|
||
**页面是在服务器生成，还是在浏览器生成？** 不同渲染策略各有优劣，选择合适的策略对性能和 SEO 至关重要。
|
||
:::
|
||
|
||
**CSR（Client-Side Rendering）客户端渲染**：
|
||
|
||
- 浏览器下载 JavaScript → 执行代码 → 生成页面
|
||
- 优点：交互流畅，服务器压力小
|
||
- 缺点：首屏慢，不利于 SEO
|
||
|
||
**SSR（Server-Side Rendering）服务端渲染**：
|
||
|
||
- 服务器生成 HTML → 发给浏览器 → 浏览器直接显示
|
||
- 优点：首屏快，利于 SEO
|
||
- 缺点：服务器压力大，实现复杂
|
||
|
||
**SSG（Static Site Generation）静态站点生成**：
|
||
|
||
- 构建时生成所有页面的 HTML
|
||
- 优点：极快，完全静态，CDN 友好
|
||
- 缺点：不适合动态内容
|
||
|
||
👇 **动手试试看**：对比不同渲染策略的特点
|
||
|
||
<RenderingStrategyDemo />
|
||
|
||
::: info 💡 如何选择？
|
||
- **内容网站**（博客、文档）：优先 SSG
|
||
- **需要 SEO 的动态网站**（电商、新闻）：使用 SSR
|
||
- **后台管理系统**：使用 CSR
|
||
- **混合需求**：考虑 Nuxt/Next.js 的混合渲染
|
||
:::
|
||
|
||
---
|
||
|
||
## 6. 第四阶段：工程化与构建工具（2015s-2020s）
|
||
|
||
::: tip 🤔 核心问题
|
||
**为什么前端需要"工程化"？构建工具到底在做什么？** 理解工程化，才能看懂现代前端项目的工作流程。
|
||
:::
|
||
|
||
### 6.1 为什么需要"工程化"？
|
||
|
||
前端项目越来越大，不能再靠"手动引入脚本"。
|
||
|
||
**工程化**就是用工具和规范，让开发更高效、代码更可靠、协作更顺畅。
|
||
|
||
::: tip 💡 工程化 = 从"手工作坊"到"现代化工厂"
|
||
|
||
想象一下你在家做饭 vs 开餐厅：
|
||
|
||
- **在家做饭**：想吃什么就做什么，很自由
|
||
- **开餐厅**：需要标准化的菜谱、规范的操作流程、统一的原材料采购
|
||
|
||
前端开发也一样：
|
||
|
||
- **小项目**：怎么写都行
|
||
- **大项目**：需要统一的代码规范、自动化工具、标准化流程
|
||
:::
|
||
|
||
### 6.2 构建工具：Webpack → Vite
|
||
|
||
**Webpack**（传统）：
|
||
|
||
- 工作方式：**先打包，后服务**
|
||
- 启动时：打包所有代码 → 启动服务器
|
||
- 问题：**慢**。项目越大，启动越慢（可能要等 30 秒）
|
||
|
||
**Vite**（现代）：
|
||
|
||
- 工作方式：**按需编译**
|
||
- 启动时：不打包，直接启动服务器
|
||
- 浏览器请求哪个文件，就实时编译哪个
|
||
- 优势：**快**。通常 1 秒内启动
|
||
|
||
| 对比项 | Webpack | Vite | 提升 |
|
||
|--------|---------|------|------|
|
||
| 冷启动 | 30s+ | <1s | **快 30 倍** |
|
||
| 热更新 | 3-5s | <100ms | **快 30 倍** |
|
||
| 配置文件 | 几百行 | 几十行 | **大幅简化** |
|
||
|
||
::: tip 💡 为什么 Vite 这么快？
|
||
|
||
**Webpack** 就像**整备家当搬家**：先把所有东西打包，再出门。
|
||
|
||
**Vite** 就像**轻装旅行**：只带必需品，用到什么再买什么。
|
||
|
||
在开发环境，大多数时候你只需要修改几个文件，Vite 只编译这几个文件，当然快。
|
||
:::
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 7. 主流框架对比
|
||
|
||
::: tip 🤔 核心问题
|
||
**Vue、React、Svelte、Angular 各有什么特点？如何选择适合自己的框架？** 了解它们的设计理念和使用场景，才能做出明智的选择。
|
||
:::
|
||
|
||
### 7.1 四大框架对比
|
||
|
||
| 特性 | Vue | React | Svelte | Angular |
|
||
|------|-----|-------|--------|---------|
|
||
| **设计理念** | 渐进式框架 | UI 库 | 编译时框架 | 完整平台 |
|
||
| **学习曲线** | ⭐⭐ 简单 | ⭐⭐⭐ 中等 | ⭐⭐ 简单 | ⭐⭐⭐⭐ 陡峭 |
|
||
| **性能** | 快 | 快 | **极快** | 快 |
|
||
| **生态系统** | 完善 | **最完善** | 成长中 | 完善 |
|
||
| **包大小** | 小 | 中等 | **最小** | 大 |
|
||
| **适合场景** | 中小型项目 | 大型项目 | 性能要求高 | 企业级应用 |
|
||
| **公司支持** | 尤雨溪（独立） | Meta | 社区 | Google |
|
||
|
||
### 7.2 Vue：渐进式框架
|
||
|
||
**核心理念**：渐进式采用，可以只用一部分，也可以用全家桶
|
||
|
||
```vue
|
||
<template>
|
||
<div>{{ message }}</div>
|
||
</template>
|
||
|
||
<script>
|
||
export default {
|
||
data() {
|
||
return {
|
||
message: 'Hello Vue'
|
||
}
|
||
}
|
||
}
|
||
</script>
|
||
```
|
||
|
||
**优点**：
|
||
- ✅ 学习曲线平缓，中文文档完善
|
||
- ✅ 模板语法直观，易于理解
|
||
- ✅ 单文件组件（.vue）结构清晰
|
||
- ✅ 适合快速开发
|
||
|
||
**缺点**：
|
||
- ❌ 大型项目的状态管理需要额外学习 Vuex/Pinia
|
||
- ❌ 灵活性略逊于 React
|
||
|
||
**适用场景**：
|
||
- 中小型 Web 应用
|
||
- 快速原型开发
|
||
- 中文团队（文档友好）
|
||
|
||
### 7.3 React：UI 库
|
||
|
||
**核心理念**：只负责视图层，其他问题交给社区
|
||
|
||
```jsx
|
||
function App() {
|
||
const [message, setMessage] = useState('Hello React')
|
||
return <div>{message}</div>
|
||
}
|
||
```
|
||
|
||
**优点**：
|
||
- ✅ 生态系统最完善，组件库丰富
|
||
- ✅ JSX 语法灵活，表达能力强大
|
||
- ✅ 虚拟 DOM 性能优秀
|
||
- ✅ 适合大型项目
|
||
|
||
**缺点**：
|
||
- ❌ 学习曲线较陡，需要掌握额外概念
|
||
- ❌ 需要自己选择和搭配各种库
|
||
- ❌ JSX 需要编译，不能直接在浏览器运行
|
||
|
||
**适用场景**：
|
||
- 大型复杂应用
|
||
- 需要丰富生态的项目
|
||
- 跨平台开发（React Native）
|
||
|
||
### 7.4 Svelte：编译时框架
|
||
|
||
**核心理念**：没有虚拟 DOM，编译时将组件转换为高效的原生代码
|
||
|
||
```svelte
|
||
<script>
|
||
let message = 'Hello Svelte'
|
||
</script>
|
||
|
||
<div>{message}</div>
|
||
```
|
||
|
||
**优点**：
|
||
- ✅ **性能最优**（无虚拟 DOM 运行时开销）
|
||
- ✅ 包体积最小
|
||
- ✅ 语法简单直观
|
||
- ✅ 响应式系统天然支持
|
||
|
||
**缺点**：
|
||
- ❌ 生态相对较小
|
||
- ❌ 社区规模不如 Vue/React
|
||
- ❌ 第三方库较少
|
||
|
||
**适用场景**：
|
||
- 性能要求极高的应用
|
||
- 包体积敏感的项目
|
||
- 愿意尝试新技术的团队
|
||
|
||
### 7.5 Angular：完整平台
|
||
|
||
**核心理念**：提供完整的解决方案，开箱即用
|
||
|
||
```typescript
|
||
@Component({
|
||
selector: 'app-root',
|
||
template: '<div>{{ message }}</div>'
|
||
})
|
||
export class AppComponent {
|
||
message = 'Hello Angular'
|
||
}
|
||
```
|
||
|
||
**优点**：
|
||
- ✅ 功能完整，路由、HTTP、表单全都有
|
||
- ✅ TypeScript 原生支持
|
||
- ✅ 适合大型团队和项目
|
||
- ✅ 代码规范统一
|
||
|
||
**缺点**：
|
||
- ❌ 学习曲线陡峭
|
||
- ❌ 概念多，复杂度高
|
||
- ❌ 包体积大
|
||
- ❌ 不适合小型项目
|
||
|
||
**适用场景**：
|
||
- 大型企业级应用
|
||
- 需要严格规范的团队
|
||
- 已有 TypeScript 技术栈的项目
|
||
|
||
---
|
||
|
||
## 8. 总结：演进的本质
|
||
|
||
前端技术的演进，本质上是在解决两个问题：
|
||
|
||
### 8.1 效率：从手动到自动
|
||
|
||
| 时代 | 开发方式 | 效率 |
|
||
|------|---------|------|
|
||
| **2000s** | 手写 HTML/CSS/JS | ⭐ |
|
||
| **2010s** | jQuery + 手动 DOM 操作 | ⭐⭐ |
|
||
| **2020s** | Vue/React + 数据驱动 | ⭐⭐⭐ |
|
||
| **现在** | 组件化 + 工程化 + 自动化 | ⭐⭐⭐⭐⭐ |
|
||
|
||
### 8.2 规模：从个人到团队
|
||
|
||
| 时代 | 项目规模 | 协作方式 |
|
||
|------|---------|---------|
|
||
| **2000s** | 几个文件 | 单人就能维护 |
|
||
| **2010s** | 几十个文件 | 小团队，容易冲突 |
|
||
| **2020s** | 几百个文件 | 中团队，需要规范 |
|
||
| **现在** | 几千个文件 | 大团队，需要完整工程体系 |
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 9. 学习路线图
|
||
|
||
### 9.1 如果你是零基础
|
||
|
||
**第 1 步：HTML/CSS/JavaScript 基础**
|
||
|
||
- 理解网页的三大基石
|
||
- 能写出简单的静态页面
|
||
|
||
**第 2 步：学习一个框架（Vue 推荐）**
|
||
|
||
- 理解"数据驱动"的思想
|
||
- 掌握组件化开发
|
||
|
||
**第 3 步：实战项目**
|
||
|
||
- 做一个完整的单页应用
|
||
- 熟悉路由、状态管理、API 调用
|
||
|
||
### 9.2 如果你有基础
|
||
|
||
**进阶方向**：
|
||
|
||
- **工程化**：学习 Vite/Webpack，理解构建流程
|
||
- **性能优化**：学习懒加载、代码分割、缓存策略
|
||
- **TypeScript**：为代码加上类型，提升可靠性
|
||
- **服务端渲染**：学习 Nuxt/Next.js，解决 SEO 和首屏问题
|
||
|
||
---
|
||
|
||
## 10. 你现在应该能识别的代码
|
||
|
||
通过阅读本章，你应该能够：
|
||
|
||
- ✅ 理解前端技术演进的脉络和原因
|
||
- ✅ 区分 Vue、React、Svelte、Angular 的特点
|
||
- ✅ 理解"命令式"和"声明式"的区别
|
||
- ✅ 掌握"数据驱动"的核心思想
|
||
- ✅ 知道组件化开发的价值
|
||
- ✅ 了解 CSR、SSR、SSG 的适用场景
|
||
- ✅ 理解构建工具（Webpack、Vite）的作用
|
||
- ✅ 能根据项目选择合适的框架和技术栈
|
||
|
||
::: info 💡 实际应用
|
||
当你用 AI 做项目时，你可以这样告诉它：
|
||
|
||
- "这是一个需要 SEO 的博客网站，用 Nuxt（Vue 的 SSR 框架）"
|
||
- "这是一个后台管理系统，用 Vue + Element Plus，不需要 SSR"
|
||
- "这是一个性能要求高的 Web 应用，考虑使用 Svelte"
|
||
- "项目已经用 React 了，继续用 React 生态的库"
|
||
:::
|
||
|
||
---
|
||
|
||
## 名词速查表
|
||
|
||
| 名词 | 英文 | 用人话解释 |
|
||
|------|------|-----------|
|
||
| **DOM** | Document Object Model | 文档对象模型。用对象树表示页面，可被 JS 读写。 |
|
||
| **jQuery** | - | 早期流行的 JS 库，简化了 DOM 操作。 |
|
||
| **Vue/React** | - | 现代前端框架，采用数据驱动和组件化开发。 |
|
||
| **组件** | Component | 可复用的 UI 单元，如按钮、卡片、导航栏。 |
|
||
| **MPA** | Multi-Page Application | 多页应用。每次跳转都重新加载整个页面。 |
|
||
| **SPA** | Single-Page Application | 单页应用。只加载一次，后续切换不刷新页面。 |
|
||
| **路由** | Routing | 管理页面之间切换的规则和过程。 |
|
||
| **SSR** | Server-Side Rendering | 服务端渲染。服务器生成 HTML 后发给浏览器。 |
|
||
| **SSG** | Static Site Generation | 静态站点生成。构建时预渲染页面为静态 HTML。 |
|
||
| **CSR** | Client-Side Rendering | 客户端渲染。浏览器通过 JS 生成页面。 |
|
||
| **Webpack** | - | 传统打包工具，先打包后服务。 |
|
||
| **Vite** | - | 现代构建工具，按需编译，速度极快。 |
|
||
| **响应式** | Responsive Design | 页面自动适配不同屏幕尺寸的设计。 |
|
||
| **媒体查询** | Media Query | CSS 的条件判断，根据屏幕宽度应用不同样式。 |
|
||
| **命令式** | Imperative | 告诉程序"怎么做"。 |
|
||
| **声明式** | Declarative | 告诉程序"要什么"。 |
|
||
| **数据驱动** | Data-Driven | 只修改数据，界面自动更新。 |
|
||
| **Tree Shaking** | - | 摇树优化。自动移除未使用的代码，减小包体积。 |
|
||
| **代码分割** | Code Splitting | 把代码分成多个小块，按需加载。 |
|