Darren Burns

Improving Posting's startup time by over 40%

Thu, 13 Mar 2025 10:09:06 +0000

I’ve been working on improving the startup time of Posting recently. Posting is a TUI application built with Textual, and written in Python, for managing and sending HTTP requests.

This post is an overview of some of the techniques (and hacks) I used and the gains made, including:

Using python -X importtime to measure import times.
Reducing the scope of import statements, so that they don’t run when they’re not needed.
Patching dependencies to prune the import tree.
Using pyinstrument and it’s new flamegraph view to find improvements.
Extracting expensive-to-import classes into their own modules, isolating other code from them.
Lazy loading of Textual widgets.
Using C-based extensions where possible.

Most of the techniques are Python-specific, and almost all of them boil down to deferring work until it’s actually required.

The values in this post are measured on an M4 Macbook Pro - the absolute gains on slower systems will likely be greater.

Deferring openapi_pydantic import (~63ms gained)#

If you run a Python application with python -X importtime, Python will print a table showing how long it takes to import each module. The “imported package” column contains the name of the module being imported, and if you look at the indentation of it, you’ll see it forms a tree structure.

The table is best read bottom-up, because parent modules are listed below child modules. The cumulative column contains the time, in microseconds, to import the module in it’s entirety, including all descendent imports.

bash

import time: self [us] | cumulative | imported package
  ... trimmed ...
import time:      3505 |      29292 |         openapi_pydantic.v3.v3_1
import time:      4138 |      62771 |       openapi_pydantic.v3.parser
import time:        84 |      62854 |     openapi_pydantic.v3
import time:        99 |      62952 |   openapi_pydantic
import time:        97 |      63048 | posting.importing.open_api

The table above shows that posting.importing.open_api and it’s descendants take a total of 63ms to import. However, this part of Posting is specific to a single CLI command, posting import, which is not used as part of the main TUI. By moving this import into the local scope of the import command handler, we can ensure we only pay the price when the posting import runs.

@cli.command(name="import")
# ...
def import_spec(spec_path: str, output: str | None) -> None:
    """Import an OpenAPI specification into a Posting collection."""
    # ...
    from posting.importing.open_api import import_openapi_spec
    # ...

The difference was immediately noticeable to me, and startup time measurement code in Posting reported a 63ms improvement. Simply by moving a single import statement. Nice!

In Python CLI apps, it’s common to have multiple command handlers in one file, with dependencies imported at the module level, even when they’re only needed by specific handlers. This is like importing the whole world when you only need an island. By moving imports inside the handlers, we can avoid this, loading just what’s necessary for the executed command.

Patching httpx (20-25ms gained)#

I found that the fantastic httpx module was taking around 51 milliseconds to import, which felt excessive. Almost 30 milliseconds of that was httpx._main, which contains a CLI tool for httpx. On diving into that module’s code, I found that if your environment contains click and rich (both common libraries), httpx “assumes”, that you’ve installed the httpx[cli] extras and will perform a bunch of expensive imports that are required for the httpx CLI. End-user apps are unlikely to require CLI, but will still pay a ~30ms price to import it.

bash

import time: self [us] | cumulative | imported package
  ... trimmed ...
import time:       292 |      28409 |       httpx._main
import time:       195 |      51101 |     httpx

To avoid running through this expensive and unnecessary import chain, I manually patch the httpx._main module at runtime, before importing httpx itself:

python

import sys
sys.modules['httpx._main'] = None

# later...
import httpx

Checking the import times again, I found the cumulative time for httpx dropped from 51ms to 23ms:

bash

import time: self [us] | cumulative | imported package
  ... trimmed ...
import time:         2 |          2 |       httpx._main
import time:       156 |      23305 |     httpx

About 28ms saved. Not bad!

Modules are cached once loaded, so some of the modules that were imported transitively by httpx._main and actually required somewhere in Posting will be still be loaded elsewhere. This means a portion of these savings are likely just due to the import cost being shifted elsewhere. However, many expensive imports such as pygments that were required by httpx._main and not required by Posting have been eliminated.

I feel I should emphasise that this is a hack - and if you’re going to do it you should be comfortable that the module is truly unused.

All of this makes me wish Python had a means of checking which extras were explicitly installed by the user or application. This would allow httpx to only perform those expensive imports when they’re asked for rather than if they happen to be installed in the environment.

Using pyinstrument’s flamegraph view#

pyinstrument is one of my favourite tools, ever. It’s a sampling profiler, which recently added a flamegraph viewer.

On running the command below, Posting starts up, and when I close the app, pyinstrument will open a browser window with profiling results.

bash

pyinstrument -r html -m src.posting.__main__

A couple of things stood out when I examined the flamegraph tab:

watchfiles is being initialised before the app starts, but we don’t actually need to setup file watchers until after the app has started.
help_screen is being imported before the app starts, which is ultimately importing markdown_it. We don’t actually need the Markdown rendering stuff until the user opens the help popup - so we don’t need to pay the import cost until then.

I made a couple of changes, noted below, based on these findings. It sliced another ~16ms off of the startup time. Not amazing, but small improvements like this add up!

Moving HelpData class to its own module (10ms gained)#

If you have code which is required on startup which is currently housed in a module alongside expensive-to-import and not required on startup code, you can extract the code that is required on startup into its own module and defer the expensive imports into the local scope(s) where it’s required.

In other words, try to isolate expensive-to-import code by splitting it into a separate module, so that it can be imported on its own, and won’t get pulled in alongside cheaper to import code.

In Posting, the HelpData class was contained alongside the HelpScreen class. HelpData is required on startup and, on it’s own, would be cheap to import. However, because it’s bundled into the same module as HelpScreen, importing HelpData also imports all the dependencies of HelpScreen.

I extracted HelpData into a separate help_data module, meaning it could be imported at the module level without the overhead of also importing all of the other stuff housed alongside HelpScreen. HelpScreen is now imported “on demand”, when the user opens the help popup.

This change shaved another 10ms off of the startup time.

Deferred loading of watchfiles library (6ms gained)#

Posting watches for changes to external files using watchfiles. The watching happens in another asyncio.Task, so by moving the import into the task which isn’t kicked off until the app starts, Posting started ~6ms faster on my machine.

Posting’s user interface relies heavily on tabs to hide content. By default, Textual will load the content of all tabs before on startup, even though only two tabs can be visible and interactive.

I used Textual’s Lazy widget to defer loading of the hidden content of these tabs until after the initial paint, and this had a substantial impact on the time taken to first paint.

My approach to testing this is rather primitive and slightly flawed, but good enough. I record a video using Quicktime Player, and scrub through it - taking note of the timestamp at which I pressed Enter to run Posting (Launch time (s)), and the time at which the UI is first painted (First paint time (s)). The difference between these timestamps is the Time To First Paint (TTFP (ms)). This allows me to measure the full end-to-end time from when I press Enter to when the UI is first painted.

Without Lazy (before)#

Run	Launch (s)	First paint (s)	TTFP (ms)
1	2.48	2.98	500
2	4.37	4.86	490
3	6.88	7.38	500
4	10.17	10.65	480

With Lazy (after)#

Run	Launch (s)	First paint (s)	TTFP (ms)
1	17.58	17.98	400
2	19.62	20.00	380
3	21.50	21.87	370
4	23.55	23.92	370

This approach is quite time consuming, and it’s not particularly accurate, since QuickTime records at 60fps (each frame captures ~17ms of time). However, in this case I didn’t require a high degree of accuracy in order to determine the magnitude of improvement.

Using PyYAML’s CLoader (5ms gained)#

Posting uses PyYAML to parse request files and theme files. Requests are stored in YAML files on disk, and when you load a collection into Posting, it’ll load all of the request YAML files into memory.

PyYAML has a C implementation, which can be used if libyaml is available on the host system.

python

import yaml
data = yaml.load(file, Loader=yaml.CLoader)

Switching to this load time when loading a collection of 18 requests from 72ms to 67ms. The time taken loading and parsing the YAML files specifically reduced from 8ms to 3ms.

Final results#

I re-ran the test where I record a video and examine the timestamps where I run the command vs when the UI is first painted. This time, a collection of 18 requests was loaded into the app on startup as well as a couple of environment files.

bash

posting --collection tests/sample-collections/ \
        --env tests/sample-envs/sample_base.env \
        --env tests/sample-envs/sample_extra.env

Overall, I found a reduction of startup time of over 200ms! Although the end result is still not quite as speedy as I’d like - I’m chuffed with the improvements.

Before#

Time between launching posting and the UI being painted was approximately 580-590ms.

Run	Launch (s)	First paint (s)	TTFP (ms)
1	0.93	1.52	590
2	4.01	4.59	580
3	6.25	6.83	580
4	8.45	9.03	580

After#

Time between launching posting and the UI being painted was approximately 360-390ms.

Run	Launch (s)	First paint (s)	TTFP (ms)
1	1.07	1.45	380
2	6.36	6.75	390
3	9.24	9.60	360
4	11.17	11.55	380

Some other ideas#

A couple of other ideas which may or may not be worth pursuing:

If the user is using one of the built-in themes (i.e. they haven’t specified a different theme in their config, then we could lazily load their themes directory when the command palette is opened rather than at startup).
There’s also an improvement I’m looking to merge into Textual itself, which will lazily load tree-sitter parsers only when they’re actually needed.

Goodbye Textualize

Wed, 01 Jan 2025 13:40:01 +0100

After three years of working full-time on Textual, it’s finally time to move on and find a new challenge.

Over the course of three years, I’ve worked with some amazing colleagues, been part of a fantastic community of open-source developers, and had the opportunity to work on the most interesting projects of my career so far. We took Textual from a proof-of-concept to version 1.0 - a fully-featured open-source TUI framework - which can be used to build apps that push the boundaries of what is possible in the terminal. I feel incredibly privileged to have been involved in such a project. Despite no longer working full-time on it, I’ll likely remain active in the community, albeit at a far reduced capacity.

What’s next for me? Frankly, I have no idea! I’ll likely be taking a little bit of time off to relax, spend time with family, and figure out what I want to do.

Introducing Posting 2.0

Sat, 19 Oct 2024 13:40:01 +0100

Posting is a powerful HTTP client that runs entirely inside your terminal.

Version 2.0 has just arrived, bringing some powerful new features to Posting, including scripting, keymaps, and more!

Posting 2.0 - a TUI HTTP client

Pre-request and post-response scripts#

A common feature request has been around adding scripting capabilities to Posting. With 2.0, you can now attach Python functions to requests, and have them run before or after the request is sent. All output from these scripts is captured and displayed in the new “Scripts” tab. This makes it easy to see the results of your script executions and troubleshoot any issues.

Viewing the status and output of scripts in Posting's new 'Scripts' tab.

This is an extremely versatile feature. You can use scripts to perform setup, set variables which requests and other scripts can access, modify outgoing requests, and much more. Here’s an example of some Python code which you can attach to a request:

python

def on_request(request: RequestModel, posting: Posting) -> None:
    request.headers.append(Header(name="X-Custom-Header", value="foo"))
    request.auth = Auth.basic_auth("username", "password")
    print("Request is being sent!")
    posting.notify("Request is being sent!")

The API is currently a bit rough around the edges, but it’ll be improved in future releases.

Attached scripts can even be edited in an external editor, and Posting will automatically reload them when they are changed.

Automatic reloading

There’s also a convenience keyboard shortcut which allows you to quickly open a request’s scripts in your preferred $EDITOR, so you could quickly swap over to vim or nano to make changes, then return to Posting to continue working.

Check out the scripting docs for more details!

Keymaps#

Posting 2.0 also allows you to declare custom keybindings, thanks to an update in the underlying Textual framework. For 2.0 only “global” keybindings can be remapped, but this will be expanded in future releases to include most keybindings.

You can customise your keymap by adding a keymap section to your Posting config. Here’s a short example which changes the default for sending the request to ctrl+r:

yaml

keymap:
  send-request: "ctrl+r"

Hopefully this will help you feel more at home in Posting, and avoid awkward clashes with emulators and multiplexers!

See the keymap docs for more details!

Customisable hostnames#

Posting is a TUI, which means it works great over SSH. However, when working inside a TUI, it’s sometimes easy to forget which host you’re on.

In 2.0, there’s a new config option which allows you to customise the hostnames which are displayed in the header, including styling them with Rich markup to make them stand out.

This is useful if you work with Posting in multiple environments, such as your local machine, a staging server, and a production server.

Running Posting locally

Running Posting on a production server

Here’s the config I use on my “production” server to achieve the effect above:

yaml

heading:
  hostname: "[black on #ff0000 bold blink]PRODUCTION[/]"

Documentation#

Posting’s documentation has been expanded, making it easier than ever to get started!

The additions include:

Duplicating and “quick duplicating” requests.
Scripting.
Keymaps.
Integrating Posting with external tools.
An improved getting started guide which better showcases some quality-of-life features that may not be obvious at first glance :)

What’s next?#

Textual 1.0 is around the corner, and will unlock a better theming system for Posting as well as a more powerful command palette!

I’ve also braindumped some features I’d like to implement in Posting here.

The new features mentioned in this post and those on the roadmap are very much driven by users. If you’d like to suggest new features, please open a discussion on GitHub!

Custom keymaps in Textual

Thu, 03 Oct 2024 10:42:09 +0100

Textual 0.82.0 adds support for keymaps, which make it easy to customise keybindings based on config or user preferences.

Keymaps allow you to swap the keys associated with a Binding at runtime with a single method call.

You could switch to a Vim keymap if a user of your app enables “Vim mode”.
You could read a keymap from a file on the users drive and swap it in on app startup.
You could swap the increment and decrement keys on April 1st!

The possibilities are endless!

Keymaps are simple to use - just give an id to any Binding you wish to permit overrides for, then call the App.set_keymap method when your app starts, passing in a dict mapping that binding ID to the new key.

Vim keys#

Here’s an example of how you’d define a binding with an overridable key:

python

from textual.binding import Binding
from textual.reactive import reactive
from textual.widgets import Static

class Counter(Static, can_focus=True):
    BINDINGS = [
        # The id is a string used to identify this binding in the keymap.
        # You may wish to namespace them to make managing them easier!
        Binding("up", "change_count(1)", "Increment", id="counter.increment"),
        Binding("down", "change_count(-1)", "Decrement", id="counter.decrement"),
    ]

	count = reactive(0)
    """Stores the current value of the counter."""

	def action_change_count(self, delta: int) -> None:
        """Change the counter by delta."""
	    self.count += delta

Pressing up or down on your keyboard will increment or decrement the counter.

Since we’ve given these bindings IDs, they can now be overridden by a keymap. Let’s override these two bindings so that we can also use Vim keys to change the counter.

When our App launches, we just need call App.set_keymap to specify our overrides. A good place to do this would be in App.on_mount:

python

from textual.app import App

class MyCounterApp(App[None]):
    def on_mount(self) -> None:
	    vim_keymap = {
	        "counter.increment": "k,up",
	        "counter.decrement": "j,down",
	    }
        self.set_keymap(vim_keymap)

Now users will be able to use k or up to increment the counter, and j or down to decrement it!

It’s important to note that if we still wish for the up and down keys to work, we need to include them in the keymap too!

That’s all there is to it!

Keymaps should make it easier for developers to support users who want to customise their keybindings, and reduce the impact of a default keybinding choice clashing with the terminal emulator or multiplexer.

Check out the API documentation for keymaps here!

Copying and pasting in Textual

Wed, 02 Oct 2024 22:36:57 +0100

Terminal emulators are in general quite limited when it comes to copying and pasting. Fortunately, we have a few options when writing Textual apps which allow us to add support for copy and paste. Each has its own trade-offs. Let’s explore these options and look at how we can integrate them into our apps.

`App.copy_to_clipboard`#

Textual’s App class has a method called copy_to_clipboard. Pass a string into it, and it gets copied to the clipboard on the machine the emulator is running on. There is a caveat here: If the terminal doesn’t support the required protocol then nothing will happen!

Aside: How does it work?#

App.copy_to_clipboard uses the OSC 52 ANSI escape sequence to tell the terminal emulator to copy text to the system clipboard. The terminal emulator doesn’t consider the source of the text, it justs sends it to the system clipboard. Running an application inside tmux over SSH? The text can still be copied to your local system’s clipboard!

This sequence has a reasonable degree of support, with MacOS terminal being the notable exception. If a terminal supports OSC 52, then App.copy_to_clipboard will work.

Here’s a table showing OSC 52 support for common terminal emulators:

Terminal Emulator	OSC 52 Support
iTerm2	Yes
Kitty	Yes
Alacritty	Yes
Windows Terminal	Yes
WezTerm	Yes
Ghostty	Yes
Gnome Terminal	No
Konsole	No (Coming soon)
MacOS Terminal	No

Consider `pyperclip`#

If you need broader clipboard support you can try pyperclip. pyperclip is a cross-platform library for interacting with the clipboard.

It’s important to note that pyperclip copies to the clipboard of the machine that the app is running on. This is an important distinction. If your app is running over SSH, pyperclip copies to the clipboard of the remote host!

Integrating `pyperclip` with Textual#

Let’s look at an example of how we can create a read-only TextArea, which we can copy some text from. The example assumes you’ve installed pyperclip into your environment.

Subclassing `TextArea` and adding a new binding#

First, subclass TextArea, and add a binding to call the action_copy_selection method:

python

class ReadOnlyTextArea(TextArea):
    BINDINGS = [Binding("y,c", action="copy_selection", description="Copy selection")]
    
    def on_mount(self) -> None:
        self.read_only = True

    def action_copy_selection(self):
        """Copy to the clipboard of the machine the app is running on"""

This links the y and c keys on your keyboard to the action_copy_selection method. Press one of those keys, and action_copy_selection runs. Let’s implement that method now.

Implementing the `action_copy_selection` method#

The snippet below implements action_copy_selection using pyperclip. It gets the selected_text from the TextArea, then tries to import and call pyperclip. There is a gotcha here: clipboard functionality is not guaranteed. On Ubuntu, the clipboard is provided by xclip or xsel. If these are unavailable, pyperclip will raise an exception which we must handle. Lack of clipboard support shouldn’t be a fatal error, so graceful handling is important. I opted to notify the user about the problem using self.notify, which shows a toast popup at the bottom right of the screen.

python

    def action_copy_selection(self):
        """Copy to the clipboard of the machine the app is running on"""
        text_to_copy = self.selected_text
        try:
            import pyperclip

            pyperclip.copy(text_to_copy)
        except pyperclip.PyperclipException as exc:
            # Show a toast popup if we fail to copy.
            self.notify(
                str(exc),
                title="Clipboard error",
                severity="error",
            )
        else:
            self.notify(f"Copied {len(text_to_copy)} characters!", title="Copied selection")

With our action method in place, we can now select text and press y to copy it to the clipboard.

Here’s a simple Textual app that demonstrates the use of our ReadOnlyTextArea:

python

from textual.app import App, ComposeResult
from textual.widgets import Header, Footer

class ClipboardDemoApp(App):
    def compose(self) -> ComposeResult:
        yield Header()
        yield ReadOnlyTextArea("Select this text and press 'y' to copy!")
        yield Footer()

if __name__ == "__main__":
    app = ClipboardDemoApp()
    app.run()

If you run the app and select some text using the mouse or by holding shift and moving the cursor, you’ll see a toast popup indicating that the text was copied.

Switch over to another application and try pasting to confirm that it works.

Which should I use?#

If you’re distributing your app, pyperclip is likely the better choice due to broader support. However, if your app might reasonably be used over SSH, you may consider supporting both.

You could override App.copy_to_clipboard with a pyperclip version, or make it configurable. You could choose to have different keybindings for “copy via terminal” and “copy via host.”

Another option is to try some smarter detection and choose which one to used based on the user’s environment. For example, if the user is using the default MacOS terminal (which lacks support for copy/paste), you may opt to fall-back to pyperclip.

python

from textual.app import App

class MyApp(App[None]):
    def copy_to_clipboard(self, text: str) -> None:
        """Copy text to the clipboard"""
        is_apple_terminal = os.environ.get("TERM_PROGRAM", "") != "Apple_Terminal"
        if is_apple_terminal:
            self.copy_with_pyperclip(text)
        else:
            super().copy_to_clipboard(text)

    def copy_with_pyperclip(self, text: str) -> None:
        """Copy text to the clipboard using pyperclip"""
        # don't forget error-handling!
        import pyperclip
        pyperclip.copy(text)

This is of course rather naive, as TERM_PROGRAM alone does not provide a complete picture of the user’s environment. A more robust solution might check the XTerm version, like Emacs does.

Let's get fractional! Textual layouts with fr units

Tue, 01 Oct 2024 22:22:47 +0100

Fractional units (fr) are a tool in Textual’s CSS system which lets you distribute space between child widgets inside a container in a really intuitive way.

I use them everywhere in my Textual apps, but I get the feeling that they may be a little under-appreciated.

fr units make it easy to implement many common layout patterns, and have some less obvious benefits too!

Let’s explore how fractional units work in Textual, along with some practical examples!

A half-and-half layout#

Let’s start with a simple example. Given a horizontal container with two child widgets Left and Right, give each widget half of the available width.

class Left(Static):
    pass

class Right(Static):
    pass

class MyApp(App[None]):
    def compose(self) -> ComposeResult:
        with Horizontal():
            yield Left()
            yield Right()

We can assign a width of 1fr to each of these widgets to achieve the desired layout:

Horizontal {
    & > Left {
        width: 1fr;
    }
    
    & > Right {
        width: 1fr;
    }
}

Both Left and Right widgets have width 1fr out of a total of 2 assigned fr units on the horizontal axis, meaning they’ll each be given 1/2 of the available space inside the container (25 cells each in this case).

In my terminal-based HTTP client, Posting, I use height: 1fr to evenly split the request and response sections inside a Vertical container:

The request and response sections are inside a Vertical container, and both have height: 1fr, creating a 50/50 split.

That’s all well and good, but it’s not really offering anything new over using % units, is it?

Changing the distribution#

If one of our child widgets, say, the Left one, is updated to width: 2fr, then that widget will take up two thirds of the space, and the other widget will take up the remaining one third.

This is because we’ve now assigned a total of 3 fr units along the horizontal axis.

The Left widget was assigned 2 units on the horizontal axis, so receives 2/3 of the available space.
The Right widget was assigned 1 unit, so receives 1/3 of the available space.

Note that in this example, the parent Horizontal widget has a width of 50, which is not divisible by 3. However, when using fractional units, Textual takes care of that for you, ensuring that the space is fully distributed with no remainder!

This also shows another subtle benefit - we only need to update a single value to 2fr and the other children will automatically adjust to fill the remaining space. When using percentages, we’d need to update all children and ensure they sum to 100% to get (almost) the same effect.

The fr unit guarantees that we’ll always use precisely 100% of the remaining space, while also handling rounding issues you might encounter when dealing in percentages… because 33.3% + 66.6% != 100%.

Mixing concrete and fractional units#

Fractional units also interact wonderfully with concrete values like width: 10;, and this combo has several practical use-cases. For example, it lets us model a fixed-width “sidebar”, and have the rest of the content fill out the remaining space.

The CSS for this might look something like this:

Horizontal {
    & > Sidebar {
        width: 10;
    }

    & > Content {
        width: 1fr;
    }
}

Having the blue Content widget in the example above fill out like it does is not possible using %, as the value we’d need to set it to would change if the parent container was resized.

We can again see this in action in Posting, this time in the URL bar:

The 'URLBar' widget in Posting.

The method selector dropdown on the left and the “Send” button on the right have fixed widths, while the URL input has width: 1fr, allowing it to expand to fill the remaining space between them.

I’ve found this to be a recurring pattern in my apps: a Horizontal container with a few children having fixed or auto-calculated widths, with one (or sometimes more) children having width: 1fr to fill the remaining space.

Here’s the Python code directly taken from Posting which shows this in practice:

def compose(self) -> ComposeResult:
    with Horizontal():
        yield MethodSelector(id="method-selector") # fixed width
        yield UrlInput(  # width: 1fr
            placeholder="Enter a URL...",
            id="url-input",
        )
        yield Label(id="trace-markers")  # fixed width
        yield SendRequestButton("Send")  # fixed width

Conclusion#

I’ve found fractional units to be a really powerful and practical tool in Textual, and I hope this post has given you a few ideas for how you can use them in your own apps!

Learning

Mon, 01 Jan 0001 00:00:00 +0000

Interactive explainers I’ve made while learning how things work.

How terminals work#

Anatomy of a keystroke →

Follow a single key press from the keyboard, through the terminal emulator, the kernel’s PTY and line discipline, to your shell and back again as pixels on screen. Includes a working simulator, a step-through VT escape sequence parser, and a job control playground.

My projects

Mon, 01 Jan 0001 00:00:00 +0000

Over the years I’ve developed several open source projects.

The majority are written in Python, and they’re typically terminal-based developer tools.

Posting#

Posting is a powerful TUI for working with HTTP APIs. It’s a bit like Postman, except it runs in the terminal and is designed around keyboard-centric workflows.

It’s a feature-rich tool that tries to work for both terminal power-users and newcomers who are more accustomed to modern web UIs.

Written in Python using Textual, a TUI framework I help develop and maintain.

Elia#

Elia is a TUI for interacting with large language models. It can interact with proprietary models such as Claude, ChatGPT, as well as local models like Llama.

Elia has a simple but powerful interface. It uses a SQLite backend to store your conversations locally, keeping your data private.

Dunk#

Dunk makes your diffs beautiful and easy to read. Just pipe your git diff output into Dunk and it’ll generate a colourful diff like this:

Dunk makes your diffs easy to read. I alias this as `gdd`, which runs `git diff | dunk | less -R`, resulting in a beautiful paged diff.

Textual’s `TextArea` widget#

I developed Textual’s TextArea widget, which is a multi-line input widget that supports tree-sitter syntax highlighting, wrapping, undo/redo, full mouse support, and much more.

The TextArea widget in action - running completely inside the terminal.

I wrote a blog post about it here, which includes a whole lot of videos of it in action, and covers some of my learnings from that project.

Ward (archived)#

Ward was a test framework I developed for Python. It had a strong focus on readability. Test descriptions were written in plain language rather than function names, and it output very readable diffs when tests failed.

Autocomplete#

I developed textual-autocomplete, which let’s you add autocompletion to your Textual-based TUI apps.

I’m currently (slowly) working on the next version which will be used in Posting.

Trogon#

Trogon was built to solve the problem of learning and discovering features of CLIs. In just a few lines of code it lets you create a fully interactive TUI which can be used in place of a CLI. Here’s an example of Trogon converting the feature-rich sqlite-utils CLI into a TUI:

Trogon gives you a sidebar menu containing all of the commands in your CLI. Clicking on an item shows you a form with all of the arguments and options for the selected command.

Radiant#

I developed (but never released) an iOS and Android app using Flutter and the Dart programming language.

Screenshot of Radiant

Things I really like

Mon, 01 Jan 0001 00:00:00 +0000

An incomplete collection of things I really like.

Books#

I mostly read fantasy and sci-fi.

The Will of the Many | James Islington | Fantasy
Powder Mage Series | Brian McClellan | Fantasy
Children of Time | Adrian Tchaikovsky | Sci-fi
Hyperion (book 1) | Dan Simmons | Sci-fi
Stormlight Archive Series | Brandon Sanderson | Fantasy
Mistborn First Trilogy | Brandon Sanderson | Fantasy
Piranesi | Susanna Clarke | Fantasy
Ender’s Game | Orson Scott Card | Sci-fi
The Expanse Series (the first 4 books) | James S.A. Corey | Sci-fi
Project Hail Mary (Audiobook) | Andy Weir | Sci-fi
Childhood’s End | Arthur C. Clarke | Sci-fi
Flowers for Algernon | Daniel Keyes | Sci-fi
The Name of the Wind | Patrick Rothfuss | Fantasy
Blood Song | Anthony Ryan | Fantasy
Old Man’s War | John Scalzi | Sci-fi

…

Darren Burns

Improving Posting's startup time by over 40%

Deferring openapi_pydantic import (~63ms gained)#

Patching httpx (20-25ms gained)#

Using pyinstrument’s flamegraph view#

Moving HelpData class to its own module (10ms gained)#

Deferred loading of watchfiles library (6ms gained)#

Using Textual’s Lazy widget for tab panes (100ms gained)#

Without Lazy (before)#

With Lazy (after)#

Using PyYAML’s CLoader (5ms gained)#

Final results#

Before#

After#

Some other ideas#

Goodbye Textualize

Introducing Posting 2.0

Posting 2.0 - a TUI HTTP client

Pre-request and post-response scripts#

Viewing the status and output of scripts in Posting's new 'Scripts' tab.

Automatic reloading

Keymaps#

Customisable hostnames#

Running Posting locally

Running Posting on a production server

Documentation#

What’s next?#

Custom keymaps in Textual

Vim keys#

Copying and pasting in Textual

App.copy_to_clipboard#

Aside: How does it work?#

Consider pyperclip#

Integrating pyperclip with Textual#

Subclassing TextArea and adding a new binding#

Implementing the action_copy_selection method#

Using our new widget#

Which should I use?#

Let's get fractional! Textual layouts with fr units

A half-and-half layout#

The request and response sections are inside a Vertical container, and both have height: 1fr, creating a 50/50 split.

Changing the distribution#

Mixing concrete and fractional units#

The 'URLBar' widget in Posting.

Conclusion#

Learning

How terminals work#

My projects

Posting#

Elia#

Elia has a simple but powerful interface. It uses a SQLite backend to store your conversations locally, keeping your data private.

Dunk#

Dunk makes your diffs easy to read. I alias this as `gdd`, which runs `git diff | dunk | less -R`, resulting in a beautiful paged diff.

Textual’s TextArea widget#

The TextArea widget in action - running completely inside the terminal.

Ward (archived)#

Autocomplete#

Trogon#

Trogon gives you a sidebar menu containing all of the commands in your CLI. Clicking on an item shows you a form with all of the arguments and options for the selected command.

Radiant#

Screenshot of Radiant

Things I really like

Books#

`App.copy_to_clipboard`#

Consider `pyperclip`#

Integrating `pyperclip` with Textual#

Subclassing `TextArea` and adding a new binding#

Implementing the `action_copy_selection` method#

Textual’s `TextArea` widget#