You can now generate self-hostable static blogs right from your DEV content via Stackbit
Tags: meta, projectbenatar, webdev, changelog
Published: 2019-09-26 11:56:08

We shipped a new feature which allows you to automatically generate and maintain a statically-hosted blog from your DEV posts. This effectively makes DEV a [headless CMS](https://dev.to/defman/whats-headless-cms-2fek) for your own hosted sites.

You can already [cross-post to DEV from your RSS feed](https://dev.to/settings/publishing-from-rss), but this flips the model and presents some fascinating possibilities.

This is a collaboration with [Stackbit](https://www.stackbit.com/), who specializes in the generation of static sites. They represent the first Oauth application that hooks into our platform, and we look forward to generalizing this feature for future collaborations.

Stackbit integrates with services like GitHub pages for storing the static files and Netlify for serving. It also allows you to choose between static site generators like Gatsby, Jekyll and Hugo. The whole process is magical.

Here is my generated site: https://royal-lime-c9165.netlify.com 🎉

And here is the repo where all the static content lives, generated automatically with a couple clicks, but editable thereafter to my heart's content...

{% github benhalpern/royal-lime %}

### **[👉 View a Step-by-step guide on getting started](https://dev.to/connecting-with-stackbit)**

# **Why would I want to do this?**

That's a good question.

For us, the founders of DEV, we consider it critical that we provide tooling to help folks better manage their data and online presence. We want to be a destination for sharing, teaching, discussing, and generally uplifting one another with our writing, but we don't want to monopolize this game.

There are a lot of reasons to be a part of the DEV ecosystem, but we don't want to make it hard to leave if you ever wanted to. Maintaining a mirror of your DEV content which you can syndicate here and elsewhere is a component of keeping web content from being wholly consumed by centralized monolithic platforms.

I wrote more about these ideas here:

{% link https://dev.to/devteam/project-benatar-fending-off-data-black-holes-499g %}

And for a bit of extra info about our ethos and outlook, here's another relevant post from a few months back...

{% link https://dev.to/devteam/medium-was-never-meant-to-be-a-part-of-the-developer-ecosystem-25a0 %}

DEV is about a lot more than just blogging, so these generated sites are necessarily lacking. There's a reason we congregate here, but we firmly believe that a healthy ecosystem is one where personal website still have a place, and migrating platforms is made as simple as possible.

You do not _need_ to be crossposting to a personal site. In fact, there are a lot of good reasons to centralize traffic to a destination like this where you can build up followers and gather reputation. But still, there may come a time where you want your content driven by your personal site.

We are on day one of this functionality. There may be some additional configuration required to get it just right so please view this as an exciting proof of concept, rather than entirely fleshed out feature. And if you encounter edge cases that break the functionality, let us know via an issue...

{% github thepracticaldev/dev.to %}

If it's on the Stackbit side, we'll pass on the info for you.

# **The technical details**

DEV uses markdown and is generally compatible with other markdown-driven frameworks. As you can see from the above GitHub repo, we do have custom rich content which does not render uniformly like markdown to HTML. Stackbit transforms this rich content into `iframe`, whereas we display this stuff inline via plain old HTML.

Stackbit acts as convenient and powerful piping, but has minimal lock-in because it integrates with other services and generates standard open source projects. This gives you a lot of additional freedom to break from the ecosystem. 

This is an area where centralization of rendering control has efficiencies which are hard to replicate with this kind of thing, but it's a small detail compared with the overall positive benefits of this optionality for everyone.

It is possible that the implementation of this could change over time, depending on what ideas we all come up with together.

# **Going forward**

In the future...

- The functionality and config of this feature and similar ones will evolve to be more and more useful over time.
- More apps will be allowed to build on our Oauth functionality. Feel free to contribute to the generalization of this feature via our repo.
- We will launch more and more functionality devoted to transparency, data portability, and decentralization. We have a lot of big things coming.

If you want to get involved in any of our open source plans, Hacktoberfest is going to be the best time to do it...

{% link https://dev.to/devteam/hacktoberfest-starts-in-six-days-3hi2 %}

Register for Hacktoberfest. We'll have lots of new guiding contribution material ready for the beginning of the celebration on October 1st.

_In case you skimmed past it above, [here are the instructions](https://dev.to/connecting-with-stackbit) to get started with Stackbit._

Happy coding!