Document With Elm

I think the age of AI has brought some really cool ways to ease work that previously did not exist. Sure, you get the slop. But, the slop can be suppressed, shaved off, and kept minimal. An item on my list has always been to have a site that is documentation as code. I miss the old internet when sites had a simple purpose, tech bros were not trying to harvest your data, and I did not have to click “REJECT ALL” for cookies! I hypothesize we may be entering an era of the internet where the experience gets worse. So, why not try to replicate what I miss in my little corner of the internet?

Elm Love

#

I’ve always had a love for Elm¹. It was the second FP language I used professionally. It took a little bit of time — coming from an OOP background — for it to click. But, once I understood the flow, it’s hard to imagine building web apps purpose-built for the client any other way. It’s mostly due to The Elm Architecture, but, also its simplicity. You can build rich web applications with Elm and, after you’ve spent some time reading Elm code, it becomes really quick to parse.

But, Elm Is A Dead Language!

#

There is an online debate that Elm is a dead language². A stable language does not need constant or huge contributions every week. 0.19.1 shipped in October 2019; 0.19.2 arrived in July 2026 — performance improvements only, no language changes³. The language I learned still compiles unchanged. Here’s what I need/want:

1. Strong type system for state safety and maintainability
2. Web Compatibility

That’s it. I contemplated using Melange⁴, but, opted to return to Elm and save it for a different project.

Living Documentation

#

Utilizing AI can empower us to make quick documentation. What I want is thorough documentation I can use to anchor research findings. A “source of truth”, if you will, that I can use to delve as deep as I want, on topics where I want more depth. What I seek is interactive documentation I can put online for me to interact with from my phone. Open source and Elm are both excellent foundations for such projects. Open source because it may bring passive accountability. Elm because it makes for an elegant experience creating, updating, and expanding such documentation. Elm brings trust in reliability, safety in refactoring, and a guarantee of no runtime exceptions — especially with AI at the helm.

Purpose

#

I have an audience of one: me. I don’t need a rich web application to appease clients, stakeholders, or random users. What I want is living and interactive documentation to stash research in one place. I need to be able to update it quickly and reliably. I also need it to be mobile in case an idea strikes while I’m not at home or for convenience when I’m not sitting at my machine.

Code As Docs

#

Another reason to do this is that the code can be documentation. Believe it or not, there’s an entire community surrounding documentation in code and code as documentation⁵. Given this philosophy, launching a website around it seemed like a really cool idea. The elements of this philosophy are pretty simple:

• Issue Trackers
• Version Control (Git)
• Plain Text Markup (Markdown, reStructuredText, Asciidoc)
• Code Reviews
• Automated Tests The last item is really only necessary for large teams, but it’s perfect for ensuring high-quality documentation! So, even for personal projects… why not? Making it open source also opens an opportunity for accountability for public editorial control.

Editorial Control

#

Being open source allows anyone to submit an issue for review⁶. Spot something the AI got wrong or cited incorrectly — changes are welcome. I made this for me, but, anyone is welcome to reference it, submit ideas, or submit PRs for expansion. I have strong feelings that open source always wins the day (another blog post for another day). So making this open source allows anyone to contribute. This accountability is more powerful than most people may realize. I may receive zero contributions over the lifetime of this project and that is fine with me, but, I want a conduit for anyone to correct potential mistakes or contribute.

First Project

#

I wanted a published guide to help me understand the nature of preparing, fasting, and achieving autophagy. As an overweight person, I hear there are great benefits to letting autophagy naturally break down cellular structure⁷. So, I wanted a protocol documented so I can follow it wherever I am in the world.

Here’s the project:

autophagous.fyi⁸ — a cycle-based field manual for achieving autophagy through prolonged fasting. It has a few nifty features:

1. A 12-section protocol. Ideally, you get intimately familiar with it and speak with your doc before starting a cycle.
2. Printable log for personal or historical reference.
3. A live cycle planner. You input your starting fast time and it will calculate which phase you’re currently in.
4. Electrolyte dosing sheet, including dose variations scaled to the intake the user wants.
5. Abort signals. There are, essentially, flashing warning signals to tell you to cease the fast.
6. A refeeding plan. This is likely the most critical step since body composition and energy sources are changed significantly.
7. Citations to documented studies. Unfortunately, some of these are paywalled. Alternative open papers/studies are welcome.

Why Autophagy?

#

I have been passively learning about autophagy over the last few years. I got more serious about my weight recently and wanted to gain more insight. The purpose of this project was not just to learn about the process of autophagy, but, to create a small, useful utility to track active progress during the fast. I also needed the tools for prep and post. Obviously, the not-eating part is easy enough to understand. But, what are the tools I need before, during, and after the fast to keep it safe?

Along the way, I learned a ton. I wanted to take this insight and develop a protocol I can follow, with steps to go with it. The protocol is tailored explicitly for achieving autophagy, so that’s where development focused. It starts with the pre-fast routine, which outlines a rough dietary restriction for a few days. Then comes the fast itself. And, finally, the refeeding post-fast process.

Aside: Before starting this line of research, I was wholly ignorant of just how important the final step (refeeding) was to the whole process!

TEA as a Publishing Model

#

I’ve thought through TEA⁹ (The Elm Architecture), and it’s perfect for the presentation layer of documentation. The experience is only as good as the data — but the hard part, state management, is abstracted away. In Elm apps, you get one Model and everything derived on-screen goes through pure functions. No abstract classes, no hidden or unexpected state¹⁰. So long as the data is right, the side rail, section numbers, and state will always be correct. The only minimal maintenance is the names in the cross-ref. Maintaining this list is trivial. This lets me focus on the highest priority: accuracy of the documentation.

Research Integrity

#

Now, my primary concern for this project was ensuring the claims were backed up by scientific studies or papers. To be honest, I’m out of my depth, but having the LLM “show its work” with hard references on each claim means they can be loaded into context whenever I go do the work. This doesn’t mean I’m safe from hallucination. But, having this mechanism should help reduce the risk of incorrect information. Again, another benefit of open source… even if I’m the only person in the world using this resource.

Conclusion

#

So far, the experience has been a pleasure. Maintenance is easy. Deploying is easy. Because the asset size is small, load times are unnoticeable. Interactions are pleasant and the app is guaranteed to not have any runtime exceptions. Building a living document with interactive functionality has been a joy.

What should I build next? 🤔

References

#