So you want to write an “app” (2025)

So you want to write an “app” (2025)(arcanenibble.github.io)

143 points by jmusall 69 days ago | 74 comments

analog31 69 days ago |

I did something similar. I’m not a developer, but I use programming as a problem solving tool, and have written little apps for limited uses such as controlling a fixture in the factory — stuff that the devs won’t touch. My first language was BASIC on a mainframe, before I had access to a microcomputer.

I was getting sick of Visual Basic and Excel, and besides, my VB license was more than a decade old. So I went “language shopping” by trying out the same two tasks in a whole bunch of languages. And I also let myself be influenced by online discussions, blogs, etc. Between computers at work and at home, I tried out each language on both Windows and Linux. One of the tasks was computational and graphical, the other was controlling a widget connected to USB.

I ended up with Python, and have been loyal to it for 13+ years. Did I make the best choice? I can drum up a list of pro’s and con’s, but it would be based on hindsight.

zahlman 69 days ago | |

> I ended up with Python, and have been loyal to it for 13+ years

As another long-time Pythonista: I feel like I would have ended up with it anyway, but I do kinda wish I'd done more of that kind of experimentation around that time.

Certainly I've made mental lists of things I'd change about the language. (Not a lot of overlap with the complaints I hear most often, actually.)

MrZorro 69 days ago | |

I'd love to see that list, I'm really intersted in your perspective given the time you put in.

analog31 69 days ago | | |

It was kind of a hodgepodge, since I gave myself a couple of rules. First, it had to be free. Second, it had to run on both Windows and Linux. Those were harder constraints in the 2010's.

To give a flavor, I tried Python, GCC, Javascript, and some higher level tools like Maxima and Octave. So I was certainly not systematic in my search. And trying Python coincided with a really pleasant and comfortable vacation where I had some blocks of time to play with it in peace.

The devs at my workplace had just jumped onto C#, but it was exactly during the time when C# was a mountainous download, hard to install without a good network connection, and Windows-only. I didn't relish staying dependent on Microsoft. Building a "hello world" app also seemed laborious.

Some of those issues have become meaningless, but here we are. On the other hand the growth of the Python community and ecosystem are hard to dispute.

You can see that among Python, Maxima, and Octave, you've got a REPL and a notebook style interface. At a previous job, I was a heavy Mathematica user. But Python was definitely gaining momentum compared to those other tools.

If I were to issue a complaint about Python, it's that the language has sprawled to the point where it's hard to claim that it's easy to learn unless someone helps you get started with a subset of it.

Mielin 69 days ago | |

Im curious to see the whole list of languages you tried, and result with each. I suspect it was related to finding suitable library for each problem (usb, graphics) more so than the language itsel. But maybe ecosystem is what we need from a language.

dvh 69 days ago |

When I need desktop app for my personal needs, I'm still writing them in Lazarus (text editor, git client, music player, spreadsheet, image cropper, various oddball one off desktop apps). It works on Linux and windows. If it really doesn't need to be desktop (typically visual apps that works on different files in different local dirs, or opening it in browser would be awkward) then I make browser app or extension in vanilla js. If it can be both desktop or browser, I chose browser most of the time, Lazarus is not exactly pinnacle of bug free apps.

jrapdx3 69 days ago |

Probably not what most on HN would think of, but for writing a simple app with a GUI, I'd suggest that Tcl/Tk is hard to beat. Of course the simple approach wouldn't suffice if the program had to be compiled to a native binary. Though Tcl/Tk has an excellent C API, so a binary version of the app could be built if considerably more work to accomplish.

veqq 69 days ago | |

I second this, Tcl is a lovely language in general and quite lisp like. One of the nicest and most unexpected experiences was learning it last year. Tk is then trivial from Tcl, with nice native GUIs being 15 mins away.

jrapdx3 69 days ago | | |

Yes indeed, I concur completely with your comments. I've used Tcl/Tk for a few decades and for a long time enjoyed it's Lisp-like character. Of all GUI toolkits Tk is by far the best thought out, no wonder it's been adopted by a number of other languages.

Tcl does have a few disadvantages, for one the lack of distinction between string and list types makes certain programs hard to write. Also the absence of lexical environment for the apply command requires awkward workarounds. Many Tcl users dislike expr syntax.

Warts notwithstanding, Tcl has allowed me to be very productive. Over the years it's been steadily improved, and yet remains mostly compatible with code written even decades ago. That's a rare accomplishment in the programming universe.

divan 69 days ago | |

I tried Tcl/Tk back in 2005 and abandoned it in favour of Qt/QML (and much later Flutter), mostly because UI was so bloody ugly it was embarassing to show to any other user except myself. Has anything changed since then?

jrapdx3 68 days ago | | |

AFAIK the answer is an emphatic yes, a lot has changed since 2005. Tcl9 was recently released and has many new features. As far as Tk goes, for a number of years we've had "themed Tk" or Ttk widgets, much better styling, resembles native widgets quite closely. Ttk widgets aren't as configurable as regular ones, well, everything has tradeoffs.

You should take a look at the current releases, you might be pleasantly surprised.

olcay_ 69 days ago |

I think Jetpack Compose is not actually as bad as you think. I think it's really great and I wish more people caught on actually.

I can't comment on the learning materials as I was following it since the project started and I was already accustomed to the Android Developers website.

Kotlin has a few reactiveness concepts that make reactivity easier but might scare off developers from other languages. The most important ones are Flows and Coroutines.

Say you want to have a UI that shows the current list of connected devices that should always show up to date info. The function to get the list would be something like this:

  val devices = manager.getDevices()

But you need it to be declarative instead of imperative, so you use a Flow:

  val devices = flow {
      while(true) {
          emit(manager.getDevices())
          delay(1000)
      }
  }

Devices is now a cold flow. It does nothing unless it's being collected. When you start collecting it, e.g. by using collect:

  devices.collect { list -> ... }

Now it starts running the while loop and you get the up to date devices list in your lambda every second. You can also make the lambda run only when the list has changed, or debounce it, or run only for the latest value, and more with trivial function chaining. But this function is suspending, which is Kotlin's way of async functions, and suspend functions take turns running on the threads that are managed by the coroutine scope they are in, so you need to provide it a coroutine scope by wrapping your collection in scope.launch { ... } .

And your viewmodel can now collect the flow in a way that's going to be accessible without suspending (async) functions by turning it into a StateFlow:

  val devicesStateFlow: StateFlow<List<Device>> = devicesFlow.stateIn(scope, some more arguments...)
  // Now synchronous code can call like this:
  print(devicesStateFlow.value)

  // And Compose (reactive ui) code can do this in Composable functions:
  val devicesState by vm.devicesStateFlow.collectAsState()

I think that was the source of confusion you had when you were trying to use datastore. It's designed for reactive applications so you were supposed to use it in a viewmodel, turn it into a stateflow and collect it as state in your ui.

memothon 69 days ago | |

This model is probably really strange to people who haven't spent a ton of time working in something like Clojure.

gavinray 68 days ago | | |

Flows are obvious to anyone who has worked with streams, and coroutines are obvious to anyone who has worked with async/await languages.

judah 69 days ago |

Increasingly, there just aren't enough incentives to write native apps.

This isn't a criticism of the article, but rather a tangential observation about why so many people turn to the web instead of using native toolkits to build apps, and why so many of native toolkits feel uninspired and lacking any real innovation.

If I choose to build an app using web tech, I get:

- Universal distribution

- No download and install process

- No "please wait while we update this"

- Users can easily share my app

- Users can link to individual pages within my app

- Users get autofill for forms and passwords and credit cards

- Users can block ads

- Users can scale and zoom my content

- Users can find text on any page in my app

- No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.

- A clearer security model: web apps prompt the user for access to e.g. microphone, camera, or secure disk locations. Native apps can kinda do whatever they want.

Why would I give up all those things to write a native app? A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

Another common answer is app store distribution, but web apps can now be published to the major app stores without Electron or other frameworks. Google Play and Microsoft Store both support PWAs, and iOS App Store supports web apps via web view.

There are some scenarios where a native app is warranted. For example, hooking into some native component or OS API; e.g. HealthKit on iOS. But for many apps, the web is good enough.

casey2 69 days ago |

I think most people starting on linux or *bsd (and macos power users) will learn about POSIX long before they start programming. Usually because a shell script they want to run breaks

If you type 'shell' into arch wiki the first line talks about POSIX On my system typing 'man sh' brings up a posix programming manual. On systems with dash the man page refers to POSIX. On Wikipedia linux mentions it all over the place, on unix's page the offical site link is a link to opengroups. Even 'man man' (man-db) mentions POSIX. Oh, and the coreutils info page mentions it right at the start (and 234 times in total) which based on my admittedly poor count is the second most used nonstandard word behind env beating out coreutils/cp/du/cksum/printf/uniq/.

Until we hit the YOTLD users will continue to be exposed to standards.

haolez 69 days ago |

Lazarus[0] would probably have scored well in this exercise.

[0] https://www.lazarus-ide.org/

cadamsdotcom 69 days ago | |

It’s a bit hard to see from their website what would make you say this, but I am very curious!

Why would you back Lazarus?

haolez 69 days ago | | |

Just because of the other examples, which even include C applications or GTK ones. Not strong contenders against something derived from old Delphi like Lazarus.

However, Electron & the web stack has clearly won.

NetMageSCW 69 days ago |

I wish you had tried C# with WinForms which is still has the best GUI development tooling in Visual Studio.

doesnt_know 69 days ago | |

> As mentioned, my past experience with GUIs was with WinForms, and so I wanted to see what had changed or improved in the intervening years.

They didn’t need to because they already had WinForms as a baseline experience for Windows UIs.

vunderba 69 days ago | |

If I was still doing Windows development, I would likely still be using Winforms to this day - you can't beat it from a purely functional prototyping tool even if it doesn't produce the most aesthetic GUIs ever.

It's a great successor to IMHO one of the other all time best RAD environments, Visual Basic. (Though I've head Pascal had some really nice out-of-the-box tools for GUI work)

Tallain 69 days ago | | |

Delphi has an amazing RAD environment. For building small, self-contained desktop apps (with cross-platform support!) it beats any other modern offering... if you can get past the ecosystem. The language and ecosystem very much show their age.

Anyway, I think this generation is missing out on the experience of building in a real RAD environment. I'm more on the backend, but from what I see the pinnacle is fast hot reload, which pales in comparison to what could be.

wolvesechoes 69 days ago |

> it's simply not clear why a new developer would or should bother to invest in Microsoft's ecosystem

Well, depends on the context.

In my domain (professional, non-software engineering) Linux users don't matter as Linux users generally don't like to pay for products, and Mac users don't matter because they do not exist in this context. Zero incentive to bother with anything that is NOT Microsoft ecosystem.

satvikpendem 69 days ago |

They should've tried Flutter, which is what I primarily use for building apps, and it's hard to find a competitor that's as "write once, run everywhere," as Flutter. Only Dioxus with their native renderer might come close, but that's years away from being at a Flutter-level production capacity.

dfee 69 days ago | |

i worry about Dioxus. not because "they're going to be destroyed by their VC funding" directly, but indirectly. is this a sustainable endeavor? does the market really want them or care about them? it's hard to consider and commit to them, when it's unclear if they're sustainable or just running on the fumes of a passionate founder three months away from marking the project as unmaintained and walking away.

to that end, while i find beauty in dioxus, i've been more willy to play with expo.

jtesp 69 days ago | | |

it's a bet for sure. but if you squint or zoom out, you can see that dioxus labs is creating a whole new land of possibilities with blitz, taffy and their rust hot-reload. nothing is more motivating to a founder than adoption so i think developers should look at the big picture and contribute more to help speed things up. a big blocker for me was video in blitz but i solved it myself. ultimately it's up to developers to take a risk and give dioxus some credible case studies. flutter really dropped the ball on web and dioxus has a huge opportunity on the line. hopefully people will give it a real shot to help build some momentum. they are miles ahead in a lot of ways simply due to the vastly available rust crates

satvikpendem 69 days ago | | |

That's what happened to Darklang, if I recall correctly. I've been hearing about it for almost 10 years now and they went through multiple language rewrites and ultimately went bankrupt and then open source. Turns out it's hard to make money in languages and tooling.

spacecadet 69 days ago | |

Flutter turned out surprisingly useful.

satGuess 69 days ago |

I keep coming back to the web for small projects for exactly those reasons.

The distribution alone is hard to beat — if someone can open a link and try the app instantly, it removes a huge amount of friction.

stackedinserter 69 days ago |

How about React native? Is it still a thing in 2025/26?

potatoproduct 69 days ago |

I'm a semi-retarded product manager that was interested in what it was like building linux desktop apps. With a hand from Claude, I was surprised to get a simple Gnome/gtk widget that was functional and understandable. I was also able to iterate on it without any headaches.

diego_sandoval 69 days ago |

Use Flutter.

wiseowise 69 days ago |

Good that someone is calling out Compose. Android team and Google and JetBrains should be ashamed of the state of documentation around it. It’s all over the place, outdated the moment it is posted and generally feels like written by ADHD students. “Hello world” format virtue signaling they’ve posted on YouTube is an embarrassment and we’re clearly made as ones promo checklist.

Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.

fsflover 69 days ago |

Now, make a web app and compare the effort and tooling.

WalterGR 69 days ago | |

First paragraph:

> After writing that (no-longer-)recent post on web development, I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms if you don't resort to web tech such as Electron.

NetMageSCW 69 days ago | |

With which framework and tooling?

maleldil 69 days ago | | |

Even vanilla js embedded in a HTML file would probably have been easier than most of these.

sublinear 69 days ago |

> I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms...

I don't really understand what this means. Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics. Of all the things to focus on, that's going to be by far the lowest priority in app dev.

Maybe I'm just too young to have ever experienced the kind of stability expected here. My opinions of tools are based on what they are capable of doing and how well it lines up with what I expect them to do. That's my definition of "feel" as an app dev. I don't care if the interface is stable. I want the capabilities to be stable. To make an analogy, when I buy a new work truck I care more about the specs and not the stuff on the dashboard.

> ... if you don't resort to web tech such as Electron

And that's precisely why everything is now a web app for over a decade, and why W3C standards and big tech bureaucracy won out.

BoppreH 69 days ago | |

> Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics.

That's how I took it, and I enjoyed it thoroughly. If you're making a small app by yourself, sufficiently bad developer ergonomics can be the reason that the app doesn't get made at all, or the frustration makes me regret it. That's important for me.

> Maybe I'm just too young to have ever experienced the kind of stability expected here.

This could be it. I've been around many cycles of technology, and it always feels like a great waste when you have to abandon your tools and experience for something that's buggy and better in only a few small ways. I'm willing to tolerate a lot more bullshit for something that I know will be long-lived, like QT or a static website, than Microsoft's UI-framework-of-the-month.

jmusall 69 days ago | |

I guess the author's perspective is one of someone who has little experience with current tools/frameworks, so "ergonomics" become somewhat more important. Most of the complaints are actually about lack of documentation, not instability of interfaces.

I also liked the article especially because it avoided web apps, which I think are a subpar solution to a problem the software industry created itself by not developing more standards like W3C.

duskdozer 68 days ago | |

If you're young enough not to have driven a work truck without a screen and with physical buttons, it would also make sense. Interfaces are a means to access the capabilities, and often the latter gets modified when it's time for a "fresh" interface.