DraftView vs a Git-Based CMS (TinaCMS, Decap)

Authoring vs Reviewing

Git-based CMS: A CMS like TinaCMS or Decap CMS is built for authoring. It gives content editors a UI to create pages, fill in frontmatter fields, manage media, and commit the result to a branch in your repo. It is the place where content is written and structured.

DraftView: DraftView is built for reviewing. It takes a proposed change that already exists as a GitHub PR and gives stakeholders a visual way to suggest edits and leave comments — feedback that flows back onto the pull request itself.

Who's at the Keyboard

Git-based CMS: The people using a CMS are content editors who have been granted access and a workflow to publish. The CMS assumes they are trusted to write and commit.

DraftView: The people using DraftView are reviewers — PMs, legal, SMEs, executives, or external partners — who need to weigh in on a change without write access to the repo and, often, without a GitHub account at all.

The Review Gap

Git-based CMS: Most git-based CMSs either commit changes directly or offer a lightweight editorial workflow (draft → in review → ready) that moves a whole entry between states. What they generally do not offer is granular, line-level suggestions and comment threads from people outside the CMS, reconciled back into a pull request.

DraftView: Reviewers highlight rendered text, type a replacement, and leave comments. Each suggestion becomes a native GitHub Suggested Change on the exact source lines, so the author accepts feedback with a click — no rewriting, no separate approval tool.

Using Them Together

The two are complementary. A content editor drafts and structures a page in the CMS, which opens a pull request. DraftView then renders that PR for non-technical reviewers to suggest and approve changes, and everything lands back in Git. Authoring in the CMS, review in DraftView, one source of truth.

When a Git-Based CMS Is the Better Choice

• You need a friendly authoring UI to create and structure new content
• Editors rely on a media library and structured frontmatter fields
• You want a configured live preview of your specific site build
• Your primary need is content creation, not stakeholder sign-off

When DraftView Is the Better Choice

• The bottleneck is review and approval, not writing
• Reviewers have no repo access or no GitHub account
• You want suggestions to arrive as GitHub Suggested Changes on the PR
• You need it to work on any pull request with zero repo configuration
• You require an auditable trail of who suggested and approved what