Why WYSIWYG static site CMS’s love Gatsby
Tags: webdev, gatsby, jamstack, discuss
Published: 2020-06-24 16:43:56

---
title: Why WYSIWYG static site CMS’s love Gatsby
description: "React seems common in JAMstack's fanciest CMSes"
published: true
date: 2020-06-24 15:00:00 UTC
tags: webdev,gatsby,jamstack,discuss
series: Playing With Gatsby
canonical_url: https://katiekodes.com/wysiwyg-cms-why-gatsby/
---

Please correct me if I’m wrong:

This is my current understanding of why most Jamstack CMSes with drag-and-drop WYSIWYG previewing seem to heavily favor [Gatsby](https://www.gatsbyjs.com/) as a static site generator.

* * *

## React

![React logo](https://pbs.twimg.com/profile_images/446356636710363136/OYIaJ1KK_200x200.png)

It’s all about Gatsby’s choice to use [React](https://reactjs.org/docs/hello-world.html), a JavaScript framework originally meant for easily changing the appearance of a web page by manipulating its [DOM](https://en.wikipedia.org/wiki/Document_Object_Model#Applications), as its “template language” for rendering HTML into your static site at build time.

_(Learning enough React to make [“version 2” of my Gatsby experiments](https://dev.to/katiekodes/gatsby-react-minimum-viable-markdown-template-component-1e26) was quite an endeavor!)_

Other static site generators, like Jekyll, ask you to code your logic in templating languages like Liquid _(ahem – much lower learning curve)_.

For a CMS to create a simulation of your web site, it’d have to write an interpreter for converting code written in the templating language to HTML/JavaScript _(which web browsers can actually understand)_.

Unless the template code _is_ just JavaScript. Then the CMS can simulate your web site with very little effort.

Ultimately, it’s probably not so much that WYSIWYG drag-and-drop content management systems love Gatsby as it is that they love React.

* * *

## Gatsby renders 2 copies of your site

![Gatsby logo](https://pbs.twimg.com/profile_images/1135999619781939201/HZ-pCQcP_200x200.png)

Gatsby does a little “bonus” when it comes to React: it uses it to render _two_ copies of your web site at build time.

### As HTML

![W3C logo](https://pbs.twimg.com/profile_images/1069553420854591489/stZUQMcC_200x200.jpg)

Like all static site generators, at “build” time, Gatsby produces a bunch of HTML _(and CSS and JavaScript)_ for each “page” of your web site that gives visitors a full-featured copy of the page’s “elements” when they inspect the HTML behind “page source” in their browser.

If your homepage is supposed to have `<div>Hello world</div>` in it, that HTML will actually show up in “View Page Source” from a browser.

### As JavaScript

![JavaScript logo](https://pbs.twimg.com/profile_images/827354992377860096/sUe4dG_L_200x200.jpg)

When viewing the “page source” of a Gatsby-rendered web page, you might notice references to JavaScript files with funny names.

These are spare copies of the React components you wrote for the “build server.” Gatsby put copies of them into the browser-available JavaScript within your page.

These “spare copies” of your React components can be be used to control the [DOM](https://en.wikipedia.org/wiki/Document_Object_Model#Applications) that, more than the “page source” behind your web page, _actually_ represents what a visitor sees when they visit your web page.

* * *

#### Why?

Including some JavaScript in the “page source” of a web page for “later use” isn’t terribly unusual.

My blog’s HTML includes a small `<script/>` definition of a JavaScript function called `toggleExpanded()` in my “page source.”

When a visitor clicks on the toggle-arrows for my sidebar, `toggleExpanded()` alters the [DOM](https://en.wikipedia.org/wiki/Document_Object_Model#Applications) responsible for rendering my sidebar.

This shows or hides months and posts.

What’s a bit particular to Gatsby is that it puts _(“hydrates”)_ _ **all** _ of the JavaScript responsible for defining _your whole web page_ into browser-available JavaScript _ **just in case** _ the page needs further manipulation browser-side.

That might seem like overkill, but according to [episode 71 of JS Party](https://changelog.com/jsparty/71#transcript-5) and the [Gatsby Docs](https://www.gatsbyjs.org/docs/adding-app-and-website-functionality/), modern web developers are already quite comfortable working with a full-fledged copy of a page’s DOM in JavaScript.

They likely have plenty of ideas about functionality dependent upon browser-side JavaScript – things far more glorious than my little “sidebar toggle.”

However, apparently even modern web developers like the comfort of knowing an _approximation_ of the web page as visitors will see it exists directly in the page’s “source” because search engines favor such web pages.

* * *

#### What does this have to do with CMS?

When the “browser-ready” JavaScript includes full-fledged React components representing portions of your site, not just little functions like `toggleExpanded()`, _ **other people’s JavaScript code** _ running in a visitor’s web browser can easily manipulate their way your site looks to them.

For example, code from a CMS.

> **The DOM for your page, as seen at `https://preview.yoursite.com` by a legitmate content author, might change with each keystroke the author types into your site’s CMS.**

In practice, I don’t think a lot of CMSes leverage Gatsby’s “bonus copy” of React components.

However, I suspect that CMSes that work as plugins / settings within your Gatsby project itself might become _part of_ this “exported-to-the-browser-by-Gatsby” JavaScript and interact with the rest of the React components as a way of altering the DOM for a given visitor’s experience.

* * *

#### How does it work?

Take a look at my [second Gatsby experiment](https://dev.to/katiekodes/gatsby-react-minimum-viable-markdown-template-component-1e26#variation-1-standalone-template).

{% link https://dev.to/katiekodes/gatsby-react-minimum-viable-markdown-template-component-1e26 %}

The React component I wrote for Gatsby was called `Xyzzy` and rendered a `message` between two `DIV` tags. I stored this code in a file in the Git repository that Gatsby Cloud / Netlify looks at _(at build time)_ called `/src/templates/xyzzy.js`.

Gatsby, at build time, replaces `message` in my `Xyzzy` component with `Hello World`, ensuring that my “page source” contains `<div>Hello World</div>` from the get-go. When I look at the “page source” of my home page, I **_also_** find the following HTML:

```
<link 
  as="script" 
  rel="preload" 
  href="/component---src-templates-xyzzy-js-d35216e.js"
/>
<link 
  as="fetch" 
  rel="preload" 
  href="/page-data/index/page-data.json" 
  crossorigin="anonymous"
/>

```

Reading `/component---src-templates-xyzzy-js-d35216e.js`, I find that the JavaScript within includes a snippet that seems to give _the visitor’s browser_ a way to alter `Hello World` by executing JavaScript:

```
var t=n.pageContext;
return a.a.createElement("div",null,t.frontmatter.message)

```

Reading `/page-data/index/page-data.json`, I see:

```
{
	"componentChunkName":"component---src-templates-xyzzy-js",
	"path":"/",
	"result":{
		"pageContext":{
			"frontmatter":{
				"template":"xyzzy",
				"message":"Hello World"
			}
		}
	}
}

```

Personally, _ **I** _ don’t know enough JavaScript to figure out how to pass a new value to `t.frontmatter.message` in `/component---src-templates-xyzzy-js-d35216e.js`, but seeing that it exists as part of my web page’s browser-side JavaScript assures me that a good JavaScript programmer could figure it out.

Particularly if such code were _also_ included by Gatsby as part of the page’s browser-ready JavaScript _(which I think is how TinaCMS works)_.

* * *

## What I think each CMS actually does

### TinaCMS

![TinaCMS logo](https://pbs.twimg.com/profile_images/1181303466188128256/z62BjH1D_200x200.png)

[TinaCMS](https://tinacms.org/), I believe, actually interacts with code like `/component---src-templates-xyzzy-js-d35216e.js`.

_(More specifically, I think it adds extra code to such files.)_

TinaCMS consists of _even more_ browser-side JavaScript that, when writing your source code for Gatsby, you ask Gatsby to include in every page’s browser-available codebase.

Therefore, I’d guess that TinaCMS’s browser-side codebase is interacting with the standard browser-side React components injected into each page of your site by Gatsby.

- _(Note: Typically, you’d only inject TinaCMS code into, say, `https://preview.yoursite.com`, not into the real `https://yoursite.com`.)_

### Any highly active CMS + Gatsby Cloud previews

![Gatsby logo](https://pbs.twimg.com/profile_images/1135999619781939201/HZ-pCQcP_200x200.png)

When you [set up a “development” / “preview” Gatsby site like `https://preview.yoursite.com`](https://www.gatsbyjs.com/docs/sanity/getting-started/) to “listen” to data changes emanating from a CMS that issues data over its API with every keystroke such as [Sanity](https://www.sanity.io/)…

…I would guess that the “listener” code within `https://preview.yoursite.com` might run in your web browser and interact with the browser-side React components copies Gatsby injected into each page of your web site.

I’m not sure, but it seems like a reasonable guess?

Looking at the HTML of such a “preview” site, it has completely different JavaScript files and doesn’t have a hard-coded `<div>Hello World</div>` in its “source” at all, so it’s possible that Gatsby Cloud previews are, structurally, a little more like Stackbit than like TinaCMS.

### Sanity Studio

![Sanity logo](https://pbs.twimg.com/profile_images/1135907399582199809/7uZ5d2to_200x200.jpg)

#### Approach 1

I don’t think Sanity Studio pays any attention to the `/component---src-templates-xyzzy-js-d35216e.js` embedded within `https://yoursite.com`.

Instead, I think Sanity Studio “cheats” by [having you embed pages](https://www.sanity.io/blog/evolve-authoring-experiences-with-views-and-split-panes), hosted in something like Gatsby Cloud as described above _(such as `https://preview.yoursite.com/page_corresponding_to_the_content_you_are_editing`)_, into an `<iframe/>` within its user interface.

#### Approach 2

Alternatively, if I’m [reading the docs](https://www.sanity.io/blog/evolve-authoring-experiences-with-views-and-split-panes) correctly, there’s also an option to copy/paste the code for actual React components you wrote, like `Xyzzy` or `BasicDiv`, into the configuration of Sanity Studio.

From those, the studio can render visual **simulations of your content** as appropriate.

Data entry into Sanity would result in edits to the DOM of the simulations.

### Stackbit

![Stackbit logo](https://pbs.twimg.com/profile_images/1099066432757747712/dBv6E4wa_200x200.jpg)

I suspect [Stackbit](https://www.stackbit.com/) might be taking advantage of the fact that it asks you to let it see the Git repository where you’ve stored the actual React components you personally wrote.

I don’t think it’s paying any attention to the `/component---src-templates-xyzzy-js-d35216e.js` embedded within `https://yoursite.com`.

Instead, rather like Sanity Studio’s second approach, I think Stackbit builds its own _ **simulation of your page** _ out of the “raw” React components in your codebase.

Upon doing data entry into Stackbit, it would edit the DOM of its own simulation.

### Magnolia CMS

![Magnolia logo](https://pbs.twimg.com/profile_images/1116637184998690818/hAfmbTL5_200x200.png)

[Magnolia CMS](https://documentation.magnolia-cms.com/display/DOCS62/Hello+Magnolia) is a little much for me to follow, but I think it, like Stackbit, is already privy to the filesystem in which you’ve stored your raw React components like `Xyzzy` and `BasicDiv`.

Therefore, it builds its own **simulation** of your pages and edits the simulation when you do data entry.

I don’t think Magnolia CMS pays any attention to the React components embedded within `https://yoursite.com` within files like `/component---src-templates-xyzzy-js-d35216e.js`.

* * *

## Conclusion

> **In the end, I’d say that most CMSes are more interested in the fact that you use React as a templating language, which makes it easy for them to build simulations of your site, than in anything Gatsby itself does _(like providing copies of the React components in the browser-side source of your site)_.**

That said, like React, [Vue](https://vuejs.org/) is a JavaScript framework developed around browser-side JavaScript execution, and it seems the [Nuxt](https://nuxtjs.org/) static site generator uses Vue as a templating language the way Gatsby uses React, but I don’t see nearly as much love for it among WYSIWYG CMSes as I do Gatsby.

Maybe that’s just a market share choice, or maybe I’m missing something else technical that makes so many CMSes play nice with Gatsby.

I suspect things will become clearer as I work my way through the Jamstack CMS and SSG ecosystem, but it’s nice to write out a checkpoint of my understanding today.