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 CandyCore 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 CandyCore 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 CandyCore 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[".

vs. Go bubbletea

Genuinely the same architecture; SugarCraft is the deliberate PHP port of bubbletea + the Charm ecosystem on top of it. If you already write Go and your TUI lives next to a Go server, just use bubbletea — it's the reference implementation.

Pick bubbletea for: existing Go codebases, any project where binary distribution is part of the story.

Pick SugarCraft for: PHP-native shops, Composer- installable distribution, drop-in to existing Symfony / Laravel / Yii / WordPress tooling. The mental model carries over — blog posts and tutorials about bubbletea translate almost line- for-line, and CONVERSION.md has the per-feature mapping.

Architecture decisions worth noting

• Cursed cell-diff renderer (Bubble Tea v2's headline feature) is a first-class option in CandyCore 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.
• CandyWish leans on OpenSSH. Rather than re-implementing the SSH wire protocol, CandyWish 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).
• Sixteen libraries, sixteen Composer packages. Pull just what you need. The umbrella candycore/candycore metapackage brings the whole stack at once, but a tiny CLI that only wants colours can grab candycore/candy-sprinkles in isolation.

Try the quickstart →