Fizzy: a modular Zig editor shell for pixel art and plugins

Fizzy's modular editor model

Fizzy addresses editor extensibility rather than one narrowly defined editing task. Its core is described in the README as an empty modular editor shell that dynamically loads and unloads compiled plugins. Those plugins provide the capabilities exposed to the user. This makes Fizzy relevant to programmers who want to extend an editor, exercise a plugin SDK, or assemble several kinds of editing workflow in one interface.

The repository description calls Fizzy a pixel art editor made with Zig, but the README presents a broader architectural distinction. Pixel art is supplied by the separate pixi plugin. A fresh Fizzy installation includes only built-in plugins, so the base application is not documented as arriving with the complete pixi workflow. The core supports regular text and Markdown editing by default. Markdown is included so plugin README.md files can be rendered in the store, although the README says it can also be used generally.

The plugin store is part of the product rather than an external package catalogue. According to the README, plugins can be published there, and a store tab lets users browse and install them. This is Fizzy's clearest distinction from a conventional single-purpose pixel editor. The application supplies the shell, project-oriented layout, store, and plugin lifecycle, while separate repositories provide functional plugins. An adoption decision therefore has two parts: deciding whether the shell fits, then deciding whether its available plugins cover the required work.

Plugin loading and workspace structure

Fizzy's central mechanism is dynamic loading and unloading of compiled plugins. The README does not publish the module-loading code path, plugin ABI details, or a configuration file for selecting plugins, so those specifics cannot be confirmed. What can be established is that functionality is packaged as plugins rather than permanently folded into every installation.

The interface is driven by DVUI, and the general layout draws on the familiar folder-based organization used by VSCode and other IDEs. This points to a workspace model rather than a single-document dialog, although the README does not document the exact persistence format or project metadata. The store also needs Markdown rendering to display each plugin's README.md file, which ties documentation presentation to the store's plugin discovery and installation flow.

Several first-party plugins demonstrate different capability types. The pixi plugin provides a grid for pixel art, animation frames, Lospec palettes, and sprite atlas packing. The Zig plugin provides syntax highlighting and ZLS features, including hover, goto definition, and signature help when a compatible ZLS executable is available in PATH. The README also identifies the built-in text plugin as the companion for the Zig plugin. The ghostty plugin uses ghostty_vt to add a cross-platform terminal in a bottom panel.

These examples show that Fizzy plugins can add complete editing surfaces, language services, or narrow interface panels. They are not all equivalent in workflow. In particular, the README says pixi uses its own workflow and draws its cursors through its atlas. That separation is an adoption constraint for teams expecting every plugin to behave like a standard document tab.

Building Fizzy from source with Zig 0.16.0

The README's native compilation instructions target Linux and name `gtk+3-devel` or a similar package for native file dialogs. It then requires Zig 0.16.0, followed by a clone and build command. The documented commands are:

git clone https://github.com/fizzyedit/fizzy.git

This creates a local checkout under the current directory. The README does not specify the expected terminal output or a release binary path.

cd fizzy

This moves into the cloned repository so the Zig build commands run from its root.

zig build run

This invokes the repository's build definition and runs the resulting application through Zig. The repository contains `build.zig`, `build.zig.zon`, and separate source areas including `app/`, `core/`, `plugins/`, `sdk/`, and `web/`, but the README does not publish individual targets beyond this run command. The documentation also does not describe Windows or macOS native build steps. A browser edition is available through the website, but no local command for producing that web build is provided.

The strict Zig version is worth noticing. A machine with an older or newer installed Zig should not be assumed to work, because the project documentation specifically requests 0.16.0. Linux builders must also account for the GTK development dependency when native file dialogs are required.

Starting with pixi in the Fizzy store

The shortest documented route to trying Fizzy is its browser edition at `https://fizzyed.it/app/`. The README also links downloads from `https://fizzyed.it`. For a pixel art workflow, a new installation still needs the pixi plugin, because the default installation includes only built-in plugins.

The README states that a store tab can browse and install plugins. It does not provide a button-by-button procedure, plugin identifier, version constraint, or screenshot for that flow, so the confirmed first-use sequence is limited but clear: open Fizzy, locate the store tab, find pixi, install it, and then use the plugin's pixel art features. The store renders each plugin's README.md file, giving users access to plugin documentation at the point where plugins are discovered.

Once installed, pixi supplies the grid-based canvas, animation frames, Lospec palette support, and sprite atlas packing described in the README. Its own workflow and atlas-based cursors mean that users should evaluate it as a distinct editing mode inside Fizzy. The documentation does not state whether plugin installation requires a restart, whether pixi can be removed through the same store, or how failed plugin installation is reported.

For non-pixel work, the built-in text plugin is immediately relevant. Installing the separate Zig plugin adds language behavior and can connect to compatible ZLS functionality if ZLS is already available in PATH. That dependency boundary is important: Fizzy can host language tooling, but it does not automatically remove the requirement for a compatible ZLS installation.

GPL-3.0 and compiled plugin boundaries

Fizzy is released under MIT. That licence matters to developers considering integration, redistribution, or derivative work. This review does not provide legal advice, and the repository licence file should govern the exact obligations for a particular distribution model.

The project also separates its core from plugin repositories such as pixi, zig, and ghostty. The README identifies MIT for Fizzy itself, but it does not state the licences of every listed plugin. Engineers should therefore check each plugin repository before assuming that one licence covers every downloadable component.

The architecture can lower the cost of replacing a capability because functionality is loaded as plugins. It can also complicate distribution because the application, store, plugin build process, and each plugin artifact must be evaluated separately. The README confirms compiled plugin loading and a store, but it does not document plugin signing, checksum verification, sandbox permissions, or what access a plugin receives. Security-sensitive deployments should not infer isolation guarantees from the word “modular.”

For game developers, pixi's grid, frames, palettes, and atlas packing are directly relevant. However, Fizzy itself is not documented as a complete sprite production suite. Its value comes from combining pixi with a custom editor shell, not from replacing every specialized art tool in one install.

Maintenance signals and adoption constraints

The repository is not archived, and its last push was on 2026-10-16. The three most recent listed releases are Fizzy SDK releases: `sdk-v0.2.27` on 2026-10-15, `sdk-v0.2.26` on 2026-10-14, and `sdk-v0.2.25` on 2026-10-14. These dates indicate recent repository and SDK activity, but the README does not define a release cadence or promise of long-term compatibility.

The README uses the term “open-source modular general editor,” while the repository description emphasizes pixel art. This mismatch matters for procurement and product planning. Teams looking only for a dedicated pixel art application should inspect pixi directly. Teams interested in the SDK, compiled plugins, the store, or a common interface should evaluate the Fizzy repository. The most recent release names concern the SDK, so they should not be read as evidence of a stable application release train.

Fizzy is not the right tool when a single, predictable editing window is more important than extensibility, when every feature must be included in the base installation, or when native Windows and macOS build instructions are a prerequisite. The missing documentation for those platforms, plugin ABI, rollback, sandboxing, and plugin-specific compatibility makes adoption require direct source and plugin inspection. Its clearest use is as an extensible editor foundation for a developer willing to work with a Zig-based plugin ecosystem.

Editorial conclusion

Fizzy fits developers who want to assemble an extensible, cross-platform editor around compiled Zig plugins and are comfortable with early-stage tooling. It is a poor fit for users who need a standalone pixel art editor with an immediately fixed feature set or for teams that cannot accept MIT obligations. Before adoption, verify that Zig 0.16.0 fits the build environment, confirm the desired plugins are available in the store, and test the browser or native workflow on the target operating system.

Frequently asked questions

Official sources

1. fizzyedit/fizzy on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases