LazyDoomSlayer

Posted on May 14

Building Software Beyond the Browser

#rust #tauri #webdev #opensource

For the last 3 years, most of my work lived inside the browser.

Vue.js SPA development, Nuxt applications, frontend architecture, SEO optimizations the usual frontend ecosystem.

And honestly, after some time, I started feeling limited.

Not because frontend development became bad or boring, but because I felt like I was mostly moving inside the same boundaries over and over again.

The only thing that still looked extremely interesting to me on the frontend side was probably Three.js, but I never really found a practical place where I could meaningfully use it.

At some point, I realized I wanted to build software that could do more than a browser tab allows.

I wanted:

direct operating system interaction
process management
local-first tooling
background tasks
hardware communication
system utilities
applications that continue running outside the browser lifecycle

That curiosity slowly pushed me toward Rust.

The Problem That Started Harbor Sweep

Ironically, Harbor Sweep started because of a very small and annoying workflow issue.

I was dealing with a Windows/JetBrains-related bug where ports sometimes remained occupied even after shutting down services or closing development environments.

Technically, solving it in PowerShell was easy.

But doing it repeatedly every day became annoying enough that I decided to build a small utility for myself.

At first, it was just meant to save me a few seconds.

Nothing more.

But eventually, that small utility became my Rust playground.

I kept adding features, improving workflows, experimenting with architecture, and trying ideas I normally could not explore inside traditional SPA development.

Discovering TUI Applications

Around that same period, I attended my first RustMeet in Gliwice.

That event changed my perspective a lot.

Until then, Rust still felt somewhat “distant” to me interesting, but maybe overhyped.

The meetup made me realize people were actually building real systems, tools, and infrastructure with it.

At that point, Harbor Sweep already had a GUI version.

Then Orhun Parmaksız casually suggested:
“Why not build it as a terminal UI application?”

That idea immediately clicked for me.

So I started experimenting with Ratatui.

And honestly, building terminal applications felt surprisingly refreshing.

You start thinking differently when the entire interface becomes keyboard-driven and event-based.

The focus shifts from visual browser components to:

application state
rendering loops
event handling
terminal constraints
responsiveness
workflow efficiency

It felt much closer to the operating system itself.

Desktop Software Changed My Engineering Mindset

The deeper I went into Rust and desktop development, the more I realized how different the engineering mindset becomes outside the browser.

In frontend development, many low-level details are abstracted away.

With desktop and systems-oriented software, suddenly you start thinking about:

threads
async workflows
long-running processes
local persistence
OS APIs
notifications
background schedulers
process management
direct system interaction

The browser sandbox disappears.

And with that freedom comes a completely different type of responsibility.

What surprised me most is that learning Rust itself was not the hardest part for me.

The documentation is genuinely excellent.

And modern AI tooling helps a lot when you need practical explanations instead of spending hours watching crash courses.

Async Rust is still something I continue learning, but overall, the language itself felt much more approachable than I originally expected.

What Was Actually Hard

The hardest part was not ownership or the borrow checker.

It was shipping software properly.

Packaging, installers, release pipelines, platform-specific behavior, distribution systems like Chocolatey or Snapcraft that was the part that forced me to adjust the most.

Debugging also feels very different outside frontend environments.

In browser development, the tooling is incredibly mature and immediate.

Desktop applications force you to think closer to the operating system itself, and debugging often becomes much more low-level and environment-dependent.

That transition took far more adaptation than the language syntax ever did.