HN user
developer productivity, card tricks, basketball, chess.
I am working on a few things:
Voiden: Released the Voiden Runner so that users can test APIs directly in the terminal. https://github.com/VoidenHQ/voiden
ApyHub: https://apyhub.com/ working to onboard a few more API providers. Working to rationalize the terms for new APIs added in the catalog.
I am also working to streamline how all APIs are certified and monitored.
I am working on making working with APIs simple and modular: https://github.com/VoidenHQ/voiden
Hello,
Wanted to get some opinions from folks here that have actually built and shipped with Electron.
Background: Building an API IDE on Electron. Designing this to not be “just an API client”or a thin wrapper around a webapp. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior: local workflows, richer interactions, and some things that I think would have been much harder to build and maintain in a more constrained setup. So yeah, thats why we went for Electron.
this is the tool: github.com/voidenhq/voiden :)
Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.
The (slightly) frustrating part is that when the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage 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,
built and open sourced a postman alternative, and decided to do it on Electron.
what has been funny is indeed when having to "defend" electron when it comes to memory footprint etc.
One thing that I always thought was interesting is that people make the argument by comparing the full Electron process footprint VS the smallest possible Tauri/native mental model and all without thinking about all the advantages of electron like development speed, cross platform consistency etc.
we have now optimized it a lot and we even show the actual usage inside the app for folks to monitor.
here is the repo in case you wanna have a look: https://github.com/VoidenHQ/voiden
with my team we built Voiden for some of these reasons, initially for our own internal use (building many APIs for our SaaS marketplace). Most of the folks in the team have been postman power users before so we do remember the time when this was indeed something new.
Problem now is that most of the alternatives out there (including the ones you mentioned) do offer some great things but essentially they feel variations of the same concepts - so I see them as "Enshittification on the way". Reason we built voiden is that we wanted something that challenges these ideas. You can try it out and let me know if it resonates: https://github.com/VoidenHQ/voiden.
apologies for the slight promo - but based on your comment I thought it might be relevant.
changelog here for anyone who wants to check what was released in the last couple of months.
postman is great for complex stuff - what kind of complex stuff?
https://github.com/VoidenHQ/voiden
Today I released the community plugins for Voiden.
This is a big one because one of the things I dont want is the API tool to become bloated with new features - so I want to allow anyone to build plugins to grow the tool.
must be the groundhog day...but yeah, this is happening a lot.
Not sure if “code has always been expensive” is the right framing.
Typing out a few hundred lines of code was never the real bottleneck. What was expensive was everything around it: making it correct, making it maintainable (often underestimated), coordinating across teams and supporting it long term.
You can also overshoot: Testing every possible path, validating across every platform, or routing every change through layers of organizational approval can multiply costs quickly. At some point, process (not code) becomes the dominant expense.
What LLMs clearly reduce is the short-term cost of producing working code. That part is dramatically cheaper.
The long-term effect is less clear. If we generate more code, faster, does that reduce cost or just increase the surface area we need to maintain, test, secure, and reason about later?
Historically, most of software’s cost has lived in maintenance and coordination, not in keystrokes. It will take real longitudinal data to see whether LLMs meaningfully change that, or just shift where the cost shows up.
Indeed, its quite obvious it is written by an employee. I was not aware of the term though, thanks :)
one of the creators here - you are right in the sense that most tools start open source and then they close source. For us it was different/ the opposite. We first made it as a product and then we open sourced it. It was never our intention to make it a SaaS though nor charge for it.
well void is also the blank slate in the sense that Voiden is a tool without rules - without explicit directions to the users on how they should do xyz. So yeah, our inspiration comes from an empty sheet, a blank slate to work with APIs. And if there are no restrictions then there are infinite opportunities. :) thts how it makes sense to us.
:)
thanks for the points- on the product comment: in what way you think it doesn't fit? genuinely interested.
true
cool!
for me chatgpt has completely replaced google.
Hi all, I am Nikolas, co-founder of ApyHub.
At ApyHub we currently host 110+ APIs (that are available for our users to consume) + we operate hundreds of internal APIs that power the platform. With all these APIs we had/need to be super careful and diligent about API management.
We soon found out (the hard way) that the de facto API clients (even the newer, supposedly “modern” ones) did not make our lives much easier when it came to building and Testing APIs (not to mention collaboration).
So we decided to do something about it and (long story short), Fusion is the result: We like to call it the Notion-like API Client because it follows Notion’s philosophy of modularity, collaboration and extensibility.
Some points that I think are worth mentioning:
Modularity: Fusion is built with modularity from the ground up - API requests are composed of blocks - like headers, query, body, post request tests etc. Just to give some reference, in postman and other clients these are all part of ONE request. Here you can create it as part of one request and reuse them (link or clone these blocks) in other requests. It is a new way to build APIs with reusability and efficiency in mind. You can link request blocks from other API requests and override them etc. You can have a quick look here: https://assets.apyhub.com/home/test-with-fusion.mp4
Collaboration: In most API Clients I have seen collaboration is mainly around documentation and working on API collections - users cannot easily discuss and ideate around APIs. So you end up using these API clients for testing and using other tools to collaborate with your team ( slack, Jira etc.). With Fusion, you can collaborate with your team while you are testing the APIs, or documenting them or even designing them.
Fusion AI: Right now can help generate documentation from just an API request / specs, improve existing documentation and also identify when your APIs start behaving differently than what is documented. Besides that, Fusion AI allows you to create client stubs as well as generate openapi specs from an API request. We will continue to explore more use cases where AI can reduce manual efforts, increase efficiency etc.
We intend to integrate Fusion into the entire Software Development lifecycle - start from project management tools, git repos, CI/CD, and monitoring as well to make it seamless to use it from everywhere.
Fusion also supports a self hosted mode besides the cloud offering, in case organizations / teams want to ensure that data ownership is critical for them.
We welcome you to try out Fusion. We have a free tier + the ability to start a free trial.
Interactive demo: https://app.arcade.software/share/sixDw5lhT9bp0m6J0Wwr
Cheers, Nikolas
It's disheartening to hear :) It also proves that people who predicted this for the metaverse were right. I thought i was the only one not getting it because i am old :)
Mark Zuckerberg, Meta’s chief executive, has declared that 2023 will be the “year of efficiency” at his company. So far, efficiency has translated into mass layoffs.
This is the link to the discord server for anyone who wants to join our community: https://discord.com/invite/JZagJJcw6F
yes, i learned how to run a half marathon Why? cause i quit smoking and i ended up having some extra free time. determination, came in handy