SugarCraft vs. the alternatives.

Honest, side-by-side. SugarCraft isn't the right tool for every terminal program — but for the things it's built for, the alternatives don't really compete.

vs. Symfony Console

Symfony Console is the de-facto standard for PHP command-line tools. It's excellent for one-shot commands — php artisan migrate, composer install, php bin/console cache:clear. Argv parsing, I/O helpers, an option / argument DSL.

What it isn't built for: persistent terminal UIs. Once your program needs a render loop — a dashboard with a ticking clock, a wizard with form validation as you type, a log tailer that keeps a header pinned at the top — Symfony Console doesn't give you the primitives. You'd be hand-rolling the same fixes SugarCraft already ships: cell-aware diff rendering, raw-mode input, signal handling, alt-screen lifecycle.

Pick Symfony Console for: argument parsers, one- shot scripts, pipeline tools, anything that exits cleanly after printing a result.

Pick SugarCraft for: anything with a render loop.

The two compose nicely. The pattern we like: Symfony Console for the outer CLI surface (php app foo --bar=baz), and SugarCraft Program::run() inside one of the commands when you need a TUI.

vs. raw readline / fread(STDIN)

For the simplest interactive prompts — readline("y/N: "), fgets(STDIN), a "press any key" pause — raw stdio is fine and zero deps.

But you hit a wall fast. Arrow keys, function keys, bracketed paste, mouse, alt-screen, signal-driven resizes, terminfo capability detection, true-color support, OSC 8 hyperlinks — every step past "single line of text" pulls in a stack of escape-sequence grammar that SugarCraft already implements correctly.

Pick raw I/O for: a single password prompt, a yes/no, scripts where adding a Composer dependency feels heavier than the script itself.

Pick SugarCraft for: the moment you write a second echo "\033[".

Where the inspiration came from

SugarCraft is a PHP-native project. Its original design inspiration came from the Go terminal ecosystem — notably Bubble Tea and the wider Charm family of libraries — reimagined here for PHP 8.3+. That is where the similarity ends: every package here is built and shipped in PHP, for PHP toolchains.

Pick SugarCraft for: PHP-native shops that want a Composer-installable TUI stack — drop-in to existing Symfony / Laravel / Yii / WordPress tooling, no polyglot build, no separate binary pipeline.

Architecture decisions worth noting

• Cursed cell-diff renderer — a compact-repaint mode that ships the full screen once, then streams only changed cells — is a first-class option in SugarCraft via cellDiffRenderer: true. Verified ≥15% bandwidth savings on a 50-tick counter test — the kind of win that matters when your TUI is served over SSH.
• SugarSshServer leans on OpenSSH. Rather than re-implementing the SSH wire protocol, SugarSshServer runs as a ForceCommand entry; sshd handles authentication, ciphers, host keys, fail2ban, audit logs. You get a battle- tested SSH stack and a clean middleware programming model.
• No build step. Every library is pure PHP, installable via composer require, no native extensions required for the base flow. ext-pcntl, ext-gd, ext-ssh2 are optional for specific advanced features (signal handling, PNG → Sixel, outbound SSH from inside a session).
• Forty-one libraries, twenty apps, sixty-one Composer packages. Pull just what you need. The umbrella sugarcraft/sugarcraft metapackage brings the whole stack at once, but a tiny CLI that only wants colours can grab sugarcraft/sugar-style in isolation.

Try the quickstart →