Almost all of Patrick's points are great if your software development goal is to make a buck. They don't seem to matter if you're writing open source, and I'd argue that desktop apps are still relevant and wonderful in the open source world. I just started a new hobby project, and am doing it as a cross-platform, non-Electron, desktop app because that's what I like to develop.

The onboarding funnel: Only a concern if you're trying to grow your user base and make sales.

Conversion: Only a concern if you're charging money.

Adwords: Only a concern if, in his words, you're trying to "trounce my competitors".

Support: If you're selling your software, you kind of have to support it. Minor concern for free and open source.

Piracy: Commercial software concern only.

Analytics and Per-user behavior: Again, only commercial software seems to feel the need to spy on users and use them as A/B testing guinea pigs.

The only point I can agree with him that makes web development better is the shorter development cycles. But I would argue that this is only a "developer convenience" and doesn't really matter to users (in fact, shorter development cycles can be worse for users as their software changes rapidly like quicksand out from under them.) To me, in my open source projects, my "development cycle" ends when I push to git, and that can be done as often as I want.

To me, I prefer desktop apps because I KNOW when I've upgraded - it either said "upgrade now?" and did it, or, in the olden days, I had to track it down, or I installed an updated version of a distro, which included updated apps, so I expected some updates.

There are some things that NATURALLY lend themselves to a website - like doctor's appointments, bank balance, etc - but it's still a pain when, on logging in to "quickly check that one thing" that I finally got the muscle memory down for because I don't do it that often, I get a "take a quick tour of our great new overhauled features" where now that one thing I wanted is buried 7 levels deep or something, or just plain unfindable.

For something like Audacity (the audio program), how the heck does it make sense to put that on a website (I'm just giving a random example, I don't think they've actually done this), where you first have to upload your source file (privacy issues), manipulate it in a graphically/widget-limited browser - do they have a powerful enough machine on the backend for your big project? - then download the result? It's WAY, WAY better to be able to run the code on your own machine, etc. AND to be stable, so that once you start a project, it won't break halfway through because they changed/removed that one feature your relied upon (no, not thinking of AI at all, why do you ask? :-)

This blog post benefits a lot from understanding where the author was at that point in their career: They had gained notoriety for their writing about their Bingo Card Creator software, but were moving on. After this they went on to build Appointment Reminder, a webapp that grew to a nice MRR before being sold off. Both were nice little indie developer success stories.

I grew up reading his writings and learned pretty quickly to read them as "this is what I'm thinking right now in my life" even though they're written more as authoritative and decisive writings from an expert. Over time he's gone from SEO expert to $30K/week consulting expert to desktop app expert to indie SaaS expert to recruiting industry expert to working for Strip Atlas. It was fun to read his writings at each point, but after so many changes I realized it was better to read it as a blog of ongoing learnings and opinions, not necessarily as retrospective wisdom shared from years of experience on the topic even if that's what the writing style conveys.

So I agree that the advice in the post should be taken entirely in context of pursuing the specific goals he was pursuing at the time. The less your goals happen to align, the less relevant the advice becomes.

Going further, if you're a hobbyist, you're probably instinctively prioritizing the aspects of the hobby that you enjoy. My first app was a shareware offering in the 1980s, written in Turbo Pascal, that was easy to package and only had to run on one platform. Because expectations were low, my app looked just as good as commercial apps.

Today, even the minimal steps of creating a desktop app have lost their appeal, but I like showing how I solved a problem, so my "apps" are Jupyter notebooks.

They're also ubiquitous for creative works, i.e. the sort of things a small set of people spend much time on, but is not something most people use. Examples:

  - CAD / ECAD
  - Artist/photos
  - Musician software. Composing, DAW etc
  - Scientific software of all domains, drug design etc

I see a lot of this sentiment amongst developer friends but I never could relate. Its not that I'm against it or something but it just doesn't move me personally.

Most things I create in my free time are for my and my family's consumption and typically benefit immensely from the write once run everywhere nature of the web.

You can launch a small toy app on your intranet and run it from everywhere instantly. And typically these things are also much easier to interconnect.

> Analytics and Per-user behavior: Again, only commercial software seems to feel the need to spy on users and use them as A/B testing guinea pigs.

KDE has analytics, they're just disabled by default (and I always turn them on in the hopes of convincing KDE to switch the defaults to the ones I like).

I quit all social media, cancelled Spotify and whatnot and I am hella thankful for the Strawberry media player as a desktop app as it allows me to play all the music i actually own. I love desktop apps.

>To me, in my open source projects, my "development cycle" ends when I push to git, and that can be done as often as I want.

If development ends at a git push and users are left to build/fend for themselves (granted this is a lot of open source), then yeah not much difference, but if you're building and packaging it up for users (which you will more likely to be doing if your project is an app specifically) then the difference is massive.

Agreed, desktop frameworks have been getting really good these days, such as Flutter, Rust's GPUI (which the popular editor (and more importantly a competitor to a webview-based app in the form of Electron) Zed is written with), egui, Slint and so on, not to mention even the ability to render your desktop app to the web via WASM if you still wanted to share a link.

Times have changed quite a bit from nearly 20 years ago.

I generally despise "web tech" as it is today. Browsers are not application platforms!

Agreed.

And his point about randomly moving buttons to see if people like it better?

No fucking thanks. The last thing I need is an app made of quicksand.

its just waaaaaay easier to distribute a web app

For some things a desktop app is required (more system access) or offers some competitive UX advantage (although this reason is shrinking all the time). Short of that user's are going to choose web 95% of the time.

To be fair, probably most of us here on HN write software to put food on the table. Don’t pooh-pooh our careers.

Attitudes like these is why non-developers don't want to use open source software.

These concerns may not matter to you, the developer, but they absolutely matter to end-users.

If your prospective user can't find the setup.exe they just downloaded, they won't be able to use your software. If your conversion and onboarding sucks, they'll get confused and try the commercial offering instead. If you don't gather analytics and A/B test, you won't even know this is happening. If you're not the first result on Google, they'll try the commercial app first.

Users want apps that work consistently on all their devices and look the same on both desktop and mobile, keep their data when they spill coffee on the laptop, and let them share content on Slack with people who don't have the app installed. Open source doesn't have good answers to these problems, so let's not shoot ourselves in the foot even further.