This document outlines the alternatives considered and the justification for the final technical stack.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| Electron | Fast dev cycle, massive ecosystem, easy hiring. | Bloat: 100MB+ footprint, high RAM usage (Chromium). | Rejected |
| Native (Swift/Kotlin) | Best performance, OS-specific features (Menu bar). | Fragmentation: 3x development effort for cross-platform parity. | Rejected |
| Tauri | Tiny binaries (~10MB), Rust performance, native webview. | Newer ecosystem, requires Rust expertise. | Selected |
Justification: For a "Toolbox" that developers keep running in the background 24/7, Electron is a non-starter due to memory bloat. Tauri provides the "Native-lite" experience with a single codebase and Rust's safety.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| Hand-rolled | Minimal binary size, zero dependencies. | Extremely high effort to implement Parquet/CSV/JSON correctly. | Rejected |
| Polars | Industrial Grade: Extreme speed, multi-threaded, handles Parquet natively. | Large crate size, increases compile times. | Selected |
Justification: For the Parquet Suite, correctness and performance are non-negotiable. Polars is the fastest DataFrame library in the ecosystem and allows us to support massive datasets with minimal code.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| ESLint + Prettier | Industry standard, millions of plugins. | Slower execution, complex configuration (many .js files). |
Rejected |
| Biome | Fast: Written in Rust, single binary, unified linting/formatting. | Newer ecosystem, fewer community rules. | Selected |
Justification: Omnitool aims for "Native Speed." Using Biome ensures that our development workflow remains as fast as our application runtime. It fits the project's Rust-centric philosophy.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| Svelte | Tiny bundle, no Virtual DOM, high performance. | Smaller ecosystem for specialized dev-components. | Rejected |
| React | Rich Ecosystem: Radix UI, Framer Motion, Monaco. | Larger bundle size, Virtual DOM overhead. | Selected |
Justification: The React ecosystem has mature, high-performance components for layout and animation (Framer Motion) and accessible primitives (Radix) that allow us to build a premium UI faster than hand-rolling in Svelte.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| Built-in (Llama.cpp) | Seamless "out of the box" experience. | Massive binary size (+500MB), high maintenance. | Rejected |
| Agnostic (Ollama) | App remains tiny, leverages existing user setup. | Requires user to install Ollama separately. | Selected |
Justification: We do not want to become an AI company. We want to be the UI for the local AI ecosystem. By connecting to Ollama, we keep the app size under 50MB while providing full AI power.
- Binary Size: As we add heavy crates like Polars and future JS runtimes, we must use LTO and feature-stripping to keep the installer under 50MB.
- Platform Parity: Using native webviews means subtle rendering differences between macOS (WebKit) and Windows (WebView2).
- Mitigation: Standardized CSS variable system and cross-platform CI testing.