Forem: Nikolas Dimitroulakis

Cross-Platform Desktop Wars: Electron vs Tauri: How do you explain the tradeoffs to users?

Nikolas Dimitroulakis — Wed, 25 Mar 2026 14:59:25 +0000

Hello,

I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).

Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.

this is the tool:

https://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 this:

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 :)

And of course, I get it. The broader footprint is real. Chromium is not free. Electron 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?

Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?

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!

Burgers, APIs, and the State of Developer Marketing

Nikolas Dimitroulakis — Fri, 13 Mar 2026 13:43:13 +0000

Wanted to share some thoughts as a founder who has been building and shipping developer tools and applications (including open source, Voiden).

When I started, every discussion and engagement I had with dev-tool marketers and experts revolved around the idea that effective developer marketing should be a combination of genuinely helpful content, engaging tutorials, thoughtful blog posts, and insightful guides that actually help people get unblocked or see common problems from a new perspective.

I wanted to — and still want to — contribute to that kind of ecosystem.

And to be clear, I still believe this is what good developer marketing looks like.

But I also realized that a lot of what passes for “dev marketing” today (especially in the API tooling space that I’m in) is much more about SEO, keyword stuffing, backlinks, and thinly veiled sponsored content.

Case in point:

I came across a post on dev.to titled:

“12 open-source alternatives to popular dev tools.”

Great idea, right?

Except the first tool listed wasn’t open source at all — it’s a paid SaaS.

Some of the “alternatives” weren’t even truly comparable. It felt much more like keyword stuffing and backlinking than a genuine resource meant to help developers.

And some of the comments below were things like:

“Great list!”

So I made a joke in the comments calling out the issue. Something along the lines of:

“You could also add the tool to a list of ‘Top burger joints in Manhattan’, since people could also test APIs while eating a burger, right?” or something like that.

In hindsight, maybe not the best joke ever made.

The author of the post apparently thought the same and deleted my comment.

Twice.

But this isn’t really about that one tool or that one post.

I have seen many companies do similar things.

That said, I also don’t want to overgeneralize and in a weird way I can even sympathize a bit.

A lot of founders and makers fall into a strange trap: the idea that self-promotion is inherently bad.

So instead of honestly sharing what they’ve built or what they’ve learned, they look for clever tactics or “growth hacks” to appear neutral, helpful, or educational while still getting attention.

In a way, they’re staging the play they think developers want to see.

It’s understandable (maybe).

But it can easily cross the line into something misleading or manipulative.

I honestly don’t know whether this happens because people underestimate developers’ ability to see through it, or because the SEO benefits eventually pay off anyway.

Maybe both.

From my experience, developers are skeptical and notoriously allergic to being marketed to. And when marketing stretches the truth this far, it can slowly erode trust — not just in one tool, but in the ecosystem as a whole.

The lesson I’m taking away as a founder:

Authentic engagement wins.

Build tools that solve real problems.
Share honest insights.
Be simple and transparent about what you are doing.

A little vulnerability goes a long way.

Anyway, enough whining.

Let’s make it fun:

What’s the most absurd developer marketing you’ve seen lately that made you roll your eyes?

Voiden is now extensible via community plugins

Nikolas Dimitroulakis — Tue, 10 Mar 2026 21:07:09 +0000

A lot of developer tools follow the same pattern: They start simple and then new ideas come. Then these these new ideas become built-in features.

This is of course fine (and natural) but over time, the core can become huge, harder to maintain and evolve, and slower to experiment with.

When we started building Voiden we wanted to avoid this trap.

What we observed from our experience and also while talking to other developers is that different teams use API tools very differently, in different scenarios.

So we decided that forcing everyone into the same giant feature set doesn’t really make sense.

So, instead of putting everything in the core, we decided to have the tool grow through a plugin system. This way, it can be flexible and extensible since new functionality can live outside of the core tool.

The idea is simple:

Keep the core lean. Let the ecosystem grow around it. Developers can build extensions independently and users can just install the pieces they actually need.

Keeping Voiden flexible and extensible is one of the key design principles we had from day one and I am very happy with this milestone.

Curious what kinds of extensions people will build 🙂 (we already have a few community plugins in the works)...

Start contributing: https://docs.voiden.md/docs/plugins/build-a-plugin
Repo here: https://github.com/VoidenHQ/voiden

API security and compliance in 2026

Nikolas Dimitroulakis — Fri, 06 Mar 2026 10:22:05 +0000

Choosing an API based on functionality is one thing. Getting it approved for production is where things can get tricky.

The moment your product sends data to a third-party service, questions come up:

→ Where is the data stored?
→ How long is it retained?
→ Are third-party processors involved?
→ Is it compliant with GDPR, SOC 2, or other standards?

This is often the step that slows down adoption more than the integration itself.

At ApyHub, we tackle this head-on.

Every API in our catalog comes with clear, standardized info on data handling and compliance. That means teams can:

→ See certifications and disclosures upfront (GDPR, SOC 2, ISO 27001)
→ Understand exactly where and how data is stored and handled
→Track retention and third-party processing
→ Stay up-to-date as APIs evolve

The result? Teams can find, evaluate and approve APIs faster, with confidence, without digging through scattered docs or privacy policies.

We are happy as our catalog keeps growing with new APIs. But in the end, it’s not just about functionality.

It’s about trust, compliance, and true data sovereignty.

Explore certified APIs here: https://apyhub.com/catalog

Scripting in API tools?

Nikolas Dimitroulakis — Tue, 24 Feb 2026 17:43:38 +0000

Spent months thinking about scripting in API tools.

Honestly, most tools don’t go far enough. They stop at JavaScript, a limited sandbox and a system that is not really extensible.

That works for small tests, but it can also quickly break down when you want to start building real, multi-step workflows.

We wanted to go further. So we spent time observing how developers actually work with APIs, talking to them, and learning from the patterns and frustrations in real workflows. We saw token rotations handled manually, small helper scripts scattered across repos, and tools that forced engineers into JavaScript even when their stack was Python, Go etc.

So for Voiden Pre & Post Request Scripts adapt to how developers work.

JavaScript + Python (first-class): use the language you already know and trust
Real runtimes & package imports: run actual code, import libraries, reuse existing logic
Stateful workflows: share variables, store data, and chain requests dynamically
Orchestration-ready: automate multi-step flows, token rotations, and dependent API calls

Again, it's a basic principle we had from day 1: API tools should not dictate how devs think. It should adapt to how they work.

We believe this is one of the most powerful scripting systems available in any API client today.

And we are just getting started.

🌐 Beta: https://voiden.md/download#beta
📂 GitHub: https://github.com/VoidenHQ/voiden

Assertions vs pre and post scripts

Nikolas Dimitroulakis — Tue, 24 Feb 2026 17:39:06 +0000

Simple Assertions vs Pre & Post Requests

Many developers already use Assertions in Voiden to validate responses—checking status codes, verifying fields, or ensuring data formats.

They are great for simple validation and quick checks after a request.

But what if your workflow needs more than validation? That’s where Pre & Post Request Scripts come in.

Pre-request scripts run before the request: generate tokens, set dynamic headers, compute values, inject variables, or prepare data on the fly.

Post-request scripts run after the response: validate responses, extract values, store variables, trigger follow-up logic, or chain multiple requests together.

When to use Assertions: simple checks and validations, fast feedback, lightweight workflows.

When to use Pre & Post Scripts: dynamic APIs, token rotation, multi-step flows, automated chaining, or when your workflow requires more complex logic.

Use assertions for quick checks and scripts for dynamic, automated workflows.

Voiden now supports JavaScript and Python for Pre & Post Request Scripts (available in the beta, link below).

Question for the community: Which other languages would you like to see supported in Voiden?

Your feedback could shape the next updates!

🌐 Beta: https://voiden.md/download#beta
📂 GitHub: https://github.com/VoidenHQ/voiden

Most API tools treat requests as monolithic blocks - Voiden doesn't

Nikolas Dimitroulakis — Mon, 16 Feb 2026 09:57:50 +0000

On the one side you have legacy tools: API tools like Postman, Insomnia etc that are built as platforms first: Accounts, workspaces, cloud sync, dashboards, paywalls. Actual API work often comes second.

On the other side, we now have a bunch of API tools that are vibe coded. Built, shipped and posted on Twitter the same day. Yes, they look sharp, but under the surface they are often thin abstractions over fetch calls. With no clear model or long-term thinking about workflows, versioning, or how teams evolve their API usage over time.

Somewhere in between, there is Voiden. Voiden is a result of years of synthesizing thoughts and feedback from real developers : backend engineers, platform teams, API designers. We watched how they actually work. Where workflows break. Where collections rot and collaboration becomes painful.

So we designed it, we showed it, we improved it and then improved it a bit more. And now we open sourced it.

Voiden is an offline-first, Git-native API tool where requests, specs, tests, and docs live together as executable Markdown inside your repository.

Voiden introduces a live Markdown + API runner workflow. API requests, reusable blocks, and human explanations live in the same Markdown file - and can be executed in place. No request builder UI. No context switching.

The best thing is, while other tools treat a request as a single opaque object, Voiden does something completely different (and unique) - no other API client does this.

Voiden breaks a request into composable blocks: endpoint, headers, query, JSON, auth etc.In most tools, headers and auth live inside individual requests, so if you need them elsewhere, you duplicate them. When something changes, you update every copy manually.

In Voiden, blocks behave like functions: define them once, reference them across requests, and when the block changes, every request using it stays in sync.

Voiden is intentionally lightweight and extensible. We wanted the core to stay lean, and everything else to live in a plugin system: gRPC, GraphQL, WebSockets (WSS), assertion blocks, etc and more coming.

That means the tool can grow in capability without growing in bloat. Everyone can select which plugins to have and the community can extend it just as easily as we can.

Voiden works around your workflow, your way, rather than make you adapt your processes around the tool.

If you don't want to deal with bloated API tooling and saas looking clients, Voiden is the tool you want to try.

Github : https://github.com/VoidenHQ/voiden

How to switch from Postman to Voiden : https://voiden.md/blog/migrate-postman-collections-to-voiden

which API tool is this?

Nikolas Dimitroulakis — Tue, 10 Feb 2026 07:14:51 +0000

Postman announced that their Free plan for teams is going away.

Nikolas Dimitroulakis — Thu, 05 Feb 2026 11:14:53 +0000

Postman announced that their Free plan for teams is going away.

Free now means one person. Collaboration is a paid upgrade.
This is not really a surprise. It’s the SaaS playbook.

That’s exactly the problem we didn’t want to recreate when we built Voiden.

Voiden doesn’t have “Teams” cause Git already solved it years ago.

Your team structure already exists.
Your review process already exists.
Your version history already exists.

So instead of inventing roles, dashboards, and pricing tiers, Voiden:

keeps API specs as Markdown in your repo
uses commits and PRs for collaboration
works fully offline
never locks a teammate out because of a license

APIs belong with the code. Collaboration belongs in Git. Everything else is overhead, and usually a paywall.

And yes, we have now open sourced Voiden.
https://github.com/VoidenHQ/voiden

Open-sourcing Voiden: An API Tool Built for Developers, Not SaaS

Nikolas Dimitroulakis — Wed, 28 Jan 2026 08:57:49 +0000

Open-sourcing a project is usually "business as usual." Many companies do it, and it’s healthy, expected even. But for us, open-sourcing Voiden feels different, like finally paying off a long-overdue debt to the community that shaped my career.

Why Voiden Exists:

API tooling has slowly drifted away from being just tools. They turned into cloud platforms with forced logins, proprietary formats, per-seat pricing, and workflows that break the moment you lose internet access.

For many developers, this is frustrating:

Testing a localhost API shouldn’t require an internet connection.
Specs, tests, and docs shouldn’t live in three different tools.
API workflows shouldn’t feel fragile or over-engineered.

We wanted something different. Something that respects how developers actually work.

What Makes Voiden Different?

Voiden started as a reset — a tool built for the developer’s headspace, not a SaaS dashboard.

Here are the core ideas:

Offline-first: Your API requests live locally, no cloud required.
No accounts, no telemetry: Your work is yours.
Git as the source of truth: Everything is stored as plain text files in your repo.
APIs as reusable blocks: Build, test, and link requests like code.
Specs, tests, and docs together: No bouncing between different tools.
Designed to stay out of your way: Fast, local, beautifully nerdy, and just opinionated enough.

Voiden is your personal API lab: local, fast, and developer-owned.

What Open Source Means to Us:

Opening up Voiden is not just about sharing code. It’s about:
Letting the vision exist without explanation — trusting developers to judge it on its own merit.

Shifting from isolation to collaboration — handing over the tool to a community that can make it better.

Voiden isn’t perfect. It’s deliberate and very much alive. And now, it’s yours to help grow.

What’s Next?

If you work with APIs and value calm, local-first, developer-owned workflows — give Voiden a try.

Your feedback, ideas, and contributions can shape where it goes next.

Check out the repo here: https://github.com/VoidenHQ/voiden
and let’s rethink API tooling together.

Open source is a conversation, not a monologue :)

Let’s see what happens.

cheers,

Nikolas from the Voiden team

Landmark detection using an API

Nikolas Dimitroulakis — Mon, 19 Jan 2026 11:58:46 +0000

Your app sees the image. Does it know the place?

Teams building with user uploaded photos hit this fast. Travel apps, social tools, content platforms. Everyone wants to auto tag locations, group images, or unlock smarter search based on where a photo was taken.

The usual approaches:
📍 Ask users to tag locations
📍 Rely on GPS data that is often missing
📍 Build custom vision logic that takes time and still breaks

Then the pain shows up.
What tends to go wrong:

⚠️ Users skip tagging
⚠️ Images lose metadata after edits or screenshots
⚠️ Vision pipelines turn into long term maintenance work
Landmark detection solves this quietly.

ApyHub AI Image Landmark Detection API takes an image and returns recognized landmarks like monuments, buildings, or natural places. One API call. No manual input.
Why this is useful in real products

✨ Easy to plug in without owning a vision stack
✨ Enables auto tagging, smarter feeds, and location aware features
If images matter in your product, this is a solid building block.

Try the API from the link and test it on a random photo : https://apyhub.com/utility/ai-image-detect-landmark

Comment if it confidently identifies a place you absolutely did not expect 😄

Open Source Question

Nikolas Dimitroulakis — Thu, 15 Jan 2026 09:00:07 +0000

Planning to open source Voiden (https://voiden.md/) soon.

This isn’t a “maybe someday” idea anymore, it’s a deliberate step we want to take in the coming weeks.

We started Voiden as a tool we wanted for ourselves: a minimal, offline-first API client that works with plain text, no accounts, no cloud sync, no SaaS gravity. Just something that respects how developers already work.

Open sourcing feels like the right next move, but I’ll be honest: it also raises a lot of questions for us.

We have talked to many devs who strongly believe tools like this should be open. At the same time, we are thinking carefully about:

how to structure the repo and contributions

how to balance direction vs community input

what we wish we had known before flipping the switch

etc etc.

So I wanted to open this up and ask directly:

If you have open sourced a project (especially a dev tool):

What do you wish you had done differently at the start?

What mistakes are common but avoidable?

Anything you underestimated, emotionally, technically, or community-wise?

Any advice you’d give before making it public?

I want to stay committed to doing this thoughtfully, not performativel, so learning from people who have been through it already would help a lot.

Appreciate any hard-earned lessons you are willing to share 🙏