That’s cool. I’ll look into that
Comment on Voiden - A Markdown based Open Source Alternative to Postman
chrash0@lemmy.world 14 hours ago
i’ve been looking for a silver bullet in this space. hurl[1] seems promising as well. i feel like Bruno has always been jank, and going 1.0 didn’t help. at work i’ve stuck to vibe coding my API test code with a stack of TOML configs, that way i get to reuse/test my client code as well.
what i want is something version controllable with lightweight dependencies that i can automate easily. i’m afraid that discounts this project. not going to ask my team to download Yet Another Electron API client UI. i’m hesitant to introduce hurl, which can at least be scripted.
1: hurl.dev
nikolasdimi@lemmy.world 11 hours ago
hey, nikolas here (part of the team of Voiden)- I am keen to understand more if you dont mind. Which of the preferences you mentioned discounts this project? the version control and lightweight?
I guess you are you referring to the tool being on Electron (Since the version control is handled through the native git integration)?
We used electron cause allows to deliver the same experience across Windows, macOS, and Linux, and makes it easier to iterate quickly in these early stages.
a few points:
Some apps do feel heavy because of how they are structured : monolithic cores, always-on cloud layers, or unnecessary background services. Voiden is (intentionally) built with a lightweight core: offline-first, Git-native, and without extra baggage.
Voiden uses a plugin architecture. This means that we have a small core and all the extra functionality is optional (users can enable or disable plugins) so the base app stays small while the ecosystem can grow. Community contributions or advanced features don’t inflate the core, they live in plugins that users opt into.
At the same time, there is no special tie to Electron :) We evaluated other options as well but we felt they didn’t offer the same support for all the features we wanted to deliver.
But we intentionally designed the plugin SDK to be framework-agnostic, leaving the door open to switch the core to a different framework in the future if it makes sense.The goal is a tool that stays lean, extensible, and adaptable as it evolves.
apologies for the long answer - hope it makes sense?
chrash0@lemmy.world 4 minutes ago
first, i’m biased. i’m a home row kind of guy. i live in the terminal.
i’ll be direct: light weight dependencies. i understand why you’d use Electron to build a UI, but does an API tester need a UI as a first class feature? i think something like
hurlshows it’s not necessary. i get that maybe it’s an accessibility problem (juniors and Java devs being afraid of the command line etc), but UIs are not composable. i could runhurl(orcurlfor that matter) via bash or nushell or Elisp or Rust or Powershell or JavaScript or GitHub Actions or as a k8s postDeploy… and, not to draw the ire of Lemmy armchair zealots, they’re not easily usable by agents. an 8B model on my Macbook could figure outhurl, no MCP or crazy preprompting required.plus: user adoption. this is the self hosted community, so maybe not everyone here has the same concern, but i can’t just commit a bunch of exotic files to my shared repositories. Bruno was a tough adoption, even though it seems obvious to version control this stuff and it was the only real option at the time. now i’m tired of Bruno cuz it goes out of date cuz it’s not easily scriptable with our internal auth services because it runs everything in its bespoke UI. if they haven’t made a button for it, you can’t do it. that’s the problem with UI dev tools.
no shade, i understand some people would be totally lost if their IDE didn’t have a big green run button.