u/RobinCrusoe25

For years I've been struggling to grow my own knowledge base. I tried many flows and guru templates, eventually I procrastinated on everything.

After some reflection, I realized that I take notes daily and I use the simplest thing for that - a messenger and the chat with myself. Sending things there felt so natural, there's no brain resistance - we've done it so many times.

After a few years, I was taking more and more notes. It was effortless - just like chatting with friends, a well-familiar pattern. Eventually I liked it so much, that I started to use it for tasks, journaling, habits, projects, checklists... For anything that can be stored as text.

I inspired my friends to take notes and save other things with this flow. Initially we used Obsidian and set up file sync through Dropbox. It was techy and complicated. I dreamed about a simpler solution where you wouldn't need to install or set up anything.

After many trials and errors, I finally decided to create a progressive web application. One that works like a regular website, but that you can also install (like Youtube or X) to get native-like experience.

And I've made it! Right now on a completely new device you can open your chat application, type /app, and a web app (similar to Obsidian) will open up, with all your stuff. And it feels magical - all your life is accessible from anywhere. Local-first, so that you own the files.

This chat flow was such a handy solution, that I also implemented it in the web application.

All code is fully open source.

I believe that not only you should own your data in plain files, but also you should own the software that opens those files. So that your files and tools can grow together, fully under your ownership, through the ages.

Chrome browser is recommended at this stage.

files.md

Hi, redditors!

I believe that not only you should own your data in plain files, but also you should own the software that opens those files. So that your files and tools can grow together, fully under your ownership, through the ages. And Golang is the best fit for that kind of software.

For the past five years I've been making an app for notes, tasks and journaling that stores everything in .md files. A few days ago I open sourced it: files.md github.

I'll share the story behind it.

I love Golang dearly. I like everything about the language: its simplicity and minimalism, tools and std libs. I also love that the software written in Go is self-sufficient and doesn't have so many dependencies. It can last. In 10 years, it will be possible to just build and use most Golang projects with no troubles whatsoever. Compare it with any legacy js app with some fancy (but now very outdated) build system :)

I have been maintaining a few pet projects, and at some point it became a nightmare. Outdated frameworks, a lot of dependencies, tightly coupled complex code. Whenever I wanted to change something, I had to open somewhat 10 files and to try to figure it all out. I couldn't update the framework or dependencies - there were too many of them. Eight years can kill any PHP Laravel project, it ages badly. Not only that, but also back then, I was obsessed with small classes and modules. If you ever supported a project with too many small classes, you know what I am talking about.

Also I had to mess with Docker and a lot of server components, migrating or maintaining the server was hard.

I decided to rewrite everything to Go. I wanted to have just one single binary that I can deploy anywhere easily. Out of all pet projects I picked the one that I used the most - a chatbot for tasks, notes and journaling.

The goals I had:

• I plan to use it for the rest of my life, so it should be easily maintainable
• If I open code a few years later in the middle of the night, I should be able to understand it
• Ideally, all important bot functionality should be in 1 file
• It should be 1 binary, I should be able to deploy it in a matter of seconds

Somewhat 6 months later I had it all done.

Server setup before the rewrite:
docker + php-fpm + php7 + larvel + nginx + redis + cron + worker + certbot

Server after the rewrite to Golang:
server, a 15MB no-dependencies binary that has everything.

That's my favourite part about the language. Go is best for these kind of things.

>3 years passed since then, you can check out how things are going in 3K lines of code file, so far I am happy. It's very easy to add features, not only I am glad to maintain it, but also AI can oneshot pretty much everything nowadays, because there's no complexity.

I was happy with the result, but also I wanted more.

Telegram chatbot for taking notes is a good thing, but what do you do when you are offline? I wanted to work with my knowledge base without the internet.

I decided to develop a desktop application using fyne.io. And it worked! I was able to work with my .md files (tasks and notes) exactly the same way I do in the bot, but this time fully offline using one single binary.

The idea was to have a binary for this chat bot, so I can store it close to my .md files. So that I can use my knowledge base on any machine that has my folder with files. I failed at my first attempt - my second apple machine had different architecture (intel), so the app wouldn't launch.

It seems like for the past decade everything has moved to the web. Browsers are preinstalled on every computer, widely available. So it has to be a web application.

Fyne.io is a good project, and it had a solution to this - you can compile your project to WASM! So that it can be accessible in your browser.

Having a Golang app running in your browser like that felt magical! I've been using it for some time. After a bit of tweaking though, I came to some conclusions.

It could be a beautiful story that you have codebase in one language as a source of truth, and you build for any platforms from this. But the reality was, that the whole system became complex.

1. Again, fyne.io is great. But the amount of custom widgets and tweaks that I made grew a lot. What would happen to all that code in the future? What about all the custom code closely tied to fyne.io? Code is liability.
2. I wasn't familiar with layout system in this framework, nor an LLM was familiar with it. It was quite a struggle to tweak UI elements however you want.
3. Debugging became hard. Golang -> WASM -> Canvas, a lot of async javascript calls mid through. Errors became cryptic. On the interconnection between WASM and JS you had to use complex glue that is not so easy to debug.
4. Yes, you add one feature in Golang for your bot, and you have it in the web app, that's magical. But at what cost! Usually you'd tweak things a lot to make it work good in that complex setup.
5. Browser would have to download 10MB+ WASM binary before it could start, and on slow connection it became an issue.
6. Also, Go's WASM support is somewhat experimental.

It felt like, at this point, some simplicity was lost mid through.

The bot was just the first part of the project, eventually I wanted to have a minimal Obsidian replacement. After a bit of experimentation with markdown rendering and UI tweaking the complexity started to pour in. Not many people did that kind of thing, so most of the code you'd write from scratch. I came to the conclusion that it would be a bad idea to write that kind of editor within fyne.io + WASM + WEB stack.

An IDE like Obsidian requires a lot of rendering compexity and a lot of UI tweaking and customization. I decided to go for a Progressive Web Application, that is going to be served from my Go server. People would be able to open the app in a web browser, no need to download something, quite a native experience.

At first I used JS/HTML for the UI, and to have core logic compiled into the WASM. So that, as I dreamed, Golang code was the single source of truth for server and web app. It was a simpler setup, where the JS code talked to Go's produced WASM via single entrypoint - "executeCmd(params)".

I lived with this setup for quite some time, but eventually I let it go as well, for the reasons I stated above.

Did I like the experience of writing JS, and using Browser File System API? No, not at all. Along the way I fought a lot of browser-related complexity, I issued 2 bugs in Chromium (and waited for 6 months for them to be fixed). I tried to keep everything simple, no build systems. You just open web/index.html and the app is ready to use.

The moral of the story? So, is it not a 100% Golang project?
The majority of the code in the project is still Go. Core parts are implemented in Golang: server, API for synchronization, workers and scripts.

Glue code between Go's produced WASM and JS is quite complex, and sometimes it just didn't work. Any integration issue resulted in hours of debug. That's understandable, given that this is an experimental support.

My final goal was not to write everything in Golang, that is binary, all-or-nothing thinking. My final goal was to write simple, easy to maintain software. And sometimes to achieve simplicity you have to use components and technologies that you're not so passionate about.

GitHub

Both HoMM III and HoMM II are quite playable.