Static wiki

WARNING This repo is archived but continues its life in postgit

This tool is a very simple CMS made to edit static website (or any plaintext files). It's also made to be very versatile to enable you to build much more complicated things with it.

It's extremely lightweight and simple (only about a 100 lines of Rust so far), and made to be easily editable, even with limited programming skills (no need to download the code, use an IDE, learn git, understand system administration or anything like that, simply edit the editor's theme and configuration directly from the web interface).

The perks

• Static websites
• SSG-agnostic (you can use quartz, custom script, zola, hugo, cap, pandoc or even shell if you're bold enough)
• Plaintext-first
• Complete versioning using git
• Preprocessing and complex components possible using client side JS (like talk pages are handled on wikipedia for instance)
• Postprocessing through server-side scripting
• Can edit its own styles, themes, content, templates at runtime using its own editor (you can edit the editor in the editor)
• Multi-user (not great so far but will get better)
• Ridiculously light, ~100 lines of Rust and like 3 routes
• NoJS-first, while JS can add some cool features, you can totally use it without any JavaScript

The goal

The initial goal of this software was to create a very simple and versatile solution to publish static content. But the current goal of the project is actually to create a versatile solution to let users create their own tools (whether it's a website, a content management system, a task management system, a forum, etc).

My goal is to reduce as much as possible the barriers between users and developers and keep the core base as simple as possible so it can be understood by as many as possible.

If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual

Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression.

A system should be built with a minimum set of unchangeable parts

The dream of malleable software is that we can enlarge the space of possibilities, users can enjoy more freedom and get more out of their software, without having to rely on software developers to provide it for them. I share that dream. I want to be able to modify my software without first having to download a 150GB code base, learn GNU M4, and figure out what the hell the developers were smoking when they wrote the text renderer.

Seamlessness in software obfuscates inner-workings and is a myth: things are only seamless to those who fit an idealized standard. To complicate things, software vendors often use the term "transparency" when in fact still designing interfaces in which underlying processes remain hidden to the user. However, making a technology appear transparent or seamless to users, can become an obstacle to understanding how it works, to critical engagement, and to knowledge and skill sharing. Obfuscating inner-workings makes it harder to question and challenge a technology.

On top of the complexity of actually learning code (like HTML, CSS, JavaScript, Tera or Shell), there is a lot of barriers that prevent newbies to interact with the internals of the system.

In order to start developing, they would have to:

• Have a computer and being allowed to install software on it
• Learn how to use git
• Install git
• Clone the project's source code
• Figure out and read documentation about how the code is structured
• Install the compiler or whatever
• Learn how to install it
• Generally learn how to use command-line interface
• Install a code editor
• Learn how to use that code editor
• Learn the programming languages and frameworks in use
• Do the changes
• Commit and push
• Test everything is working fine
• Try again and fix stuff
• Have access to the server that hosts the tool
• Learn how that server and the deployment work
• Connect to that server and update the software
• Figure out you forgot something in the end, and do most of this stuff again...

Many of this is more related to the workflow than the actual code. In a way the code is the easy part.

With this system, in order to modify something they simply have to:

• Click on the button to modify the theme/editor
• Learn the basics of the code
• Add their own changes, describe them and click on save

And that's it!

A problem with the current state of websites and programming in general

Let's say you want to make a website for yourself (or generally a place to share or organize your stuff), generally you have the following options:

• Use an existing platform (Wordpress, Wix, Google Drive, Tumblr, Reddit, etc). These solutions are extremely complicated and spend countless amount of energy, money and time on trying to appear simple and "transparent" to the end user. The user is completely disconnected from the tool it uses and has absolutely no power over how it works.
• Make a static website yourself. You have total control over how everything work, down to the smallest of details. However it's a solution that's generally not accessible. In order to do that you have a lot of things to understand first, on top of generally the tools and HTML+CSS+JS, you need to understand: how to publish a website, how to track versions, how to use git, how to setup an IDE, how to structure a project, etc.
  • Doing this therefore requires a lot more time and effort, and often becomes even more complicated if the user cannot use a computer and instead uses a phone.
• Pay a professional developer to make the website for them. This offloads all that work and effort to someone else, and remain very inaccessible as it's often pretty pricey.

The goal here is a sort of middle ground, where the barrier between programming and using the software is blurred, since editing the code isn't really any different from editing any other page and can be done on any device that has a web browser.

In the current system the intervention of a developer to actually setup the system in the first place is required (to create the initial files, configure the server and install the wiki). The ultimate goal would be to reduce that as much as possible.

How can it be customized?

Mainly via 2 things:

• Client-side pre-processing. This is simply JavaScript code made to ease the creation of content in the browser. This code is simply added or linked in the editor.html template.
  • Example of this is the "forum" feature of Wikipedia which is a simple client-side script to give you nice forms to interact with the forum, except behind that it simply edits the page's wikicode. But you could interact with the forum with the wikicode directly as well.
• Server-side post-processing
  • This includes building a website (by calling a static website generator for instance) to change the rendering of everything. It can also include many other things such as making automatic backups, sending notifications on changes, etc.

Basically with those two simple principles you can make it look like and do whatever you want, all of that either in your favorite IDE, or directly in the web interface at runtime.

There is no constraint on the langauges to use for either of those, if you don't like JavaScript you could use wasm or a something-to-javascript transpiler if you want to. And if you don't like shell scripting and prefer to use lisp or python as a post-processing script, you can too! There's basically no limit to what can be done here.

What could be done for instance?

Since this tool is still very early in developpement it's hard to give very concrete examples but here's a few ideas:

• An easy editor to manage a blog
• A way to manage documentation
• A way to manage course notes, summary, etc
• A file drive
• A forum
• A personal journal, mood tracker, etc
• A contact management system
• A task management system
• etc

Basically pretty much anything that can be done using plaintext files (you can find many examples of that in Obsidian's plugins or org-mode related stuff in Emacs) should be able to be reproduced here.

Inspirations

• Inspied by dokuwiki's editor,
• low techs,
• permacomputing,
• ikiwiki's system of dynamic-static,
• miniwiki (an old project of mine I rebuilt and expanded),
• Wikipedia's talk pages (for the interactivity based on plaintext human-readable data),
• obsidian's plugin system (for the same reasons as wikipedia, but on top of markdown too),
• git (versioning and workflow),
• plaintext (for its simplicity and reliability)
• partly unix philosophy but probably better described by smalltalk's concept of "comprehensible by a single individual"
• markdown's general philosophy of "you don't need to know the syntax to use it or even sometimes write it"

Inspirations I don't the name of

• A description of tech stack of static website with use of javascript and APIs for interactivity instead of the classic MVP.
• Some kind of post talking about breaking down the barriers between the developers and users to make the act of starting to contribute to code as low-effort and accessible as possible. Maybe human-scale, smalltalk principles, vines-like system?