Forem: Jeff Lindsay

Why a static site generator on Apptron is revolutionary

Jeff Lindsay — Wed, 11 Mar 2026 19:02:21 +0000

We're building on the last Apptron demo by introducing a static site generator to show that workflow. This is also a brief intro to the Taragen site generator we made that we might build into the system, a la Jekyll on GitHub Pages.

By installing Taragen, though, we can start to see what makes Apptron particularly special. The Taragen we download isn't a Wasm build, it's a Linux executable...

Check it out:

Zero-effort offline static websites with Apptron

Jeff Lindsay — Tue, 10 Mar 2026 23:20:49 +0000

Apptron can do many things, but I've never seen a faster way to publish static files to the web than Apptron. You can just copy files to /public or edit them there directly.

What's more, it's the only platform that will magically make your site work offline. Time to move my blog off GitHub Pages.

Take a look:

Apptron 0.7: Offline Sites, Console Embeds, and Much More

Jeff Lindsay — Tue, 10 Mar 2026 00:28:49 +0000

Apptron has become the center of all my projects. It's where everything is being put together and is itself a new kind of software platform. If you haven't been following closely, you may have missed it. So below are the release notes of our latest release.

This is our biggest release yet! Lots of fixes and UX improvements, but also lots of new little features here and there. For example, the /web/dl mount is a new write-only filesystem that will cause files written to it to be downloaded by the browser.

There's also now an open command that will let you edit files that aren't in /project, which is what the file explorer shows by default. If you use open on a directory, it will add it as a new root in the explorer.

Lots more if you read the full changelog below, but first are some details on the major improvements in this release.

Console Mode Embeds

Embedding your environment on other pages with the embed snippet code previously just meant you could embed more or less the exact editor UX of visiting the environment directly. Now you can choose if you want "Editor Mode" or "Console Mode" for your embed.

Editor Mode is the same as before, giving you the default editor experience (though now without the Apptron topbar). Console Mode gives you just the terminal, making it really easy to create interactive playgrounds for CLI programs, or just run arbitrary Wasm/Linux on any web page.

Like before, you can put a .apptron/envrc file in your project (which can now also be .envrc in your project), allowing you to hook into right before you get a prompt. You can use it to run commands to customize the shell at startup like a project-level .profile.

You'd still get the "Welcome to Apptron" banner text with information about your session before .envrc is run. But now you can customize this by creating a .banner or .apptron/banner file, which will run instead of the default banner. For example, creating an empty file will cause no banner to be shown.

This all gives you full control over how the terminal session looks and is set up. You can even run different code in different contexts. For example, there is an environment variable ENV_MODE that is either edit or console. When loaded as an embed, there will be a variable set called ENV_EMBED.

Offline Public Sites

Apptron environments give you one of the fastest ways to publish a static site by just changing what's in the /public mount. Now by default, those static sites will work offline after visiting with no extra effort.

If you have a /public/index.html, we inject JavaScript to install a dynamic service worker that starts to cache all assets in /public in the background. Now after visiting the homepage, the entire site will then still be accessible and load when you are offline.

This is really cool and I've not seen any other platform do this, despite it being pretty low hanging fruit. Caching is always tricky, though, and the default refresh-ahead strategy used at the moment means you'll have to reload a page twice to see changes. Please try this feature to help us work these sorts of issues out.

Check out the demo video

Performance Improvements

It is an ongoing effort to maximize what we can get out of the embedded-like performance and memory constraints of Wasm and the browser. Two big improvements in this release, though both with plenty of room for further improvement, apply to network speed and environment building.

We upgraded our deployment's network gateway on Cloudflare Containers to the current max available of standard-4 and that gave us a 4x improvement in throughput. This mostly means downloading files and installing packages will be faster.

We also finally integrated our copy-on-write filesystem so that changes to an environment via envbuild are layered on top of the base system with every session. This was to make sure those environments got updates to the base system, but also turns out to make larger builds finish up to twice as fast.

Changelog

Additions

add new project welcome readme (#221)
add default service worker to cache public site assets for offline
add custom 404 support to public sites
add Embed Mode option to get new console embed
add open command for non-project files (#230)
add support for .apptron files as dotfiles in project root
add .apptron/banner or .banner to customize shell banner
add support for ?topbar=0 to hide topbar
add sponsor dialog from account dropdown (#247, #225)
add feedback form dialog from topbar (#247, #224)
add bundle caching that clears on login (#163)
add publish helper command (#227)
add loopback network device
add /web/dl filesystem for triggering downloads
add ENV_MODE environment variable (edit or console)
add kernel modules for audio support in vm
add confirmation dialog on project delete (#262, #267)
add toast notification on project delete (#238)
add loading indicators to buttons (#244, #203, #234, #202)
add help text in publish tab of share dialog (#195, #249)
add improved copy button in share dialog (#242)

Changes

use copy-on-write for custom environments (#217) (2x envbuild speedup, cuts seconds from pageload)
improve network throughput (#159) (4x speedup)
change starting directory to /project
refactor share dialog architecture (#245, #222)

Bugfixes

fix project file truncation/corruption (#232, #157)
fix first-time publish failure (#231)
fix inability to publish project root (#244, #233)
fix broken markdown preview (#229)
fix offscreen login component in smaller windows (#269, #268)
fix broken UI in share dialog (#266)
fix broken dropdown dismissal behavior (#240, #214)
fix broken apptron logo link (#228)
fix short project name limit (#208)
fix login failure when session expires (#210, #243)
fix broken state after changing project settings (#167)
fix dangerous username change in account dialog (#239, #246)

Full Changelog: https://github.com/tractordev/apptron/compare/v0.6.0...v0.7.0

As usual, we'd love you to try it out and file issues you run into. A huge thanks to our GitHub Sponsors who are now our only source of funding. Consider sponsoring to make sure we can sustainably see these projects all the way through and get that "Megazord" moment that's been 6 years in the making...

Turning VS Code into a Product Framework

Jeff Lindsay — Mon, 28 Jul 2025 18:33:43 +0000

Visual Studio Code is no longer just a developer tool. It’s now a highly malleable and embeddable product platform. Looking at it beyond a code editor, it's actually a general-purpose application shell with a familiar UI, plugin system, command framework, and cross-platform runtime. Recently it's been used as the platform for several major AI products, but more quietly it's also been used for much more, from cloud IDEs to domain-specific editors and internal dev tools.

In this series of posts, I’ll show how I’ve been turning VS Code into a reusable module; something you can embed, extend, and ship as part of your own product.

Why VS Code as a Platform?

I never thought the developer ecosystem would embrace a single editor as much as it has VS Code. Its dominance as a general-purpose coding environment is undeniable. This popularity and familiarity is one reason to build on it, but there are other attributes that make it a solid building block:

Generalized Design: It was designed not just as an editor, but as an integrated environment for various tools involved in the development workflow and beyond.
Highly Extensible: Its extension API allows for deep customization, from minor modifications to total transformations, even into non-code oriented tooling.
MIT License: The permissive MIT license means you can freely adapt and distribute it, provided you don't call it VS Code. The open source project is officially called "Code - OSS"

Given its intended purpose is for software development, you might think this limits it to being a framework for devtools and code adjacent domains. Really, though, you can disable and rip all of that out and still have a great shell for applications that use the same general shape of its user interface. It might not be a fit for all products, but any application built around tabbed views, user-customizable sidebars, and is advanced enough to need a command palette would be a good candidate.

Even then, having integrated code editing abilities might be more of a benefit for non-development applications than you might think. Any professional knowledge tool these days needs some level of integration and extensibility. Imagine giving power users the ability to build these in-app. An embedded VS Code could just be used for this mode of your application. Imagine a game that comes with its own modding environment. Development environments are incredibly intricate systems to build, so having the most familiar of them that you can embed in your application is a huge win.

However, there is another argument that some kind of development environment might be worth including in your application, if not building on top of one directly.

Embracing the Future of AI Agents

Rather obnoxiously, AI is everywhere. For the foreseeable future, we are going to be working with more and more AI. But also for the foreseeable future, code will remain significantly cheaper to run than AI.

Luckily, AI is pretty good at writing code. To me, this points to an eventuality where most AI agents will be automating with code rather than direct control. This is great for a lot of reasons, which I can get into another time if people are interested. For now I just want to point out that any application or system that involves agentic AI will likely need a development environment and editor as a sort of "admin backend" for a behind-the-scenes code generating agent.

As of right now, the leading AI co-development environment, regardless of model or coding agent technology, is VS Code. So if you're interested in building agentic AI products or involving code generating agentic AI in your product, it might be worth thinking about how you can embed an environment like VS Code in your product.

Maybe Avoid Forking VS Code

Let's say you're in on using the VS Code open source project in your product. Your first thought might be to fork it, essentially adopting it wholesale. After all, that's what Cursor and Windsurf did! Well here are some quick stats that might be good to know about the VS Code project:

Massive Codebase: Currently it contains 1.3 million lines of TypeScript. This is comparable to the codebase of Grand Theft Auto III.
Extensive Dependencies: Right now I count over 900 dependencies, which is a lot even for your average already-too-many-dependencies Node.js project.
Bloated Project Size: After a full npm install, the project directory expands to a hefty 2.6GB. Not sure what all of that is, but almost 1 gig of that is node_modules.

This is what you'd be inheriting and you haven't even started your application. On a high-end machine like my M3 Max, it takes around 30 minutes just to build the frontend. It takes 50 minutes on GitHub Actions. Why? I don't know, but maybe this is partly why they're porting the TypeScript compiler to Go.

Maybe you're just one person, like me, and this already seems overwhelming. Even for a small team, such a large and complex codebase and all those dependencies is rather prohibitive. Or maybe your team isn't interested in working with TypeScript, let alone 1.3 million lines of it. Or maybe, like me, you'd like to avoid Node.js and all those dependencies like the plague.

So is it already game over or is there an alternative approach? Well, since I'm also on this path as one developer with just a handful of GitHub sponsors funding this work, I had to find one. Because building an alternative to VS Code from scratch is also not an option for me.

Towards Another Approach

Thanks to VS Code's extensibility, there's a good chance the majority of what we'd want to change or add, we could do through extensions. This means changes to the codebase could at least be minimized to a few patches, making a full fork potentially unnecessary. We'd still need a build of VS Code we can configure and ideally embed in our application. It turns out there is a little known official option for this, but I'll have to explain some background on how it works.

VS Code is an Electron app, which means it's mostly a web frontend that runs inside a webview in a native window. That's essentially a browser window without the chrome that just runs VS Code. What can't run in the webview is run in Node.js outside the webview. Electron provides a framework for this with cross-platform APIs to common native functionality like webview windows, menus, etc. The webview frontend talks to the Node.js backend via RPC and that's generally how most Electron apps work.

For VS Code, what runs outside the webview are subsystems for filesystem and shell access, the ability to run subprocesses for language servers, and extensions themselves that are typically run in a separate Node.js process. This will come up later.

Despite being made to allow an app to be built with web technologies, most Electron apps become quite coupled to Electron and Node.js. When people started building cloud IDEs where Electron didn't make sense and you could just view the frontend in your browser, they couldn't use VS Code because of this coupling. Eventually, thanks to projects like openvscode-server, which patched VS Code to run as a normal web app in a Docker container, VS Code took many of these changes upstream and began to decouple VS Code from Electron.

VS Code for the Web

This decoupling led to VS Code for the Web, a build target of VS Code that can run almost entirely in a webview or browser without the Node.js backend. Where openvscode-server decoupled it from Electron, VS Code for the Web even decoupled it from its own Node.js backend. In other words, it's a build of the VS Code editor that's just static files you can serve with any HTTP server.

When compressed into a zip file, the result is an 18MB artifact that could be deployed or embedded anywhere. In fact, there is a public deployment of VS Code for the Web at vscode.dev, and even a semi-secret version deployed for GitHub. While logged in to GitHub, if you hit period (.) while on any repository, you're taken to that repository opened in an instance of VS Code for the Web. This is different from a GitHub Codespace, which runs a full backend and development environment in the cloud, similar to what you can do with openvscode-server. The reason it's different gets at the core limitations of VS Code for the Web:

No shell or direct filesystem access
No extensions that use Node.js APIs

It might be obvious but they both have to do with not having the Node.js backend. One of the major changes they made to support this build target was to make an extension host that runs in-browser using web workers, so extensions can only do what can be done in a browser web worker. Luckily, most of the core extensions have been ported to work in web workers.

Unfortunately, most third-party extensions are likely to use at least one Node.js module or NPM package. This hurts most for language extensions that typically use Node.js to run an LSP server subprocess. So if you need to support specific third-party extensions, you'll have to fork them and find a way to make them work. Better than forking all of VS Code?

The lack of shell and filesystem are pretty easy to fix because both can be provided by extensions. We can just have a kind of "system extension" that gets a filesystem and shell over WebSocket.

Embed and Extend

With VS Code for the Web we get an 18MB editor "module" in a single file that we can embed in our apps and then extend with extensions. While it comes with some limitations, I believe it opens up even more possibilities. We could:

serve it from any CDN or static host for the cloud.
use it on the desktop through any webview wrapper like Electron, Tauri, etc.
serve it in an application of any language to access via the browser.

It becomes trivial enough to embed as a built-in editor for whatever application you're building. And it's extensible and malleable enough to become any number of different non-code editors, like a DAW for audio, or a CAD tool, or a game engine editor.

In the following posts for this series, we'll build a cross-platform desktop code editor in Go using this approach. Effectively a clone of VS Code that you can use as a foundation for your own application, without all the baggage of building directly on a fork of the VS Code project.

The Spirit of Plan 9 on the Web

Jeff Lindsay — Tue, 06 May 2025 18:11:33 +0000

If you go back to the first talk ever given on webhooks, it opens on the command-line. Specifically the Unix shell, focusing on one of its defining features: pipes. The idea was that pipes brought a new level of compositionality to programs, and webhooks could bring a new level of compositionality to web apps. Perhaps you could say I was trying to bring the spirit of Unix to the web.

With this last release of Wanix, I'm at it again. This time with the successor to Unix, a little known operating system called Plan 9 from Bell Labs.

Plan 9 has been on my mind for quite a while. In fact, around the time of that first talk on webhooks, the team behind Unix and Plan 9 was being re-assembled to create the Go programming language. I pretty instantly fell in love with the Go worldview, which turns out to be an outgrowth of the Unix and Plan 9 values of simplicity, pragmatism, economy, and ultimately compositionality.

Like Unix, the Plan 9 environment is really made for programmers and system operators. I'll leave a deeper explanation of what makes Plan 9 great for another post, but I do get into it a bit in the demo video for Wanix:

While I wanted to incorporate Plan 9 ideas into Wanix from the beginning, it wasn't until we rebuilt it from scratch with that intention that the magic really starts to come through. That's what this preview release is about.

Wanix is a whole new beast now. It's no longer a singular computing environment that runs in the browser. It's now a primitive for building environments in general. The demo shows a shell environment, but this environment is not the point. It's just a way to bootstrap Wanix so you can use and explore it interactively.

The point of this preview release is to get this primitive out there. I have my uses for Wanix, and I plan to share them with the final 0.3 release, but until then I wanted to let it all percolate. Maybe inspire people to get creative with their own use cases.

Here's a quick rundown of Wanix features in this release:

Plan 9 inspired design

With the original intention to enable exploring Plan 9 ideas on modern platforms, we've ended up with a radically simple architecture around per-process namespaces composed of file service capabilities using similar design patterns to those found in Plan 9.

Single executable toolchain

The wanix executable includes everything needed to produce Wanix environments.

Filesystem is the only API

The Wanix microkernel is now simply a VFS module with several built-in file services exposed via a standard filesystem API. This ends up making the module itself a file service.

Built-in Linux shell

Using the built-in file service primitives, Wanix can bootstrap a Linux-compatible shell based on Busybox. It comes with several helper commands for working with built-in file services.

Tasks and namespaces

The Wanix unit of compute is a task, which is equivalent and compatible with POSIX processes but allows for different execution strategies. Each task has its own "namespace," which is the customizable filesystem exposed to the task.

Core file services

Wanix includes two singleton file services: one to manage tasks (similar to procfs), and one to manage "capabilities" which are user allocated file services. Built-in capabilities include: tarfs, tmpfs, and loopback.

Web file services

With future non-browser deployments in mind, all web related file services are packaged in a web module, which is also built-in but not considered core. This module includes these work-in-progress file services:

opfs: For working with the OPFS browser storage API
dom: For inspecting and manipulating the DOM
worker: For managing web workers
pickerfs: Capability wrapping the window.showDirectoryPicker() method (not available yet in Safari and Firefox)
ws: Capability for working with WebSocket connections
sw: For configuring the service worker, which is used by the system now to cache all resources needed to run Wanix allowing offline usage, as well as exposing virtual URLs to the root namespace.

Go programmers might also appreciate the filesystem toolkit we've been working on since before Wanix. It builds on the fs.FS abstraction in the standard library and gives you DSL-like utilities for defining virtual filesystems like the file services in Wanix. More on that in a dedicated post as well.

So far, the feedback has been really positive. I appreciate everybody taking the time to process it. There's still lots to do. Wanix is itself its own universe, but it's just one layer of the Tractor project. After a little vacation I'll be back to continue work on both fronts. As usual, I'd love help.

Speaking of help, shout-out to Joël Franusic for the help and support. And as usual, big thanks to my GitHub sponsors for making this possible.

How I build simple Mac apps using Go

Jeff Lindsay — Mon, 15 Jul 2024 20:41:57 +0000

I started DarwinKit a few years ago because there were no bindings to native Mac APIs for Go. We've slowly turned the project into bindings and generation tooling to someday reach full coverage of all Apple APIs. The release of v0.5.0 last week is the largest the project has seen:

Bindings for 33 frameworks with near complete coverage:
- 2,353 classes
- 23,822 methods and properties
- 9,519 constants/enums
- 543 structs
Automatic conversion and use of native Go builtin types in APIs
Support for block arguments as Go functions with properly typed arguments
Pre-made delegate implementations you can simply set Go functions on
1-to-1 mapping to Objective-C symbols while still idiomatic to Go
Documentation for all symbols including a link to official Apple docs on that symbol
Growing collection of high-quality example starter apps for sponsors

Here is a quick example using DarwinKit to build a native webview window application in a few lines of Go:



package main

import (
    "github.com/progrium/darwinkit/objc"
    "github.com/progrium/darwinkit/macos"
    "github.com/progrium/darwinkit/macos/appkit"
    "github.com/progrium/darwinkit/macos/foundation"
    "github.com/progrium/darwinkit/macos/webkit"
)

func main() {
    // runs macOS application event loop with a callback on success
    macos.RunApp(func(app appkit.Application, delegate *appkit.ApplicationDelegate) {
        app.SetActivationPolicy(appkit.ApplicationActivationPolicyRegular)
        app.ActivateIgnoringOtherApps(true)

        url := foundation.URL_URLWithString("https://github.com/sponsors/darwinkitdev")
        req := foundation.NewURLRequestWithURL(url)
        frame := foundation.Rect{Size: foundation.Size{1440, 900}}

        config := webkit.NewWebViewConfiguration()
        wv := webkit.NewWebViewWithFrameConfiguration(frame, config)
        wv.LoadRequest(req)

        w := appkit.NewWindowWithContentRectStyleMaskBackingDefer(frame,
            appkit.ClosableWindowMask|appkit.TitledWindowMask,
            appkit.BackingStoreBuffered, false)
        objc.Retain(&w)
        w.SetContentView(wv)
        w.MakeKeyAndOrderFront(w)
        w.Center()

        delegate.SetApplicationShouldTerminateAfterLastWindowClosed(func(appkit.Application) bool {
            return true
        })
    })
}

In less than 40 lines we made a native Mac app without opening XCode or using Objective-C. I think this might now be the best bindings project in existence for Apple APIs. Possibly even the best way to make small utilities on the Mac. And soon even other Apple devices.

The Future

There is one big missing piece to DarwinKit: there are no bindings to Apple framework functions. Luckily, most frameworks are built with OOP, which we have great bindings for now. But some frameworks, especially lower-level frameworks, are mostly functions. While there is a workaround that involves using CGO (which DarwinKit is trying to help you avoid), we're working on generating native Go function bindings for every framework function.

The other big thing we're working towards is making DarwinKit not use CGO at all! Using purego, we can call into Apple frameworks without involving CGO. This will improve build time, make smaller binaries, and allow DarwinKit to be used in programs that need to avoid CGO for whatever reason.

For iOS and mobile devs out there, I really want to get this working for iOS. In fact, it already should! But we generate bindings for MacOS for now. If anybody wants to help bring this to iOS to let people make Apple mobile apps with Go, please reach out!

Until then, try building an app with what we've got so far. Let me know how it goes!

Treehouse 0.3.0: Fields, Live Search, and References

Jeff Lindsay — Thu, 18 May 2023 19:03:29 +0000

New Node Types: Fields, Live Search, and References

This release we added some exciting new features: Fields, Live Search, and References. These new node types represent our first step into becoming much more than a simple outliner. Quality of live improvements include making the node menu easier to click, initial work towards a mobile view, and improving interactivity of the command palette. We also cleaned up all our UI elements to match our design system, allowing for better custom CSS support.

New Feature: Fields

A field is a node that can store a key-value pair. This introduces structured data to your nodes, letting you create nodes as data records. You can also search for nodes by field. This initial pass supports text values, but we'll soon provide more value types.

To turn a node into a field:

Indent underneath the node you want to contain the field, and type the field name
Command/Control + K to open the command palette, and choose "Create Field"
Add your field value in the value section

New Feature: Live Search

Live Search allows you to create search nodes where the children are auto-updating search results. Simply type a keyword, or use the format "fieldname:value" to filter by fields. The Live Search nodes will update automatically as your workspace content changes. This is a powerful way to view your data in new configurations.

To create a Live Search:

Create a new node where you want your search node, and type your search value
Command/Control + K to open the command palette, and choose "Create Search Node"

Tips: Search terms are case-insensitive, and you can filter on multiple fields (uses AND, not OR) like so: "fieldname:value fieldname:value".

New Feature: References

References are nodes that refer to another node and its children inline. They're sort of like symlinks on the filesystem. This lets you have a node exist in multiple places at once. References are differentiated from normal nodes with a dashed outline around their outline bullet. Deleting a reference node does not delete the node it points to. You may notice that Live Search results are reference nodes!

To create a reference node:

Select the node you want to make a reference to
Command/Control + K to open the command palette, and choose "Create Reference"

Bugfixes

Command palette now uses normalized title #117
Command palette supports mouse interactivity #102
Components no longer fail with bundled library #119
Ensure Node IDs are unique #104
Reference sub-nodes now include fields #121
Search nodes no longer production workspace #118
Prevent indenting/outdenting a field node #116

Enhancements and Chores

New feature: Field nodes
New feature: Live Search nodes
New feature: Reference nodes
Clear out non-existent node keys in workspace document under expanded #120
Don't show bullet for empty nodes #31
Allow hovering over menu area to show menu #76
Clean up styles on search bar, palette, quick add, menu, buttons #81, #85, #96, #108, #110
Show placeholder text for empty field key/value inputs #135
Implement initial version of mobile web app #103

Pulling from the best tools for thought

Jeff Lindsay — Thu, 27 Apr 2023 23:04:08 +0000

Over the past few months, we've built the Treehouse frontend framework into an elegant, quality outliner that's open source, extensible, and gives you control of your data. I’d like to share some of the design influences for the Treehouse frontend, which should give a sense of the unique direction Treehouse is going from here.

The biggest influences for Treehouse are Tana, Notion, and Obsidian. These three represent the state of the art of personal and collaborative information management, sometimes simplified as note-taking tools. However, "note-taking tools" sells them short as they go beyond note-taking and information management. For lack of a better descriptor, many consider them tools for thought.

From Notes to Tools for Thought

For most, note-taking brings to mind simple apps like Apple Notes and Google Keep, or even just a text file editor. These work well for people because they're already there and focus on quick and easy plain text capture. We could call this casual note-taking.

Back in the 2000s, hosted and self-hosted wikis became popular for easy, collaborative web publishing and knowledge management. Like Wikipedia, they could be used to build out hyperlinked knowledge repositories. Many wiki-based tools focused on their use as personal notebooks, one of the most influential examples being TiddlyWiki. The simple versatility of the wiki laid the groundwork for what we call "tools for thought" today.

When Notion appeared in the mid-2010s, it built on the idea of the wiki and introduced structured data management with flexible views that effectively gave you integrated, customizable versions of other productivity tools. Notion, Airtable, and others helped bring in the age of no-code and low-code tools, allowing knowledge workers and entrepreneurs to build their own "apps" or solutions to problems without traditionally building software. Notion brought it all together in a simple, user-friendly experience based around the core idea of wiki-like information management.

Meanwhile, a separate paradigm of note-taking tools emerged, focusing on the nested, tree-like structure of the outline. Perhaps inspired by tools like OmniOutliner and Org Mode for Emacs of the 2000s, Workflowy appeared in 2010 as a no-frills web-based outliner.

Obsidian arrived in 2020 and is a local app focusing on Markdown files stored on your filesystem. Obsidian has a large plugin ecosystem giving it a wide breadth of features, but it’s especially appealing to those that want to own their data. If you strip away the plugins, Obsidian is a pretty simple hyperlinked Markdown editor.

Most recently, a tool in early access called Tana caught my attention. Their key innovation is taking the linked outline model of Workflowy and introducing schemas for nodes, making them into structured data. This gives Tana the embedded database functionality of Notion and Airtable, a step towards bringing the two paradigms of note-taking software together towards powerful, malleable tools for thought.

How Treehouse Fits In

By now there's no shortage of options in this space, both as SaaS and open source. Take a look at this growing encyclopedia of note-taking tools. Like Notion and Tana, many of the apps listed are much more than note-taking tools. Some lean into the framing of "collaborative documents", and some are just categorized more generally as "productivity tools". Tana goes so far as to say "the everything OS".

Note-taking is just the beginning. It's a tangible gateway for something more powerful inherent to computing. Ever since Engelbart's mother of all demos, the computing revolution seems to start with powerful tools for thought, which are, at minimum, good note-taking tools.

Treehouse is a frontend and starter kit for anybody else that wants to explore this space with us. We will release a standalone product based on it soon, but most of the user-facing development will be done in the open source Treehouse project.

Today with Treehouse you can build your own Workflowy equivalent, but soon it will become more comparable to Tana and Notion with the open extensibility of Obsidian. That alone is pretty exciting to have in a minimal open source project, but I can't wait to show you what will come next.

Coming Soon

In the next post, I'll start getting technical and share details on the Treehouse project stack and architecture. If you can't wait, we do have documentation for you to check out.

Thanks for reading, and a big thanks to my sponsors for supporting this kind of open source work. Share your thoughts and favorite note-taking tools in the discussion thread for this post.

Treehouse release 0.2.0 with CSS design system

Jeff Lindsay — Tue, 28 Mar 2023 18:19:09 +0000

New design system, GitHub session locking, and documentation

This release is a refinement of our initial release, fixing a number of bugs and adding interaction improvements. The look and feel of the UI was also updated with the start of a new CSS design system based on custom properties. Session locking was added for the live demo and GitHub backend so multiple devices/browsers/tabs don't clobber changes of each other. Documentation also got an upgrade with the start of a full guide on the website.

Bugfixes

Autosave error when switching between devices #32
Deleting a node doesn't delete child nodes #25
Hitting return should produce a new node directly below the above node #29
TypeError exception when switching back from new panel #65
Support emojis #52

Enhancements and Chores

Typography and layout improvements to application #37
Add keyboard shortcut to move nodes up or down #28
Prevent backspace to delete if there are child nodes #15
Allow renaming the workspace #23
Clicking outside of the search bar/command palette should close it #48
Workspace/workbench separation #39
Add API docs #34
Set up versioned library bundle #41
Allow backspace to delete an empty child node #53
Save last location on reloads #54
Hide buttons to move a panel up/down #49

Build your own Tana clone with this new frontend

Jeff Lindsay — Thu, 02 Mar 2023 16:53:59 +0000

Apptron Demo: HTML5 Background Apps

Jeff Lindsay — Fri, 19 Aug 2022 15:31:01 +0000

In this week's demo I built a background application using HTML and Apptron. It may seem weird to involve a webview at all for a background app, which is why this was not a use case I had planned, but I was pleasantly surprised to discover how this turned out.

In the last demo, we made an app indicator background utility as a shell script. This week we re-create it using JavaScript in an HTML file. With apptron build we can make it into a standalone executable. This workflow was originally intended for quick webview apps, but because we can let the JavaScript of the page run while the window is hidden, we effectively get a background application.

Apptron wasn't made just for webview apps. I wanted to expose other native APIs that let you hook into more pre-built UI elements the operating system provides. For now this covers the common ones like app indicators, dialogs, and desktop notifications. In the future I'd like to expose APIs to let you add new items to system menus, control panels, and other places the OS lets developers hook into. These are important to make scriptable so you can easily leverage them for simple workflow hacks. When it's easy to throw that kind of thing together, you don't need to find "an app for that," you can just imagine what would work for you and make it happen.

If this is also a world you want to see, join Apptron early access and help us get this thing out. See you next demo!

-jeff

Apptron Demo: Shell Scriptable Native APIs

Jeff Lindsay — Fri, 05 Aug 2022 21:45:03 +0000

In this demo I show off the rest of the Apptron CLI, which exposes most of the cross-platform APIs as commands. These commands make great shell scriptable utilities, and you can see how they've been designed to facilitate this. By the end, we'll have created an app indicator (systray) icon and menu that's created and driven by a shell script.

There is a whole class of power users that doesn't always want to take the time to "write a program," let alone learn how. Since the functionality is right there, why not expose it in a way that's useful for these folks? Sysadmins and devops engineers often spend most of their time at a command prompt, so this feature goes out to all of them.

It turns out having a CLI interface to the APIs also makes it easy to do basic regression testing for the project. It also provides a kind of accessible listing of functionality. And! It helps with our polyglot primitive goal, working as a stopgap before having native library support for a language, since nearly all languages can "shell out".

As I mentioned in the video, this is a strategy I like to use when making generative primitives: maximize utility by providing multiple ways to access features. Like being language agnostic, this helps meet users where they are, and reach users you might not otherwise. There's also often a dominant context people think of for some functionality, so showing it in a new or surprising context helps break people out of existing thought patterns and imagine new possibilities.

Let's see what possibilities open up with the next demo! In the meantime, join early access to explore Apptron on your own.

-jeff