Skip to content

Commit 864a957

Browse files
xiaozhua-bitxiaozhua-bit
committed
feat: add knowledge base pages for seo
1 parent 1704b8e commit 864a957

8 files changed

Lines changed: 533 additions & 0 deletions

‎pages/_meta.js‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,10 @@ export default {
1313
title: "Docs",
1414
type: "page"
1515
},
16+
kb: {
17+
title: "Knowledge Base",
18+
type: "page"
19+
},
1620
blog: {
1721
title: "Blog",
1822
type: "page"

‎pages/kb/_meta.js‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
export default {
2+
index: {
3+
title: "Knowledge Base"
4+
},
5+
"what-is-crdt": "What Is a CRDT?",
6+
"loro-vs-yjs": "Loro vs Yjs",
7+
"crdt-library-comparison": "CRDT Library Comparison",
8+
"build-collaborative-editor": "Build a Collaborative Editor",
9+
"crdt-time-travel": "CRDT Time Travel"
10+
}

‎pages/kb/build-collaborative-editor.mdx‎

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
---
2+
title: "How to Build a Collaborative Editor with CRDTs"
3+
description: "Learn the key architecture decisions behind building a collaborative editor, including document model, sync, offline support, conflict resolution, and version history."
4+
keywords: "build collaborative editor, collaborative text editor architecture, real-time editor crdt, collaborative editing tutorial"
5+
---
6+
7+
# How to Build a Collaborative Editor with CRDTs
8+
9+
Building a collaborative editor is not just about broadcasting keystrokes. A real product has to survive concurrent edits, reconnect after network loss, preserve document structure, and help users recover from mistakes.
10+
11+
CRDTs are often a strong fit because they let each client update locally and synchronize later while still converging on the same document state.
12+
13+
## What a collaborative editor actually needs
14+
15+
At minimum, you need:
16+
17+
- a document model for the shared content
18+
- a sync layer to move updates between clients
19+
- a persistence layer so state survives app restarts and reconnects
20+
- presence / awareness for cursors, selections, and who is online
21+
- a history model for undo, restore, and version inspection
22+
- auth and permissions so not everyone can mutate everything
23+
24+
## Why CRDTs are a good fit
25+
26+
CRDTs help with the core document-state problem:
27+
28+
- multiple users edit concurrently
29+
- clients may be offline temporarily
30+
- updates can arrive in different orders
31+
- all replicas still need to converge
32+
33+
## What CRDTs solve — and what they do not
34+
35+
CRDTs help with shared document state, concurrent merge behavior, offline edits that sync later, and deterministic convergence.
36+
37+
They do **not** automatically solve authentication, authorization, presence, transport infrastructure, or product-specific permission flows.
38+
39+
## The core architecture pieces
40+
41+
A practical collaborative editor usually has these parts:
42+
43+
1. Document model
44+
2. Local editing state
45+
3. Sync transport
46+
4. Persistence
47+
5. Presence / awareness
48+
6. Version history
49+
50+
## Text editors vs structured editors
51+
52+
There is a big difference between a shared text buffer and a structured collaborative editor. If the product is trending toward structured content, pick a library that will not fight you later.
53+
54+
## Offline-first and reconnect behavior
55+
56+
A solid collaborative editor should handle:
57+
58+
- local edits while disconnected
59+
- replaying updates on reconnect
60+
- merging with remote edits safely
61+
- reloading large documents without bizarre corruption or duplicate state
62+
63+
## Why version history matters
64+
65+
If you stop at convergence, you get a collaborative system.
66+
If you add inspectable history and restore points, you start getting a trustworthy product.
67+
68+
## A practical stack with Loro
69+
70+
A simple architecture with Loro might look like this:
71+
72+
- client: editor UI + Loro document in memory
73+
- transport: WebSocket, WebRTC, or your own sync channel
74+
- backend: stores snapshots and/or updates, enforces auth and permissions
75+
- history UX: built on top of Loro's document history / time-travel capabilities
76+
77+
## Common mistakes when building collaborative editors
78+
79+
- treating presence like document state
80+
- only testing on perfect networks
81+
- forgetting recovery and versioning
82+
- choosing a data model that is too shallow
83+
84+
## What to read next
85+
86+
- [Get Started with Loro](/docs/tutorial/get_started)
87+
- [Learn how sync works](/docs/tutorial/sync)
88+
- [Explore Time Travel](/docs/tutorial/time_travel)
89+
- [Understand the CRDT basics](/kb/what-is-crdt)
90+
- [Loro vs Yjs](/kb/loro-vs-yjs)
91+
- [CRDT Library Comparison](/kb/crdt-library-comparison)

‎pages/kb/crdt-library-comparison.mdx‎

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
title: "CRDT Library Comparison: Loro vs Yjs vs Automerge"
3+
description: "A practical comparison of CRDT libraries including Loro, Yjs, and Automerge across ecosystem, language support, data models, local-first fit, and collaboration use cases."
4+
keywords: "crdt library comparison, best crdt library, yjs vs automerge vs loro, javascript crdt library"
5+
---
6+
7+
# CRDT Library Comparison
8+
9+
There is no single best CRDT library for every product. Real teams choose one for a specific product shape: a collaborative editor, a local-first document app, a structured knowledge tool, or a shared data layer with offline sync.
10+
11+
## Quick answer
12+
13+
Choose **Yjs** if ecosystem safety and editor integration depth matter most.
14+
15+
Choose **Automerge** if you are strongly local-first in philosophy and your use case leans toward general replicated app state.
16+
17+
Choose **Loro** if you want collaboration plus a stronger document history/time-travel story, especially for structured content.
18+
19+
## What to compare when choosing a CRDT library
20+
21+
Useful criteria:
22+
23+
- document model shape
24+
- ecosystem maturity
25+
- local-first fit
26+
- history / versioning story
27+
- long-term product fit vs fastest adoption
28+
29+
## Comparison overview
30+
31+
### Yjs
32+
33+
Strong JavaScript adoption, collaborative editor mindshare, mature ecosystem.
34+
35+
### Automerge
36+
37+
Strong local-first association and replicated app-state narrative.
38+
39+
### Loro
40+
41+
Richer structured document orientation, stronger emphasis on document history and time travel.
42+
43+
## Comparison table
44+
45+
| Dimension | Loro | Yjs | Automerge |
46+
| --- | --- | --- | --- |
47+
| Ecosystem maturity | Growing | Strongest today | Established but more niche in some workflows |
48+
| JavaScript mindshare | Moderate | Strong | Moderate |
49+
| Editor ecosystem gravity | Limited vs Yjs | Strongest | Lower than Yjs |
50+
| Structured document fit | Strong | Good | Good |
51+
| History / time-travel emphasis | Strong | Varies by surrounding architecture | Strong local-first narrative |
52+
53+
**TODO:** Replace directional wording with tighter, citation-backed capability statements where official docs give enough evidence.
54+
55+
## Best for JavaScript-first teams
56+
57+
Yjs has the clearest advantage today if you want the most familiar collaboration ecosystem.
58+
59+
## Best for local-first products
60+
61+
All three libraries can participate in local-first architectures, but they support different product stories.
62+
63+
## Best for document history and time travel
64+
65+
This is where Loro stands out most clearly.
66+
67+
## Best for editor integrations
68+
69+
If your main question is which library gives the broadest editor-oriented ecosystem and least surprising integration path, Yjs is usually the strongest answer.
70+
71+
## Where Loro is differentiated
72+
73+
Loro becomes more compelling when:
74+
75+
- the document is highly structured
76+
- tree-like or movable content matters
77+
- version history is user-facing
78+
- collaboration and restore/replay belong in the same product story
79+
80+
## Common mistakes when choosing a CRDT library
81+
82+
- picking on popularity alone
83+
- over-focusing on toy benchmarks
84+
- ignoring history until later
85+
- treating all collaborative apps as text editors
86+
87+
## What to read next
88+
89+
- [What Is a CRDT?](/kb/what-is-crdt)
90+
- [Loro vs Yjs](/kb/loro-vs-yjs)
91+
- [How to Build a Collaborative Editor](/kb/build-collaborative-editor)
92+
- [Get Started with Loro](/docs/tutorial/get_started)

‎pages/kb/crdt-time-travel.mdx‎

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
---
2+
title: "CRDT Time Travel: Version History for Local-First and Collaborative Apps"
3+
description: "See how CRDT time travel enables version history, undoable exploration, and Git-like document inspection in collaborative and local-first applications."
4+
keywords: "crdt time travel, document version history crdt, local-first version control, collaborative editing history"
5+
---
6+
7+
# CRDT Time Travel
8+
9+
Most collaboration content focuses on one thing: how multiple replicas converge. But real products also need to answer what changed, whether users can restore an older version, and how a document evolved over time.
10+
11+
In a CRDT system, time travel means you can work with more than just the latest state. You can inspect history, reconstruct earlier versions, and build product features around document evolution.
12+
13+
## What does “time travel” mean in a CRDT system?
14+
15+
Time travel usually means some combination of:
16+
17+
- viewing earlier document states
18+
- restoring a previous version
19+
- replaying changes over time
20+
- inspecting how a document evolved
21+
- building history-aware product features on top of synchronized state
22+
23+
## Why version history matters in collaborative apps
24+
25+
Version history helps with:
26+
27+
- recovery
28+
- trust
29+
- review and inspection
30+
- product differentiation
31+
32+
## Why this is hard to bolt on later
33+
34+
Once persistence model, sync flow, and product assumptions revolve around only the latest state, adding high-quality version history becomes much more painful.
35+
36+
## CRDT time travel vs undo/redo
37+
38+
Undo is often local and session-oriented.
39+
Time travel is about durable document history.
40+
41+
## Product features enabled by time travel
42+
43+
- version history views
44+
- restore flows
45+
- replay / change walkthroughs
46+
- snapshot-based workflows
47+
- trust-building UX
48+
49+
## How Loro fits here
50+
51+
Loro is not only positioned as a CRDT library for convergence. It also has a stronger story around document history and time travel.
52+
53+
**TODO:** Align exact terminology and capability wording with Loro’s official time-travel docs so the page stays precise instead of vague.
54+
55+
## When you should care about this feature
56+
57+
Care early if your product needs restore, review, recoverability, or structured content history as part of the UX.
58+
59+
## What to read next
60+
61+
- [Time Travel Tutorial](/docs/tutorial/time_travel)
62+
- [Learn how sync works](/docs/tutorial/sync)
63+
- [Loro vs Yjs](/kb/loro-vs-yjs)
64+
- [How to Build a Collaborative Editor](/kb/build-collaborative-editor)

‎pages/kb/index.mdx‎

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
title: "Loro Knowledge Base"
3+
description: "Search-first guides for CRDTs, collaborative editing, local-first architecture, and evaluating Loro against other CRDT libraries."
4+
keywords: "loro knowledge base, crdt guides, collaborative editing, local-first, yjs alternative"
5+
---
6+
7+
import { Cards } from "nextra/components";
8+
9+
# Loro Knowledge Base
10+
11+
Search-first guides for engineers evaluating CRDTs, collaborative editing architecture, and local-first software.
12+
13+
Use this section when you want the big picture first:
14+
- what CRDTs are
15+
- how to compare Loro with Yjs and Automerge
16+
- how to design a collaborative editor
17+
- why document history and time travel matter
18+
19+
## Start here
20+
21+
<Cards num={2}>
22+
<Cards.Card arrow title="What Is a CRDT?" href="/kb/what-is-crdt">
23+
Learn the core idea behind conflict-free replicated data types and why they matter for offline and real-time apps.
24+
</Cards.Card>
25+
<Cards.Card arrow title="Loro vs Yjs" href="/kb/loro-vs-yjs">
26+
A practical comparison for teams choosing a CRDT library for collaborative software.
27+
</Cards.Card>
28+
<Cards.Card arrow title="CRDT Library Comparison" href="/kb/crdt-library-comparison">
29+
Compare Loro, Yjs, and Automerge across ecosystem, data model, and product fit.
30+
</Cards.Card>
31+
<Cards.Card arrow title="How to Build a Collaborative Editor" href="/kb/build-collaborative-editor">
32+
A search-first architecture guide for collaborative text and document products.
33+
</Cards.Card>
34+
<Cards.Card arrow title="CRDT Time Travel" href="/kb/crdt-time-travel">
35+
Understand document history, replay, and versioning in local-first and collaborative apps.
36+
</Cards.Card>
37+
</Cards>
38+
39+
## Looking for implementation details?
40+
41+
If you already know what you want to build and just need APIs and examples, go straight to the docs:
42+
43+
- [Get Started](/docs/tutorial/get_started)
44+
- [CRDT Concepts](/docs/concepts/crdt)
45+
- [Sync Tutorial](/docs/tutorial/sync)
46+
- [Time Travel Tutorial](/docs/tutorial/time_travel)

0 commit comments

Comments
 (0)