Hi everyone! I’m excited to share uniwidth, a Unicode width calculation library I built for the Phoenix TUI Framework.
Why I built this
While working on Phoenix TUI, I hit a performance bottleneck with existing width calculation libraries. Terminal rendering needs to calculate character widths millions of times per second, and the overhead was noticeable. So I built uniwidth from scratch with performance as the primary goal.
What makes it fast
The library uses a tiered lookup strategy that handles ~95% of cases in O(1):
ASCII fast path (simple range check, no binary search)
Common CJK ranges (Unified Ideographs, Hangul, Hiragana/Katakana)
Common emoji ranges (Emoticons, Pictographs)
Binary search fallback…
Hi everyone! I’m excited to share uniwidth, a Unicode width calculation library I built for the Phoenix TUI Framework.
Why I built this
While working on Phoenix TUI, I hit a performance bottleneck with existing width calculation libraries. Terminal rendering needs to calculate character widths millions of times per second, and the overhead was noticeable. So I built uniwidth from scratch with performance as the primary goal.
What makes it fast
The library uses a tiered lookup strategy that handles ~95% of cases in O(1):
ASCII fast path (simple range check, no binary search)
Common CJK ranges (Unified Ideographs, Hangul, Hiragana/Katakana)
Common emoji ranges (Emoticons, Pictographs)
Binary search fallback only for rare characters
Benchmark results vs go-runewidth:
ASCII strings: 15-46x faster
CJK strings: 4-14x faster
Mixed content: 6-8x faster
Zero allocations for most cases
Features
Unicode 16.0 support with full East Asian Width compliance
Thread-safe (immutable design, no global state)
Options API for locale handling (ambiguous width, emoji presentation)
Comprehensive tests (87.1% coverage) including edge cases
Go 1.25+ with proper use of modern compiler optimizations
Real-world impact
In Phoenix TUI, switching to uniwidth reduced rendering overhead significantly. For a typical terminal with 80x24 cells updating at 60fps, that’s ~115,000 width calculations per second. The performance difference is measurable.
Try it
go get github.com/unilibs/uniwidth@v0.1.0-beta
Links:
GitHub: https://github.com/unilibs/uniwidth
Documentation: https://pkg.go.dev/github.com/unilibs/uniwidth
Benchmarks: https://github.com/unilibs/uniwidth/tree/main/bench
This is a beta release - I’m looking for feedback on the API and real-world testing. If you’re building TUI apps, terminal emulators, or CLI tools with table formatting, I’d love to hear how it works for you.
What do you think? Any questions or suggestions are welcome!
Note: This is a genuine project announcement, not AI-generated spam. I’m the actual developer and happy to answer technical questions about the implementation.