DEV Community: Subha S. Das

Why I Brought React-Like Hooks to Retui

Subha S. Das — Wed, 12 Aug 2026 08:02:15 +0000

Why I Brought React-Like Hooks to Retui

I didn't set out to copy React. I set out to stop writing terminal apps the way I'd been writing them for years — a giant switch statement on key events, a pile of mutable struct fields tracking "what screen am I on" and "what's selected right now," and a Draw() function that touched half of those fields just to figure out what to paint. It worked. It just didn't scale past a few hundred lines without becoming something I was afraid to touch.

Retui is a terminal UI framework in Go. Components are functions that return an Element. You describe what the screen should look like given the current state, and the framework figures out what to paint. That part isn't controversial — plenty of frameworks work that way. The part people ask me about is the hooks.

The problem I actually had

Before hooks, my components needed somewhere to keep state between renders. A text input needs to remember its cursor position. A list needs to remember which row is selected. In a typical Go TUI, you'd put that in a struct — type TextInputModel struct { value string; cursor int } — and pass it around, or embed it in some bigger app-state struct.

That's fine for one text input. It stops being fine when you have a form with fifteen fields, three of which are conditionally rendered, and you're trying to keep your app-state struct from turning into a 200-line God object that every component reads and writes.

React solved a version of this problem with hooks — useState inside a function component, without you having to define a class or a struct to hold it. I'd used enough React to know that model removes a specific kind of busywork: you stop having to design a state shape up front. You just call UseState where you need it, and move on.

So the question wasn't "should I copy hooks." It was "can this idea survive translation into Go, where I don't have closures over component instances the way JSX does, and I don't have a virtual DOM doing reconciliation for me."

What I tried first

My first instinct was the obvious one: attach state to a component instance. Give every component a stable identity — like React does with the fiber tree — and store its hook state on that instance. This is the "correct" way to do it, and if I were building this in a language with more DOM-like tree diffing built in, I probably would have.

I got about halfway through building it before I ran into the actual hard part: identity. React can give a component a stable identity across renders because JSX gives you a tree with keys, and the reconciler walks old-tree vs new-tree and matches nodes up. Building that matching logic correctly — handling conditional children, lists, reordering — is most of what makes React's reconciler genuinely complicated software. I didn't want to build a mini React reconciler in Go just to get storage location for a UseState call. That felt like solving a problem I didn't have yet, in service of an API convenience.

What I did instead

Retui's render loop calls your component function directly, in order, every frame. There's no tree diffing keeping track of "this Button is the same Button as last render." So instead of attaching hook state to a component instance, I attach it to render order.

Concretely: there's a global hook state slice, and a cursor into it. Every time you call UseState, UseEffect, or any other hook, it grabs the next slot in that slice, based on call order, not on which component you're "in." The cursor resets to zero at the start of each render pass. This is really close to how React's own hooks work internally, actually — React also relies on call order within a single component, which is why "don't call hooks conditionally" is a rule there too. I just stretched that same constraint across the whole app instead of scoping it per-component.

The honest description: hook state in Retui is process-global, not per-component-instance. It's an array, a cursor, and a straightforward set of rules about how you're allowed to call things.

Why this actually works better than it sounds

The first time I explain this to someone, they wince a little, and I get why. "Global state" sounds like the thing you're taught to avoid. But it comes with real upside that I didn't fully appreciate until I'd been using it for a few months.

It's fast, in a boring, predictable way. There's no reconciliation pass, no tree walk, no key-based matching to figure out which node is which. Getting a hook's value is an array index. That matters more in a terminal renderer than you'd think, because unlike a browser, you're often re-rendering on every single keystroke, and you don't get to hand the expensive part off to native DOM diffing.

It's also simple to reason about, once you accept the rule. If you've written React, you already half-know the rule: don't call hooks inside conditionals or loops, call them in the same order every render. I didn't invent that constraint — I inherited it, and honestly I think it's a reasonable one to inherit, because it's already proven itself as something developers can learn and live with.

Where I paid for it

I want to be straight about the costs, because I've eaten all of them personally.

The biggest one: because hook storage is global, Retui can currently only run one app per process. There's no story yet for "run two independent component trees side by side" or "embed a Retui screen inside a larger non-Retui program." For a terminal app that owns the whole screen, this has never actually bitten me — but I know it's a real limitation the moment someone wants to do something more creative with the framework, and I don't have a great answer for them yet.

The second one is testing. Hook-touching code can't safely run in parallel test cases right now, because they're all reading and writing the same global slice. I've structured the test suite around this — nothing runs t.Parallel() where hooks are involved — but it's a constraint I have to remember, not one the compiler enforces for me. That's the kind of thing that's fine when I'm the only maintainer keeping it in my head, and less fine as more people contribute.

There's a smaller, uglier problem too: dynamic lists. If you're rendering UseState inside a loop — say, one call per row in a table — call-order-based storage breaks, because the list can grow, shrink, or reorder between renders, and "the fifth hook call" stops meaning the same thing. React handles this with key props on elements, feeding into its reconciler. I don't have a reconciler, so I couldn't reuse that mechanism. I ended up adding a second hook, UseStateKeyed, that takes an explicit string key instead of relying on position. It works, but it means there are now two ways to keep state, and a developer has to know which one to reach for. That's an API smell I made peace with rather than one I'm proud of. It's the kind of trade-off you make when you're solving a real problem under a self-imposed constraint, and I'd rather have an honest wart than pretend the constraint didn't cost me anything.

I also learned, a bit painfully, that a hook-order bug — calling UseState conditionally by accident — can silently reset a piece of state instead of loudly failing. In React that kind of mistake tends to throw. In my current implementation, it can just quietly hand you back the initial value, and you spend twenty minutes wondering why your component "forgot" what the user typed. That's on my list to fix by making it fail loudly in development builds, because a silent bug is so much worse to debug than a panic with a stack trace.

Where I think this goes next

I don't think the global-state model is the final form. If Retui grows to the point where people want multiple independent app instances in one process, or safer parallel testing, I'll need to move hook storage onto something scoped to a runtime instance instead of a package-level variable. I know roughly what that refactor looks like, and I know it's a breaking change to the internals, even if the public UseState call signature barely changes for the end user.

I haven't done it yet, for one honest reason: nobody has asked for it in a way that told me it was actually blocking them. I'd rather ship a slightly compromised design that real people are using than a theoretically cleaner one that solves a problem nobody has yet. That's a value judgment, not a law of nature, and I could be wrong about the timing.

What I took from this whole process is a smaller point about borrowing ideas across ecosystems. The part of React worth stealing wasn't the virtual DOM, or the reconciler, or JSX. It was the much simpler idea underneath all of that: let a function remember things across calls without forcing the developer to design a state container up front. That idea is portable. The machinery React built to support it, in a language and runtime shaped very differently from Go, wasn't something I needed to copy wholesale — and trying to copy it exactly would have meant solving problems Go and a terminal renderer don't actually have.

🔗 Retui: https://github.com/subhasundardass/retui

If you've ever built a framework, library, or even a complicated internal tool, I'd love to hear about a design decision you're still not completely sure about.

Those are usually the most interesting ones.

From an idea to an open-source Go framework: where RetUI is today.

Subha S. Das — Fri, 07 Aug 2026 16:17:07 +0000

A few months ago, RetUI was just an idea.
I wanted a different way to build terminal applications in Go—something that could provide a modern, component-based developer experience without losing the simplicity and power of the terminal.

Since then, RetUI has grown quite a bit.
I've been working on:

• Component-based UI
• React-inspired hooks and state management
• Flexible, Flexbox-inspired layouts
• Keyboard and focus management
• Screen navigation
• Modals, overlays and toasts
• Reusable form controls
• Tables and other UI components
• Developer tooling and VS Code snippets

But building the framework is only one part of the journey.
The bigger challenge is making it easy for other developers to discover, understand, use and contribute to it.
That's what I'm focusing on now.

I'm continuing to improve RetUI, build real applications with it, improve the documentation, and make the developer experience better with every iteration.

It's still a work in progress—but that's the exciting part of building in public.

If you're a Go developer:
What would you want to see in a modern terminal UI framework?
I'd genuinely love to hear your ideas.

⭐ Explore RetUI on GitHub:(https://github.com/subhasundardass/retui)

Why I Chose React-Like Hooks in Retui

Subha S. Das — Mon, 03 Aug 2026 07:10:16 +0000

When I started building Retui, I had one goal: make terminal application development feel simple and enjoyable.

As a developer, I have worked with many UI frameworks over the years. One thing I always liked about React was its Hooks. They made it easy to manage state and keep components clean. I wanted to bring the same experience to terminal applications written in Go.

A Familiar Way to Build

Many developers already know how React Hooks work.

Instead of asking them to learn a completely new programming model, Retui lets them write components in a familiar way.

go
func Counter() retui.Element {
count, setCount := retui.UseState(0)

return components.Button().
    Label(fmt.Sprintf("Count: %d", count)).
    OnClick(func() {
        setCount(count + 1)
    })

}

The code is easy to read. The state stays close to the UI, making it much easier to understand.

Less Boilerplate

Without hooks, even a small component often needs extra structs, initialization code, and methods just to store a few values.

With hooks, I can write the logic in a single function.

That means less code, fewer files, and less time spent switching between different parts of the project.

State Belongs to the Component

Every component should manage its own state whenever possible.

A text input should know its current value. A checkbox should know whether it is checked. A dialog should know whether it is open.

Hooks make this natural. Each component owns its own state without requiring a large global state manager.

Where the State Actually Lives

Here is the part I go back and forth on the most.

In React, hook state is attached to the component instance itself. Retui does not work that way. Underneath the API, state is kept in one shared store, and each call to UseState gets its own slot based on the order hooks are called in.

This was not the plan from day one. I first tried to copy React's approach and attach state to each component instance. It worked, but it meant building something close to a reconciler just to track which instance was which. That was a lot of machinery for a young framework with a small render loop, so I stepped back and went simpler.

The trade-off is real, and I want to be upfront about it. Because state lives in one shared place, calling the same component twice without a unique key can cause two instances to read and write the same slot. React avoids this because the tree structure gives every instance its own identity for free. Retui does not have that, so the developer has to be a bit more careful, especially with lists of repeated components.

For that case, Retui has UseStateKeyed, which stores state by a string key instead of call order. It is less automatic, but it is honest about how the state is stored, and it has kept the internals small enough that I can still debug the whole thing in one sitting.

Easier to Reuse

Hooks also encourage small, reusable components.

Instead of creating one large screen with hundreds of lines of code, I can split it into many small components, each with its own state and logic.

Smaller components are easier to test, maintain, and reuse in other projects.

Side Effects Are Clear

Sometimes a component needs to perform an action after rendering.

For example:

Load data
Start a timer
Listen for keyboard events
Clean up resources

UseEffect keeps this logic separate from the UI itself, making the component much easier to follow.

It Feels Natural

One of my goals with Retui is to make developers focus on building applications instead of worrying about framework code.

When I write a Retui component, I want it to feel like writing a normal Go function.

Hooks help achieve that.

Is Retui Trying to Copy React?

Not exactly.

Retui is written in Go, not JavaScript.

The rendering system, terminal handling, and internal architecture are completely different.

What I borrowed is the developer experience.

React Hooks solved a real problem, and I believe the idea works just as well for terminal applications.

Final Thoughts

I didn't add hooks because they are popular.

I added them because they make code simpler.

They reduce boilerplate, keep state close to the UI, encourage reusable components, and make applications easier to maintain.

If you've used React before, Retui will feel familiar.

If you haven't, you'll probably find that hooks are simply a clean and practical way to build terminal applications.

Retui is open source. If you want to see how the hooks system is built, or you disagree with a decision I made, the code is on GitHub: github.com/subhasundardass/retui.

I Tried to Build a UI Framework With No Pixels. Here's What Broke My Brain First.

Subha S. Das — Sat, 18 Jul 2026 09:15:16 +0000

A few months ago I wanted to build a small command-line tool. Nothing fancy — just a form, a list, maybe a modal dialog. The kind of thing you'd knock out in an afternoon with a modern app framework.

Then I looked at what "building a UI" actually means in a terminal, in Go.

It means you get a grid of characters. You decide what character goes in row 12, column 40. You track cursor position by hand. If something changes — say, a counter goes from 4 to 5 — you are responsible for figuring out that only that one character needs to be redrawn, and you write the code to redraw it, or you just repaint the whole screen and accept the flicker.

I sat there thinking about how modern UI toolkits — component trees, widgets, declarative layout — solved this exact problem years ago on the web and on mobile. Nobody manually paints pixel-by-pixel anymore. You just describe what the UI should look like right now, and something underneath figures out the minimum work to make that true.

So I asked a question that turned into a much bigger rabbit hole than I expected: could I build that "something underneath" myself, with nothing but 80 columns and 24 rows of monospace text to work with?

That question is what this article is actually about. Not "look at my project" — but the three ideas that quietly hold together every declarative UI system you've ever used, which I only truly understood once I was forced to build cheap, ugly, terminal-shaped versions of them myself. If you've ever used a state hook or a widget tree without thinking about what it's doing underneath, I think you'll enjoy this.

(If you want to see where all of this landed, it's an open-source terminal UI framework for Go called retui — link's at the bottom too, no pressure, read on first.)

Puzzle #1: Where does component state actually live?

Here's a question that sounds trivial until you try to implement it: when a component asks for a piece of state and gets back a value plus a setter, where does that value actually live between renders?

It's not a local variable — those reset every time the component function runs, and it does run again on every render. It's not a class field — you don't need a class for this pattern. So where does it live, and how does the framework know to hand back the fifth update instead of the first?

The answer, once you build it yourself, is almost anticlimactic: the state lives outside the component entirely, in a plain list, indexed by call order.

Here's roughly what that looks like when you strip away all the optimizations:

govar stateSlots []interface{}
var stateCursor int

func UseState(initial interface{}) (interface{}, func(interface{})) {
    idx := stateCursor
    stateCursor++

    if idx >= len(stateSlots) {
        stateSlots = append(stateSlots, initial)
    }

    setState := func(newVal interface{}) {
        stateSlots[idx] = newVal
        requestRerender()
    }

    return stateSlots[idx], setState
}

Before every render, stateCursor resets to zero. Your component function runs top to bottom, and every state call claims the next slot in order — the first call always gets slot 0, the second call always gets slot 1, forever, on every single render.

This single fact is why "don't call state hooks conditionally" is a rule in basically every framework that uses this pattern. It's not an arbitrary style guideline — it's a direct consequence of how the storage works. If you wrap a state call in an if, you shift every call after it into the wrong slot on renders where the condition is false, and your component starts reading and writing the wrong state entirely. Once you've built the slot array yourself, that rule stops feeling like a rule and starts feeling like simple arithmetic.

*Puzzle #2: How do you redraw only what changed, on a grid of text?
*
Slot-based state solves storage. It doesn't solve the much scarier problem: once state changes, how do you update the screen without repainting everything?

Repainting everything is easy, and it's also what full-screen terminal apps did for decades — clear the screen, redraw every line. You'll notice the flicker immediately if you've ever used an old ncurses app over a slow connection.

The fix is the same one modern UI frameworks landed on, on the web and on mobile: diffing. You render your UI as a tree of lightweight description objects (an "element tree," not the real thing on screen), compare it to the tree from last time, and only touch the parts that differ.

A minimal version of that idea looks like this:

gofunc diff(old, new Element, x, y int) {
    if old == nil && new != nil {
        paint(new, x, y)
        return
    }
    if old != nil && new == nil {
        erase(old, x, y)
        return
    }
    if old.Text != new.Text || old.Style != new.Style {
        paint(new, x, y)
    }
    for i := range new.Children {
        diff(childAt(old, i), new.Children[i], childX(i), childY(i))
    }
}

Nothing here is clever. It's a recursive tree walk, comparing corresponding nodes and only issuing a paint instruction where something actually differs. What surprised me wasn't the diffing itself — it's that once you have it, an enormous amount of complexity elsewhere in the framework simply disappears. Your component doesn't need to know if it's the first render or the fiftieth. It doesn't need to track "did my text change." It just describes what it wants, every time, and the diffing layer absorbs all the bookkeeping. That's the actual gift declarative UI gave developers, and it turns out to be just as valuable when the "screen" is a grid of monospace characters instead of pixels.

Puzzle #3: The bug that taught me the most — events don't know when to stop

Here's a problem that has nothing to do with rendering and everything to do with a mental model I hadn't questioned before: when a key is pressed, who gets it, and who decides when it's "handled"?

Say you have a modal dialog open — a settings panel, a confirmation box, whatever — sitting on top of your main screen. You press Escape. Obviously the modal should close. But naively, the same Escape keypress often also reaches whatever's listening underneath, and now your entire app quits too, because your main screen also happens to treat Escape as "exit."

Every layered UI system needs an answer for this — some way for an inner layer to say "I've dealt with this, don't let it go any further." Most of us have used that mechanism a hundred times without thinking hard about what it's actually preventing. I hadn't, either — not until I had to build the equivalent from scratch, with no framework underneath me to lean on.

The fix, once you see it, is almost embarrassingly simple: every layer that can handle a key needs to return a plain bool — "did I consume this?" — and every layer above it needs to actually check that value before deciding to do anything itself.


gofunc (w *Window) HandleKey(key Key) bool {
    if w.onKeyPress != nil {
        return w.onKeyPress(key) // true = stop here
    }
    return false
}

The subtle trap is that it's incredibly easy to write this correctly at one layer and then forget to check the return value one layer up — the compiler won't catch it, because ignoring a bool is perfectly legal Go. I did exactly that. My modal closed, and then, one frame later, so did the app underneath it — because the outer event loop was still calling the dispatch function and just throwing away what it returned. The fix was one line. Finding it took an embarrassingly long time, because the bug only shows up on the specific key that both layers care about.

If there's one thing I'd want a reader to take away from this whole piece, it's that: "stop this event from going any further" isn't a web-specific or mobile-specific idea. It's the general answer to "multiple things want to react to the same event, but only one of them should win," and that problem shows up anywhere you have layered UI — web, terminal, mobile, doesn't matter.

Why I think this is worth trying yourself

None of this is novel. Every modern declarative UI system — on the web, on mobile, wherever — converges on similar answers, because the underlying problem is the same regardless of what's rendering the pixels (or characters). But there's a real difference between reading that state hooks are "just an array indexed by call order" and being the one who has to make that true, bug by bug, at 11pm, wondering why your fifth state call is returning your third component's data.

If you've ever wanted a weekend project that will genuinely deepen how you think about a framework you already use every day, I'd recommend picking the smallest possible surface — a todo list, a counter, anything — and building the rendering layer underneath it yourself, with no framework at all. You will hit the exact three puzzles above, in roughly that order, and you'll come out the other side reading your favorite framework's source with completely different eyes.

Where this actually landed

I kept building past the weekend-project point, mostly because Go terminal apps turned out to be genuinely fun to work on. That turned into retui — a small, component-based framework for building terminal UIs in Go, with state hooks, a flexbox-ish layout system, and the diffing/event-propagation machinery described above holding it together underneath.

🔗 Repo: github.com/subhasundardass/retui

It's still young, the API still has rough edges, and I'd genuinely welcome anyone poking holes in it, filing issues, or just telling me which part of this post made you go "wait, that's not how I'd have done it" — that's usually where the interesting conversations start.

What's the last piece of "invisible framework magic" you got curious enough to actually go implement yourself? I'd love to hear about it in the comments.

Why I Started Building RetUI - A Modern Terminal UI Framework for Go

Subha S. Das — Mon, 13 Jul 2026 13:29:02 +0000

As developers, we spend a lot of time building graphical applications for the web and desktop. Yet, some of the most powerful tools we use every day still live in the terminal.

Over the years, I've used several Go terminal UI libraries. They are powerful and have enabled many great applications. But while building increasingly complex terminal applications, I found myself wanting a different developer experience.

I wanted to build terminal applications the same way I build modern web applications.

That's why I started RetUI.

The Problem
Most terminal UI libraries focus on rendering widgets. They do a great job at that, but as applications grow, developers often end up managing:

Complex layouts
Keyboard navigation
Focus management
Component communication
Application state
Window and modal management

As these responsibilities grow, application code can become harder to organize and maintain.

I wanted a framework that helps solve these problems while keeping the code clean and enjoyable to write.

My Vision

RetUI is inspired by the ideas that made modern frontend development productive.

I want developers to think in terms of components, not terminal drawing primitives.

Instead of worrying about how to paint every character on the screen, developers should be able to focus on building their application.

Design Goals

RetUI is being built around a few simple principles:

Simple and expressive APIs
Reusable components
Predictable state management
Flexible layouts
Excellent keyboard support
High performance
Easy to learn
Easy to extend

Why Another Framework?

This isn't about replacing existing Go TUI libraries.

The Go ecosystem already has excellent projects, and I've learned a lot from them.

RetUI explores a different direction—bringing a more component-driven development style to terminal applications while remaining lightweight and idiomatic in Go.

If this approach helps even a small group of developers build better terminal applications, then the project will have achieved its purpose.

The Journey

RetUI is still in its early stages.

There will be bugs.
There will be redesigns.
Some APIs will change.

That's part of building software.

I'm sharing the project early because I believe open-source software grows stronger through feedback and collaboration.

Join Me

If you're interested in terminal applications, Go, or developer tooling, I'd love to hear your thoughts.

Whether it's reporting bugs, suggesting ideas, improving documentation, or contributing code, every bit of feedback helps.

Let's see how far we can push terminal applications with Go.

This is just the beginning of the RetUI journey.

subhasundardass / retui

RETUI is a lightweight, component-driven framework for creating beautiful, interactive Terminal User Interfaces (TUIs) in Go.

retui

A Go framework for building interactive terminal UIs with React-style components and hooks.

Inspired by React and Flutter, retui brings a component-based, reactive approach to building terminal applications — write functional components, manage state with hooks, and let a flexbox layout engine handle the rest.

Features

Functional components — plain Go functions that return an Element tree
Hooks — UseState, UseEffect, and UseContext
Flexbox layout engine — two-pass (measure → layout) with Row/Column direction, Gap, Padding, Align, Justify, and Fixed/Grow/Fit sizing
Rich styling — ANSI16, ANSI256, and RGB/Hex colors; bold, italic, underline; four border presets
Bracketed paste — multi-line clipboard content arrives as a single KeyPaste event
Built-in component library — Table, Tabs, Modal, Input, Button, Checkbox, List, SelectPicker, Spinner, ProgressBar, Alert, Badge, Panel
Efficient rendering — cell-level…

View on GitHub

Building a Window Management System for Terminal UIs

Subha S. Das — Tue, 07 Jul 2026 14:33:36 +0000

Terminal User Interfaces (TUIs) have come a long way from simple menus and forms. Modern TUI applications increasingly need sophisticated UI paradigms—multiple panels, popups, dialogs, and floating windows. However, building a robust window management system from scratch presents unique challenges in the terminal environment.

In this article, I'll walk through the architecture, design decisions, and challenges faced while building a complete window management system for TUI applications. The full source lives on GitHub at subhasundardass/tuix, if you'd rather read the real code than just the snippets below. The code we'll discuss provides a production-ready window manager with features like:

Floating windows with absolute positioning
Modal windows that block background interaction
Z-order management (window stacking)
Focus management with keyboard navigation
Fluent API for easy window configuration
Thread-safe operations

Why Build a Window System for TUIs?

I didn't set out to build a window manager. I set out to add a "confirm delete" dialog to a CLI tool, and about three days later I had a hundred-line rabbit hole on my hands.

Here's the thing nobody tells you when you start writing TUIs: the terminal was never designed for overlapping surfaces. A GUI toolkit gives you compositing, z-buffers, and a windowing system for free — the OS handles it. In a terminal, you get a grid of cells and a cursor. That's it. If you want one panel to visually sit "on top of" another, you have to figure out what that even means when both are just characters being written to the same 2D buffer.

Most TUI libraries sidestep this by giving you a single, fixed layout — a tree of panes that split the screen and never overlap. That's fine until your app actually needs a popup. A confirmation dialog. A command palette. An autocomplete dropdown that has to float above whatever's underneath it without destroying that content. At that point, you're not laying out boxes anymore — you're managing a window system, whether you meant to or not.

So that's what I built. Not because it was the fun weekend project I was planning, but because every alternative I tried (special-casing "just this one popup," hacking a second screen buffer, praying) fell apart the second I needed a second popup on top of the first one.

The Core Problem: Everything Shares One Buffer

In a real windowing system, each window typically owns its own surface, and the compositor merges them at the end. Terminals don't give you that. Every widget, every panel, every floating dialog is ultimately writing characters into the same flat buffer that gets flushed to the screen.

That means a "window manager" for a TUI isn't really managing windows in the OS sense — it's managing draw order and input routing against a shared canvas. Two problems fall out of that immediately:

Rendering order matters enormously. If window B is on top of window A and they overlap, B has to be drawn after A, cell by cell, or you get visual garbage — characters from the wrong window bleeding through.
Input has to be routed, not broadcast. A keypress can only go to one place at a time (or, for modals, be deliberately blocked from going anywhere else). Figure out who "owns" the terminal at any given moment, and you've solved half the problem.

Everything else in the system — z-ordering, focus, modality — is really just infrastructure built to answer those two questions cleanly.

Architecture: Windows as a Managed Stack

The design I landed on treats every floating surface as a Window struct with a handful of properties: position, size, content, a z-index, and some behavioral flags (is it modal, is it focusable, is it currently visible). The WindowManager owns a slice of these, sorted by z-index, and it's the single source of truth for "what's currently on screen and in what order."

type Window struct {
    ID          string
    Title       string
    X, Y        int
    Width       int
    Height      int
    ZIndex      int
    Modal       bool
    Focusable   bool
    Visible     bool
    Content     Drawable
}

type WindowManager struct {
    mu       sync.RWMutex
    windows  []*Window
    focused  string
    nextZ    int
}

The mu sync.RWMutex up there isn't decoration. TUI apps that pull data from network calls or background jobs will very often want to pop up a "loading" window or update content from a goroutine, and the moment you have concurrent writers touching the window stack, you need real locking — not a "well it's probably fine" shrug. More on that later.

Every operation that changes what's visible — opening a window, closing one, bringing one to front — goes through the manager rather than mutating window state directly. That single choke point is what makes the rest of the system tractable.

Floating Windows and Absolute Positioning

The base layout system in most TUI frameworks works in relative terms: split the screen, size things as a fraction of their container, let the framework do the arithmetic. Floating windows break that model on purpose — they need to say "put me at row 10, column 20, and I don't care what else is on screen."

func (wm *WindowManager) Open(w *Window) {
    wm.mu.Lock()
    defer wm.mu.Unlock()

    w.ZIndex = wm.nextZ
    wm.nextZ++
    w.Visible = true

    wm.windows = append(wm.windows, w)
    wm.focused = w.ID
}

Positioning itself is simple math — clamp X/Y so the window doesn't render off the edge of the terminal, clamp width/height so it doesn't exceed the available rows and columns. The part that's not simple is what happens when two floating windows overlap, which is really a rendering problem more than a positioning one.

Rendering: Painter's Algorithm, Terminal Edition

Once windows are sorted by z-index, rendering is conceptually just the painter's algorithm from computer graphics: draw the bottom-most window first, then paint each subsequent window on top, letting later windows overwrite earlier ones cell by cell.

func (wm *WindowManager) Render(screen *Buffer) {
    wm.mu.RLock()
    defer wm.mu.RUnlock()

    sorted := make([]*Window, len(wm.windows))
    copy(sorted, wm.windows)
    sort.Slice(sorted, func(i, j int) bool {
        return sorted[i].ZIndex < sorted[j].ZIndex
    })

    for _, w := range sorted {
        if !w.Visible {
            continue
        }
        w.Content.DrawInto(screen, w.X, w.Y, w.Width, w.Height)
    }
}

The subtlety is in DrawInto. It's not enough to write a window's characters into the buffer — you also have to write its background, including a drop shadow or border if the window has one, so it visually reads as "in front of" whatever it's covering rather than looking like it's been stamped through the layer below. I ended up drawing a one-cell shadow offset to the bottom-right of every floating window; it's a small touch, but it's the single biggest thing that made the UI feel like actual overlapping windows instead of just "text with holes in it."

Modal Windows: Blocking on Purpose

Modals are conceptually simple — a window that owns input exclusively until it's dismissed — but they expose a design question that's easy to get wrong: does "modal" live on the window, or on the manager?

I put it on the manager, computed from the window stack, rather than as a standalone flag anywhere else in the app:

func (wm *WindowManager) TopModal() *Window {
    wm.mu.RLock()
    defer wm.mu.RUnlock()

    for i := len(wm.windows) - 1; i >= 0; i-- {
        if wm.windows[i].Modal && wm.windows[i].Visible {
            return wm.windows[i]
        }
    }
    return nil
}

func (wm *WindowManager) HandleInput(ev InputEvent) {
    if modal := wm.TopModal(); modal != nil {
        modal.Content.HandleInput(ev)
        return
    }
    if focused := wm.FocusedWindow(); focused != nil {
        focused.Content.HandleInput(ev)
    }
}

That "top-most modal wins, full stop" rule matters because you'll eventually stack modals — a confirmation dialog spawned from within another dialog is a completely normal thing for users to trigger, and if your modal logic isn't stack-aware, the second dialog either won't block correctly or will block the wrong thing. Deriving modality from the stack, instead of tracking "is anything modal right now" as separate boolean state, means it's correct by construction no matter how deep the stack gets.

Focus Management and Keyboard Navigation

Mouse support in terminals is inconsistent enough across emulators that keyboard navigation isn't optional — it's the primary interface for a meaningful chunk of your users. That makes focus tracking one of the more important pieces of the whole system, even though it looks like the most boring one.

The rule I settled on: focus always follows the top of the z-stack unless the user explicitly moves it (Tab / Shift+Tab between focusable windows, or clicking a window if the terminal supports mouse events). Opening a new window focuses it automatically; closing a window returns focus to whatever is now on top.

func (wm *WindowManager) CycleFocus(reverse bool) {
    wm.mu.Lock()
    defer wm.mu.Unlock()

    focusable := wm.focusableWindows()
    if len(focusable) == 0 {
        return
    }

    idx := indexOf(focusable, wm.focused)
    if reverse {
        idx = (idx - 1 + len(focusable)) % len(focusable)
    } else {
        idx = (idx + 1) % len(focusable)
    }
    wm.focused = focusable[idx].ID
    wm.BringToFront(focusable[idx].ID)
}

One detail that took a couple of iterations to get right: bringing a window to front on focus is usually what you want, except for background utility windows — a status bar, a log panel — that shouldn't jump on top of a modal just because they briefly held focus. I ended up adding a Sticky flag for exactly that case, which excludes a window from z-reordering even while letting it stay focusable.

The Fluent API

None of the above is much fun to configure by hand every time you want a dialog. So the actual thing most consumers of this library touch is a builder:

window := NewWindow("confirm-delete").
    Title("Confirm Delete").
    Size(40, 8).
    Position(Center, Center).
    Modal(true).
    Content(confirmDialog).
    OnClose(func() {
        log.Println("dialog dismissed")
    }).
    Build()

wm.Open(window)

Position(Center, Center) deserves a mention — it's resolved lazily, against the current terminal dimensions, at the moment the window is opened rather than when it's built. That matters because terminals resize, and a window built once but reused across multiple opens (a settings dialog, say) needs to re-center correctly every time, not just the first.

The fluent style isn't just sugar. It front-loads validation — width/height bounds, ID collisions, invalid position combos — into the builder, so Open() can assume it's always handed a well-formed window instead of defensively checking everything at render time.

Thread Safety: The Part That Bites You Later

I'll be honest — the first version of this didn't have a mutex anywhere. It worked fine, right up until I wired in an async data fetch that wanted to close a "loading" window and open a "results" window from a goroutine while the main loop was mid-render. The result was a window stack that occasionally rendered with a window half-removed — not a crash, just silent visual corruption, which is a much worse bug to track down.

The fix is the sync.RWMutex from earlier, applied consistently: every mutation takes the write lock, every read (including the render pass) takes the read lock. The one rule that took discipline to enforce was making sure Content.HandleInput and Content.DrawInto — the callbacks into user-supplied window content — never get called while the manager's lock is held, since a badly behaved callback that tries to open another window from inside its own draw call would deadlock instantly. Snapshotting the sorted window list before iterating, as in the Render function above, solves that cleanly: the lock only needs to cover the bookkeeping, not the actual drawing.

What I'd Do Differently

A few things I'd change if I were starting over:

Dirty-rect tracking. Right now every render redraws the full stack from scratch. It's fast enough for the window counts a typical TUI app actually has, but it's wasteful, and a diff-based redraw would matter a lot for anything with animation.
Resize events per-window. Terminal resizes currently trigger a full re-layout pass across every open window. Most windows don't need to know or care that the terminal resized unless they're centered or edge-anchored; a subscription model would cut a lot of unnecessary work.
Better shadow/border theming earlier. I treated visual polish as a late-stage concern and regretted it — the shadow-offset trick that made floating windows read as floating was worth doing on day one, not day twelve.

Closing Thoughts

The terminal is a genuinely constrained environment, and it's easy to underestimate how much of "real" windowing — layering, focus, modality — you end up reimplementing the moment your TUI needs more than a single static layout. None of the individual pieces here are exotic; it's mostly careful bookkeeping around a shared buffer and a very literal notion of "on top." But that bookkeeping is exactly the part that's tedious to get right under deadline pressure, which is usually when people reach for a shortcut and end up with popups that flicker, dialogs that don't block correctly, or focus that silently gets lost. Getting the primitives right once, and building everything else on top of them, turned out to be worth the three days it wasn't supposed to take.

If you want to dig into the actual implementation, run it yourself, or file an issue about something I got wrong, the repo is at github.com/subhasundardass/tuix. Stars, forks, and PRs are all welcome — and if you build something with it, I'd love to hear about it.

Not every UI needs a browser.

Subha S. Das — Fri, 19 Jun 2026 08:29:00 +0000

Building a Dashboard-Style Terminal UI (TUI) in Go 🚀

As developers, we often default to web applications and desktop GUIs. But sometimes, a Terminal User Interface (TUI) can be a powerful alternative—especially for internal tools, dashboards, DevOps utilities, and ERP systems.

Over the last few days, I've been experimenting with building a dashboard-style TUI in Go using the tview library. The goal wasn't just to display text in a terminal, but to create an experience similar to a modern admin dashboard:

✅ Sidebar navigation with nested menus
✅ Dashboard KPI cards (Users, Revenue, Orders, Products)
✅ ERP-style data tables with proper alignment and financial columns
✅ Dynamic page switching and screen management
✅ Keyboard-driven navigation and focus handling
✅ Modular architecture with reusable components

Why a TUI?

A terminal application offers some interesting advantages:

Lightweight: No browser or heavy runtime required.
Fast: Minimal resource consumption and quick startup.
Cross-platform: Build once and run almost anywhere.
Keyboard-first workflow: Extremely productive for power users.
Ideal for internal systems: Monitoring tools, administration panels, DevOps dashboards, and enterprise applications.
Architecture Approach

Instead of placing all UI logic in one file, I designed the application with a modular structure:

Application
├── Bootstrap
├── Screen Manager
├── Layout Manager
│ ├── Header
│ ├── Sidebar
│ ├── Content Pages
│ └── Footer
├── Screens
│ ├── Home
│ ├── Orders
│ └── Settings
└── Shared Components

The Screen Manager handles page registration and navigation, while the Layout Manager keeps global components such as the sidebar and header persistent.

Challenges I Encountered

Building a dashboard in a terminal is surprisingly different from building one on the web:

Focus Management

Managing keyboard focus between the sidebar and page content required careful handling. Determining which component should own focus at any given moment is crucial for a good user experience.

Table Alignment

Unlike HTML tables, tview.Table doesn't provide CSS-like control. Proper alignment of financial data (Amount, Tax, Discount, Total) required manual configuration and thoughtful layout design.

Dashboard Density

Creating information-dense dashboards in a terminal is challenging because terminal UIs have limited styling capabilities compared to modern web frameworks.

Component Architecture

Separating screens, layouts, navigation, and shared widgets became essential to keep the application maintainable as it grew.

What I Learned

Terminal applications are not just nostalgic throwbacks. They can still be highly effective for:

ERP systems
Administrative dashboards
Monitoring tools
DevOps platforms
Internal business applications
Data management systems

Go's simplicity, performance, and excellent libraries such as tview and tcell make it an enjoyable ecosystem for building these kinds of applications.

What's Next?

I'm planning to explore:

Dynamic widgets and plugin architecture
Better table experiences (sorting, filtering, pagination)
Modal windows and drill-down screens
Event-driven screen communication
More condensed and information-rich layouts

Building this project reminded me that great software doesn't always require a browser. Sometimes, a well-designed terminal interface can be remarkably productive and elegant.

Have you built a Terminal UI application before? Which language or framework would you choose for it?

Odoo Customisation & Module Development

Subha S. Das — Thu, 05 Mar 2026 10:51:52 +0000

Custom Odoo modules, workflow enhancements, and integrations aligned with your operations.

Odoo is one of the most powerful open-source business management platforms available — covering CRM, accounting, inventory, HR, manufacturing, e-commerce, and more. But out of the box, Odoo is built for the average business. Your business isn't average. Your business isn’t average.

Odoo customisation means modifying or extending Odoo to match your exact operational requirements — from small UI adjustments and custom fields, all the way to fully bespoke modules that add entirely new functionality. As the leading Odoo expert in Siliguri, we work with businesses across North Bengal and globally, helping them unlock Odoo's true potential through smart, purposeful customisation.

Discover how a Transport Management System (TMS) helps Indian transport businesses save time, reduce costs, and manage deliveries and fleets easily. read more at https://dorii.in/blog/what-is-tms

Subha S. Das — Tue, 10 Feb 2026 13:22:22 +0000

What Is a Transport Management System (TMS)? Complete Guide | Dorii Software

Discover how a Transport Management System (TMS) helps Indian transport businesses save time, reduce costs, and manage deliveries and fleets easily.

dorii.in

DEV Community: Subha S. Das

Why I Brought React-Like Hooks to Retui

Why I Brought React-Like Hooks to Retui

The problem I actually had

What I tried first

What I did instead

Why this actually works better than it sounds

Where I paid for it

Where I think this goes next

From an idea to an open-source Go framework: where RetUI is today.

Why I Chose React-Like Hooks in Retui

I Tried to Build a UI Framework With No Pixels. Here's What Broke My Brain First.

Why I Started Building RetUI - A Modern Terminal UI Framework for Go

subhasundardass / retui

RETUI is a lightweight, component-driven framework for creating beautiful, interactive Terminal User Interfaces (TUIs) in Go.

retui

Table of Contents

Features

Building a Window Management System for Terminal UIs

Why Build a Window System for TUIs?

The Core Problem: Everything Shares One Buffer

Architecture: Windows as a Managed Stack

Floating Windows and Absolute Positioning

Rendering: Painter's Algorithm, Terminal Edition

Modal Windows: Blocking on Purpose

Focus Management and Keyboard Navigation

The Fluent API

Thread Safety: The Part That Bites You Later

What I'd Do Differently

Closing Thoughts

Not every UI needs a browser.

Odoo Customisation & Module Development

Discover how a Transport Management System (TMS) helps Indian transport businesses save time, reduce costs, and manage deliveries and fleets easily. read more at https://dorii.in/blog/what-is-tms

What Is a Transport Management System (TMS)? Complete Guide | Dorii Software