/Home

Bringing back dumb apps

A sea of ideas

I have written a few different posts about the thoughts on the current state of technology. The siloing of information, sun-setting and the single responsibility principle in apps. It's easy to point at issues, but it is harder to actually do something about it.

Reading Pketh's blog about making Kinopo and Glitch; I was inspired to make my own sort of manifesto about how I want to build tech.

Language

I made chumbucket, as a way to make apps fast, and I made a lot of random little apps with it which are still very easy to maintain and upgrade, but building things with Typescript/JavaScript became increasingly annoying because I would have to find a wrapper system to access beautiful desktop things like files.

I tried a few languages like Nim, python, Lua and a tiny bit of Clojure, but their GUI libraries were unpleasent or few and far between, so I ended up running web servers to create the GUI making it very weird, Karasu is a great example of this weirdness.

My solution is to translate the same code feel to flutter and make tiny, good multiplatform flutter apps. Flutter is very nice to program with, it compiles to lots of places, and dart is pretty easy to pickup and run with.

Dart has a health community of CLI apps as well as flutter which has a health community of GUI apps. It's an absolute breeze to go back and forth between mac and Linux and compile the same project natively.

Inspirationally quotes

This section from Viznut's Permacomputing when they describe dumb programs.

6.1. Dumb programs

A program that is intended to be like a tool should be understandable, predictable and wieldy. It should be simple enough that a proficient user can produce an unambiguous and complete natural-language description of what it does (and how)...

The absolute number of features is not as important as the flexibility of combining them. Ideally, this flexibility would greatly exceed the intentions of the original author of the program. Ville-Matias "Viznut" Heikkilä.

I think the idea of being unambiguous and easy to explain is import.Not enough people wonder how something works, they just enjoy what it does and hope no one is being creepy.

Pketh in "In search of Organic software" talks about longevity of modern start-up software

Built to Die, and Secretive About It

Funding models explain why it’s so hard to rely on software services long-term. Not because of technical problems like crashes, but because they’re often built to die. Interesting, cool, and nice-to-use tools and platforms come out all the time. But it’s annoying to invest the time in learning and relying on something new only for it to get acquired and sunset, or become crappy in the 🎡 pursuit of growth-at-all-costs.

This is something that has happened to me many times on both ends, and I have been in invited to help build things that's soul purpose is to be bought out and sunset.

I think about the original Pokémon games with no internet features they are still playable and on almost any platform because they run in a virtual machine... well really an emulator, but it's a similar concept. Dart apps are built with a similar architecture. Pokémon Go Architecture is what I want to avoid.

For my next chapter of apps, I hope they work after I'm dead.

The take aways from this are

  • longevity is important
  • how something works is important
  • app built to work without upkeep
  • unambiguous in how it works

Hamster's can rest

Online APIs are how web apps get information and save information. There are an always on, running up Cloud computing bills. They are from conception unsustainable, like a hamster running on a wheel until it has no more energy aka the company runs out of money.

There are decentralized approaches like blockchain, but they require huge amounts of power to keep the nodes running at an acceptable speed for users, so they end up being centralized to keep up with demand.

Offline apps, on the other hand, are not subject to the same risks. As long as you have the app installed on your device, you will be able to use it, even if the company that developed it goes out of business. This makes offline apps a more reliable option for users who want to ensure that they will always have access to their data and apps.

Maybe everyone knows this already, and I'm just coming from a web engineering background, but I see files now as the OG decentralized APIs, you can access the same information from an "at rest" mp3 file instead of a JSON formatted object in an unsustainable Spotify API with a much better build for the future.

TOML was created to be transparent, it stands for Tom's Obvious Minimal Language. I think using TOML will be a key part of my apps when there isn't another popular open source option.

[manga.mushishi]
cover="/cover.jpg"
chapters= [
    "/mushishi/01",
    "/mushishi/02",
    "/mushishi/03",
]

[manga.blue_period]
cover="/01.jpg"
chapters= [
    "/blue_period/01",
    "/blue_period/02",
]

example toml

Not happening in a vacuum

Because most of the world is online, I think I will need 2 types mind sets for apps;

Gatherers and Consumers.

A gatherer will get information, create the decentralized APIs by store them as files it could be a text files, image, GIF, video, or audio

a consumer would be something that shows, organizes or transforms that information.

So for example a gallery app that reads pictures and creates albums that's a consumer because without photos It's basically nothing.

Principles

My new apps will:

  • be unable to sunset
  • treat the Internet like a tap that's on or off.
  • be obvious and explicitly when it's connecting to the Internet
  • Files will be the primary input and output (TOML preferably).
  • no login, no accounts
  • personal information should be avoid or encrypted
  • Draggable UX or Keyboard focused UX are preferred (feeling like an instrument)
  • old Ugly is the new cute
  • Minimalistic
  • Non internet sharing is preferably (offline QR Code).

What am I going to build?

I'm not sure yet, I have a lot of ideas but in no particular order know I want to rebuild

  • otxto: offline kanban manager currently using todo.txt standard
  • manabee: offline manga reader with built-in offline Japanese dictionary
  • Karasu: an offline PGP key manager and message encoder
  • Niwa: an offline infinate canvas moodbooard used for creative project or memeories
/Back to homepage