voiden

ge we care about (even added it in the app itself for people to check it out). But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes: “yeah but Tauri would use way less” And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :) Of course Electron also has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so… At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare: full Electron process footprint VS the smallest possible Tauri/native mental model …without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron. So all this context to get to my real question, which is: How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron? And also, for those of you who have had this conversation a hundred times already: What do you say when people reduce the whole discussion to “Electron bad, Tauri good”? Have you found a good way to explain footprint in practical terms? Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild. Would love your thoughts and advice,

n environment that doesn't take advantage of powerful runtimes that might be available locally for a developer. The biggest limitation here is the assumption that the tool should define the runtime. Voiden runs fully locally, so this allows you to just run your scripts with actual runtimes (JS, Python, shell, with support for others being added). - Multiple requests per file (mini workflows): Allowing multiple requests in a single .void file turned out to be surprisingly useful. Instead of scattering related requests, you can group them naturally: an order flow (create - pay - confirm), or a full CRUD cycle in one place. The file effectively becomes an executable flow: run one request, or the entire sequence end-to-end. And since Voiden is executable Markdown, docs and tests are in the same `.void` file that can be organised better, preventing duplication and drift. - Stitch (composable workflows across files): Instead of a single large collection, workflows (“Stitch”) are built from .void files that you can combine across scenarios. You define small flows (auth, setup, CRUD, etc.) and stitch them together into larger workflows, without duplication. This is just the first version of this capability, we still have a lot to do here. - Agents :The file-based, local-first model also works well with agents. Since Voiden has a built-in terminal and uses Markdown, we added “skills” so that Claude and Codex agents can work directly with .void files (using your own subscriptions). We also published an SDK for community plugins, and made improvements to performance, reliability, and DX (keyboard-first), with careful attention to performance given the Electron base Looking for feedback and suggestions. Github : https://github.com/VoidenHQ/voiden Download : https://voiden.md/download

ms when they all start with great intentions is because their entire business identity is tied to being “the API tool.” Be it postman, insomnia (perplexes me even more why kong has to push it so hard), even bruno to some extent is forced to find a viable monetization strategy. In any case, all this creates strong pressure to monetize aggressively. When survival depends on one product, paywalls, feature gating, and pricing complexity become almost inevitable, even with good intentions. Part of why we built Voiden differently (https://github.com/VoidenHQ/voiden) is that it started as an internal tool. We used it ourselves for nearly two years, shared it with few teams to get feedback and incorporated it, before open-sourcing it. We also run an established API marketplace, which is our actual business. So Voiden isn’t something we’re trying to turn into a product line. The intent from the start has been to treat it as long-term community infrastructure — closer in spirit to tools like VS Code or Backstage — open, free, and evolving in the open. Interestingly, much of what the article describes as the “ideal API tool” maps closely to how Voiden ended up being designed. That’s largely because we never tried to build “a better Postman” or “an open Insomnia.” We wanted to rethink API tooling from the ground up: markdown-based workflows, reusable blocks, versioned artifacts, and workflows that work well for both humans and AI agents. No need for Postman's Postbot or whatever AI solution the tools are locking the users into - use the integrated terminal in Voiden to use claude or any other agent of user's choice. Maybe I’m going out on a limb, but I think this style of tooling will become the norm over the next few years, or at least push the category to evolve. AI is changing how fast we can build. It’s not changing what ultimately matters: trust, usability, sustainability, and developer experience. Teams will keep using tools that respect those fundamentals, and walk away from ones that don’t. And to be clear, I’m not sharing this to promote Voiden. The broader point is that we need more genuinely novel approaches to modern API challenges. Voiden is just our take on that problem. Other teams will arrive at different answers, and that’s healthy and I want people to be bold enough to shed the legacy tooling's "hangover".