DEV Community: Mo

I was wrong about Electron

Mo — Fri, 29 May 2026 11:31:40 +0000

When I started building Paseo, I picked Tauri.

The reasoning felt obvious at the time. I was building a desktop app with a web UI, and I cared about shipping something that did not feel bloated. Like a lot of developers, I had also internalized the idea that Electron was the bad option.

Tauri had all the right stuff: Rust, small binaries, native webviews, lower memory usage. It felt like the better choice.

I also kept seeing "Built with Tauri" on product landing pages, and I think that influenced me more than I realized. It made Tauri feel like what the cool kids were using.

I thought I knew better than all those other Electron apps. At first, it felt like I was right. On macOS, the app was small, the UI worked well, and the bundle size made me feel good about myself.

Getting the app working on Windows was not a problem. Tauri uses WebView2 there, which is Chromium-based, so the app behaved close enough to what I expected. There were platform quirks to deal with, but nothing specific to Tauri.

Linux is where things started getting complicated.

Tauri does not bundle one browser engine across platforms. That is the point. On Linux, it relies on WebKitGTK, which sounds elegant until you are debugging rendering behavior across distros, GPU setups, and Wayland/X11 differences.

For Paseo, this turned into a lot of product work I did not want to be doing. The WebKitGTK bindings Tauri was using were too old. Wayland had problems. And once I got the app running, it just looked different. It was not just small stuff like font weights or aliasing, some screens had real layout differences.

I could maybe have lived with all of this, but then I started implementing notifications.

For Paseo, notifications are not a nice to have. If an agent finishes, fails, or needs attention, I want the user to click the notification and land in the right place.

Tauri's notification plugin can show notifications, but desktop click handling was not there in the way I needed. There's something called the Actions API that allows you to attach callbacks to notifications, but the docs mark it as mobile-only, which was strange.

This made me notice that Tauri was expanding into mobile apps, it was hard not to feel some doubt. I was still fighting basic desktop product issues while the framework was moving into something else entirely.

I tried a bunch of Rust crates, but none of them worked the way I wanted, so I ended up having to write the notification handling per platform. It was not straightforward, and now I had to maintain it.

There was also the daemon. This part is not really Tauri's fault, but it pushed me further toward Electron.

Paseo has a Node.js daemon, and I wanted a one-click experience. Download the app, open it, and go. I did not want to tell users "go run this command first" or teach them what a "daemon" was.

Tauri supports sidecars, so I got the daemon bundled and it worked. But it became its own project: different binaries for different platforms and target triples, packaging details, permissions, process spawning, paths, upgrades.

At some point I had the realization that I was building Electron with extra steps.

So I decided to try Electron. The migration was a bit of a pain, but I got things working surprisingly fast, and after a week of solid work Paseo actually felt lighter and simpler. The UI looked the same across platforms. Notifications behaved the way I needed. The daemon was simpler since it had Node pre-bundled.

Overall, I have been really happy with Electron since. It mostly gets out of my way. And when there are performance problems, they tend to come from my application code rather than Electron itself. I guess that is also why Electron gets a bad reputation, it is really easy to make a bloated Electron app.

My conclusion here is not that Tauri is bad. It was just the wrong choice for Paseo, and I made that choice more by vibes than by looking at the tradeoffs objectively.

Lessons Learned from Building Businesses as a Technical Solo Founder

Mo — Thu, 30 Dec 2021 07:58:27 +0000

I've been working on my SaaS projects all by myself over the last four years, and I've had some failures and some success, here are some of the lessons that I've learned!

Although it may look easy from the outside, doing all the development, marketing, customer service and everything else required to run a business takes a lot of time and effort, but it's not impossible. There are countless examples of highly successful businesses operated by a one-person team.

Some examples that I know of are:

As far as I know, they're all run by a single person doing all the things, including the development of the product. They're all very open about how they go about things and their blogs are a great source of inspiration!

Tame your inner perfectionist

You have to let go of your ego and allow yourself to ship something that might embarrass you.

Don't get me wrong, I am not talking about shipping a half-assed product or something that doesn't work . The hustle MVP mentality of building something functional in a weekend, and releasing it to see if anyone is desperate enough to buy your product is not sustainable either, there's a middle ground where you can be proud of your product but release with some rough edges.

For some reason we think that when we release a project to the wild people will start flocking to the signup page, "you build it, they will come" right? but it's never the case, which yeah it is frustrating.

You've spent all this time building this great but no one knows about it yet, marketing is as important if not more important than the development of the product, so make sure you allocate some time for that.

In my experience, unless you already have an audience, it's going to be a long time form when you deploy your project to get paid customers that are not your family or buddies, so the earlier you launch that the earlier you can start getting real feedback and iterate on your product.

Whenever I get the urge to spend a whole day refactoring simple things I ask myself if this will bring more value to the customer, if in the same amount of time that it will take me to refactor this little thing I can provide more value elsewhere I try to do that instead. I know, easier said than done :)

Focus on what energizes you

A business needs constant attention and you have to be able to put in the hours, even when you don't want to, the worst thing is having to work in areas that you don't enjoy. Make sure you work on something that uses your strengths as much as possible, this will also give you a competitive advantage against the competition.

This is the reason why I decided to work on something like Genie, it's a problem that I am passionate about and I can see it evolve in many directions, which excites me and I know will keep me on my toes.

Do it for the right reasons

I have realized that all my failed projects had something in common, they were all built for the wrong reasons. I was chasing a trend, trying to take advantage of a growth opportunity, or unconsciously copying someone else's idea.

When that happens it eventually gets to a point where you don't have the energy to work on it anymore and lose motivation, whenever you start a new project you should ask whether you can see yourself working on this in the next years and if you don't then the idea might not be worth pursuing.

You have to figure out the right reasons yourself as everyone has different priorities, my reason at the moment is that I'd like to make a living doing what I enjoy doing, so I start from there, and then pick something that can solve a real problem and turn it into a business, and not the other way around.

It's been proven that most of what makes a business successful is being consistent and relentlessly market and improving your product to solve real problems, so ensuring that you work on something that you'll be able to still enjoy during years is a pretty great indicator of future success.

I hope you found this insightful! Share if you did :)

I am currently working on Genie, a platform that streamlines the process of building and deploying custom bots.

Convert JSON to CSV using JSON path expressions with Konbert

Mo — Wed, 04 Apr 2018 16:35:33 +0000

JSON paths are a very simple and intuitive way to reference elements in JSON documents, similar to CSS selectors, but for JSON.

This is how it works, if you had a document like this:

[
  {
    "name": "Christopher",
    "age": "23",
  },
  {
    "name": "Michael",
    "age": "45",
  }
]

You could extract the names of all the person records with this expression:

$.*.name

where:

$ references the root element, in this case an array
* is to repeat the expression, so it will match on each object of the array
name is to get the name property of the object

So if you used this expression to convert to CSV, this would result in:

name
Christopher
Michael

This is very useful when you need to flatten very complex JSON documents, and you only want to extract a few fields.

Go ahead and try our custom JSON to CSV conversion tool. Any feedback is welcome!