DEV Community: Emad Elsaid

Introducing XLog: A Static Site Generator Built for Knowledge Bases

Emad Elsaid — Thu, 07 May 2026 13:18:10 +0000

After years of trying different tools for my personal wiki, I built XLog - a static site generator specifically designed for knowledge bases, digital gardens, and personal wikis. Here's why it exists and what makes it different.

The Problem

Most static site generators (Hugo, Jekyll, 11ty) are built for blogs and marketing sites. They're great at what they do, but they're not optimized for interconnected knowledge bases.

Cloud tools (Notion, Obsidian Publish) solve the knowledge base problem but lock you into their platforms. Your notes become dependent on their infrastructure, their pricing, their features.

I wanted something that combined the best of both worlds:

Local-first like static generators (your data, your files)
Knowledge-base features like cloud tools (backlinks, search, organization)

What is XLog?

XLog is a fast, Git-native framework for building knowledge bases. It's written in Go and designed specifically for interconnected note-taking, not general websites.

Key features:

Automatic Backlinks - Mention a page name (Page Name) and XLog creates bidirectional links automatically. No manual link management.
Desktop Editor Workflow - Use Vim, VS Code, Emacs, or any text editor. Edit markdown locally with live preview in your browser.
Git-Native - Everything is markdown files in folders. Full version control, sync with Git, no database.
37 Built-In Extensions - Hashtags, search, todos, photos, and more. Knowledge-base features out of the box.
Live Preview - Save in your editor, instantly see changes in browser. No build step during writing.

How It Works

1. Install (30 seconds)

go install github.com/emad-elsaid/xlog/cmd/xlog@latest

2. Create Your First Note

mkdir my-wiki
cd my-wiki
echo "# Welcome to My Wiki" > index.md
xlog

3. Open Browser

Visit http://localhost:3000 and see your note rendered.

4. Edit

Click "Edit" - opens the markdown file in your configured text editor. Make changes, save, and the browser updates instantly.

That's it. No complex configuration, no theme setup, no build process.

Why Desktop Editors?

XLog intentionally doesn't include a browser-based editor. Instead, you edit in Vim, VS Code, Emacs, or whatever you prefer.

Why?

Editor freedom - Use the tools you already know
Powerful editing - Vim macros, VS Code extensions, Emacs org-mode
Offline-first - Edit without internet
Git integration - Built into your editor

The "Edit" button in XLog opens your desktop editor. You're editing local markdown files, just with a live preview in your browser.

Automatic Backlinks in Action

This is XLog's killer feature. Write naturally and connections emerge:

# Machine Learning Notes

I'm learning about Neural Networks and Decision Trees.

Both relate to Supervised Learning.

XLog automatically:

Creates clickable links to those pages if exists (Neural Networks, Decision Trees)
Shows on "Neural Networks" that this page links to it
Builds a knowledge graph of relationships

No manual link creation. No broken links when you rename files. Just write and connect.

Digital Gardens, Not Blogs

XLog is optimized for digital gardens - interconnected, evolving notes rather than chronological blog posts.

Good for:

Personal wikis
Research notes with bidirectional links
Digital gardens (learning in public)
Technical documentation
Zettelkasten-style note-taking

Not good for:

Marketing websites
E-commerce
Multi-author publications
Complex themes and layouts

If you're building an interconnected knowledge base, XLog is perfect. If you need a general website, use Hugo or Jekyll.

Comparison

Feature	XLog	Hugo/Jekyll	Obsidian	Notion
Editing	Desktop editor	Desktop editor	Desktop app	Browser
Backlinks	Automatic	Manual	Automatic	Manual
Storage	Local markdown	Local markdown	Local markdown	Cloud
Deployment	Static HTML	Static HTML	Paid publish	Cloud only
Speed	Fast (Go)	Fast	N/A	Depends on network
Cost	Free, open-source	Free	Free (publish paid)	Freemium

XLog sits between pure static generators (Hugo) and cloud tools (Notion), offering knowledge-base features with full data ownership.

Who It's For

XLog is for developers and technical users who:

✅ Prefer markdown over proprietary formats
✅ Want Git version control for notes
✅ Need automatic backlinks and hashtags
✅ Like using their own text editor
✅ Value local-first, no vendor lock-in

XLog is not for users who:

❌ Need real-time browser collaboration
❌ Want WYSIWYG editing
❌ Require complex themes and CMS features
❌ Prefer all-in-one browser tools

Real-World Usage

I use XLog for:

Personal wiki - 2000+ interconnected notes on programming, books, ideas
Project documentation - Technical docs with automatic backlinks
Learning journal - Daily notes linked to concepts

The XLog documentation itself is built with XLog. Every page is interconnected, concepts link naturally, and the knowledge graph reveals relationships I didn't consciously create.

Getting Started

Documentation:

Repository:

GitHub: https://github.com/emad-elsaid/xlog
Stars welcome! ⭐

Quick start:

go install github.com/emad-elsaid/xlog/cmd/xlog@latest
mkdir my-notes && cd my-notes
echo "# Hello World" > index.md
xlog

Visit http://localhost:3000 and start building your knowledge base.

The Philosophy

XLog is built on three principles:

Filesystem-based - Your notes are portable markdown files, not locked in a database
Git-native - Version control is part of the workflow, not an afterthought
Editor-agnostic - Use the tools you want, not what we force on you

I built XLog because I wanted a knowledge base tool that respects these principles while providing automatic backlinks and live preview. If you share these values, give XLog a try.

Feedback Welcome

XLog is actively developed and open to feedback. If you try it:

Open issues on GitHub for bugs or feature requests
Star the repo if you find it useful
Share your knowledge base experiences

I'm building XLog for people who value local-first, Git-native knowledge management. If that's you, welcome!

Links:

GitHub: https://github.com/emad-elsaid/xlog
Documentation: https://github.com/emad-elsaid/xlog/tree/master/docs
Demo: https://xlog.emadelsaid.com (this documentation is built with XLog)

Sound approach for a p2p social network which falls back to current web

Emad Elsaid — Tue, 16 Feb 2021 10:11:02 +0000

Following the last 2 posts and other videos in the past weeks. The following
will continue on the same track of a peer to peer social network.

I'll build the idea as layers over each other so:

First: Data format

I will write my notes, recipes and any activity I want as JSON file on my filesystem.
To have a common schema I'll use schema.org specifications to present my activities.

Second: Protecting my data

I will create a openPGP key pair for signing and a sub key for encryption
I will sign and encrypt my files with the keys so only me can read it and make sure no body else edits it.
File are now formatted in openPGP format on disk.

Third: Exchanging my data

To exchange a note with my friend
My friend will upload his public key to a keyserver
I will get the key and verify the signature in another channel
I will add him as a receiver to the file I want to share
I will send the file to my friend in an email or chat message or any other channel.

Forth: Organizing my files

To separate files that are created by me from my friends I will create a subdirectory for each keypair named after the key short form.
Now I can see all files shared by one friend in one directory

Fifth: Browsing my files

I can build a CLI tool or a UI to create schema.org files signed/encrypted by my key and also for a friend
I can extend the UI to show the files content in a user friendly presentation ordered by creation time latest first
Now I have a timeline of my activities and my friends
Now I can filter the files with a subdirectory which makes it my friend timeline.

Sixth: Syncing with friends

I can extend the client UI to join a kademlia network that connect me to my friends
I can make the client UI send the missing files to my friend and delete the files I deleted locally

Seventh: Social interactions

Liking/disliking and other interactions can be also schema.org files
That will make them ordinary files which has save privacy and exchange mechanism as normal activities
The UI can choose how to display the social interactions.

Eightieth: Falling back to the web

website are using schema.org for SEO
my client UI can read the webpage and extract schema.org parts and render them like any other post
I can subscribe to a website which will make the client crawl it regularily and extract the schema.org parts and save it to a separate subdirectory for this website.
Having the peers interact together over HTTP will make it easier to use the same code for crawling the websites.
Having the peers exchange schema.org format will make the code reusable.
My client can have another interface that render my public activities as HTML pages with schema.org microformats in the same page and a HTTP proxy server can sync regularily with the client and serve my social feed over HTTP
Having the activity as a JSON file without encryption means it's a public data so anyone on the internet can download the file and read it.

Ninth: Sharing content

A file I exchanged with a friend is encrypted for him and other receipients
My friend can create schema.org shareAction that reference my file address as the "object" attribute value.
He can exchange this file with his friends
His friends will retrieve the file from me if they're one of the recepients
My client will refuse to transfer the file if the user requesting it is not one of the recepients.
Even if my friends transferred the file to them without my permission the file can't be decrypted by their client.
If my friend added his friends as recepients to the file and transferred it to them it is technically possible but it will be breaking my trust in him. similar to taking a screenshot of private messages. technically possible but a social violation.

On modern web applications stability

Emad Elsaid — Mon, 28 Sep 2020 13:40:19 +0000

I don't like how modern web applications are built. Many of the web applications
are too unstable, That you can't imagine having the system running without a
team supporting it. The fact that we try to automate manual processes then the
automation needs manual intervention defies the purpose. Some companies has an
army of developers if they were to do the business by hand they would make a
better job than the programmed system. There are many reasons for this
situation. One of the reasons is the excessive use of third party dependencies.

Lets take a look on a basic modern web based system, There are several layers
on software running on the machine, starting from firmware to your business
logic.

I don't think this is very helpful to understand the gravity of the situation.
There are many actors that are not considered in this picture. Layers are also
missing because they are implicit in other layers. Lets expand these hidden
layers and actors. It will help us understand better why that small Nodejs or
RubyOnRails application we wrote isn't just one layer in this picture.

Here are the layers we added this time:

System core utilities
Other processes your application depends on like "memcached, Redis, MySQL, Postgres...etc"
Third party code your application depends on an ORM, Template engine, pagination library, a library that pads your string with spaces just because.
Server applications that sits in front of your code handling HTTP and response compression...etc.

For each of these layers there is at least one team responsible for
maintaining it.

Again, We missed other layers and people in this picture. Most of the
applications are using external SAAS providers for logs or monitoring or bug
reporting or provide parts of the system functionality that can take more time
to build by the company team. lets add them to the picture along with their
teams.

This picture is for one application, I won't expand it to a whole system with
different services and programs that is the reality of all companies.
Lets stick to one application for the sake of simplicity.

So here is the first point I want to make: With every service you use you're not
just a user, This service is now part of your application, You are held
responsible for it's behavior and misbehaving. You will inherit bugs in their
system. When this service team is affected by COVID-19 and get reduced to the
point where they can't fix issues you will be affected too. When They get slower
your application will get slower too. When their service is down your
application will experience malfunction too, Your system and theirs is now
connected. So add external services integration cautiously. By adding an
external system you're putting your trust in this service team and their ability
in delivering what the service is promising now and in the future. This is not
an easy decision and it should be treated as such.

Now lets move to the direct dependencies of your application. If you're using
any modern programming language it'll have a way to package code into reusable
format that could be reused by other applications. one package can use code from
other packages, these packages can use other packages and so on like a tree.

With every package in this tree we depend on the code inside this package and
the team that maintains it. A freshly generated rails project depends on 74
packages for ruby and Yarn list that lists JavaScript dependencies output 3102
lines, that's 3176 packages with teams maintaining them and bugs and new
versions all the time.

This is wrong for many reasons. I will list some of them here for the sake of
clarity.

You have put your trust in at least 3176 other developers. You have never met them, never talked to them, there are no guarantee they will continue to maintain this package. There are no guarantee they won't put code in their package to show ads in your terminal or code that steals your bitcoin wallets .
You are not really using all of this code. When someone is writing an open source package it will suffer sooner or later from feature creeping You are probably using couple features of this package and don't need the rest, but you wanted the banana and got the whole forest now.
With every package update you're inventing unnecessary work for yourself. New versions of packages are released all the time. Updating your project to get the latest bug fixes and features is usually what people do. Most of the time because of feature creeping these versions changes are not relevant to you at all, but you won't know until you read the change log. If it's relevant to your project you'll need to do an update. if something is deprecated or changed you'll need to change your code. So suddenly someone somewhere is telling you to change your code. That's part of the control you have over your code handed over to someone you never talked to or knew.
When your programming language has a new release you can't update unless all of your dependencies are up to date. For ruby 2.7.0 for example some language syntax is now deprecated and shows warning when you run your project. So to fix that you either fix it in the package and open a PR with the change or wait for the maintainer to update it.
When you encounter a bug in a dependency you will have to understand this package code, fork, branch, fix rinse and repeat. That requires a some cooperation from the library maintainer which is most of the time isn't possible because most of the open source projects are voluntarily maintained.
Developing new features or modifying existing features are ordre of magnitude harder. You'll need to dig into the documentation of the dependencies looking for support for this little feature you want to add. That is if there is any documentation at all for that part of the code. Otherwise you'll have to dig in to the library code.

This is the second point I want to make: Using external library implies that you
trust the maintainer and you also inherit his decisions about using other
libraries and so forth. This decision should be weighed based on the benefit of
the library and how many of it's features you're going to use and other factors
like the maturity and how responsive is the maintainer, please don't use GitHub
stars as a factor in your decision it's misleading. And if the part you use from
the library isn't too big I recommend using the library to save some time and
effort upfront but make sure you get rid of it and implement the part you need.
An example of that is a pagination library like rails "Kaminari" if you're using
it to save you some time then sure. But keep on your todo list a task to remove
it and implement the feature yourself. An example of libraries that's hard to
get rid of it "OpenCV" This is something that reimplementing the part you need
probably will be a huge task so it can stay. You'll need to use your best
judgment to decide between these 2 sides of the spectrum.

I like to think of what I do as building an automated system, I would like this
system to run by itself, keep itself clean and healthy, doesn't need manual
intervention. If the whole team disappeared out of existence I would like that
system to work for a very long time without any supervision.

More code means more bugs for me to fix, by extension more code that I didn't write
means more bugs that I probably can't solve. This is dangerous and shouldn't be
taken lightly. Extending your code with external libraries or systems can cut
down effort hence the cost of development. But when this is taken lightly it
backfires badly.