So you want to write an “app” (2025) | Hacker News Reader

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

arcanenibble.github.io

143 pointsjmusall74 comments

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.

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.

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

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.

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

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.

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.

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.

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.

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?

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.

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.

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

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

I think the fact the rebuttal has to be a random lengthy comment on the internet says it all - Jetpack Compose documentation is a bit garbage. Old style android docs were more complete.

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.

> most web apps load faster than their native counterparts these days

maybe i'm doing something wrong, but from what i've noticed, the browser is usually what takes up most of my computer's resources.

also, i assumed the reasoning for using a native app was for offline use, honestly.

No you're not. They just made it up :)

Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.

I think a lot of hatred toward web apps actually comes from the hatred toward cloud-first design. Notion feels sluggish compared to Obsidian, but is it really due to electron? Or the fact that one is cloud-first while the other is local-first?

Edit: well I just looked it up and it seems that Obsidian is electron-based too.

Yeah. You cannot achieve native performance with web apps, but most tasks are simple enough that wasm is plenty fast. If you generate a frame in 7ms or 1ms, the user can't tell the difference.

I think cloud-first design is natural because webapps have nowhere good to store state. On Safari, which is the only browser that matters for many web developers, everything can be deleted at any time. So if you don't want to have a horrible user experience, you have to force your users to make an account and sync their stuff to the cloud. Then, the most natural thing to do is to just have the user's frontend update when the backend updates (think old-school fully-SSR'd apps). You can do much better than that with optimistic updates but it adds a lot of complexity. The gold standard is to go fully local-first, but to really do that right requires CRDTs in most cases, which are their own rabbit hole. (That's the approach I take in my apps because i'm a perfectionist, but I get why most people wouldn't think it's worth it)

With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail, but despite offering great benefits in terms of self-custody of data it was never a great user experience for most people.

> With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail,

Even withou the files API, with local storage, web apps can (and some—mostly extremely casual games that are free—do!) duplicate that experience with the extra risk of your data being lost because your disk became too full or some other event causing the local storage to be cleared.

I once ran out of disk space while Chrome was running and, despite me clearing the space again shortly after, the damage was already done and Chrome had already decided to wipe all my local storage and cookies. It didn't keep it in memory to save again once there was space, it just deleted it all permanently.

> If you generate a frame in 7ms or 1ms, the user can't tell the difference.

But muh 0.00001W of energy!

> In the meanwhile VSCode has become the most used editor by developers and it's not even close

Correct me if I’m wrong but isn’t VSCode an Electron app? ie a webapp shipped together with a stripped down browser

I know that GitHub Codespaces open as a full VSCode editor in my browser so I always assumed it was the same code.

I’ll never understand “stripped down browser” like it’s some curse. Any managed language brings its own runtime. C# brings CLR runtime, Java brings JVM, Go brings its own runtime.

I’m not saying it’s a curse, I’m saying it’s a webapp. Because the person I’m replying to used it as an example of something you can only build as a native app.

Both Notion and Obsidian are sluggish compared to Minimal.

I’ve also never heard about minimal, while I’ve heard about Notion and Obsidian.

I tried a web search for "Minimal text editor" and Minimal vs Obsidian" and couldn't find any results that seemed to be an obsidian or notion equivalent.

> Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.

McDonald's is probably most popular... "food serving place" in the world.

> No download and install process

Plenty of Electron apps expect you to do this anyway. "Apps using web tech" aren't all web sites.

> No "please wait while we update this"

Not everyone has a fast web connection.

On the flip side, plenty of programs have no reason to use a web connection at all once they're downloaded and installed.

> Users can link to individual pages within my app... Users can find text on any page in my app

How many apps out there really have "pages"?

> Users get autofill for forms and passwords and credit cards

Why does my program need this information?

> Users can block ads

Why would my program present ads?

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

Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.

> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

Care to give an example?

(It also generally comes across like you just take for granted that your users will be on mobile.)

I'm convinced that the real problem here is that people preferring websites only know how to make websites and won't learn anything new. The rest is just to frame it as a rational technical decision.

> How many apps out there really have "pages"?

A lot of them. Enough for me to wish I could have OS bookmarks for specific app screens.

> Why does my program need this information?

Because I as a user don’t want to copy paste sensitive information? Also, not sure what the OPs point is, you can have autofill on native apps too.

> Why would my program present ads?

Because you’re a penny counter at big tech who subsidizes their product by stealing user information?

> Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.

Web has one of the most hardened sandboxes out there, just because it was an attack vector for decades. Yes, it’s a good thing - less friction.

> Care to give an example?

VSCode loads faster than Xcode. Google Sheets loads faster than Numbers. On Windows you can start VSCode and brew coffee until VS is ready to roll.

> Because I as a user don’t want to copy paste sensitive information?

When using my program, why would the user need to supply a password or a credit card number?

> why would the user need to supply a password

Because they’re logging in to your application and then buying a thing with a credit card?

Why would I write a program for this, when we were doing it decades ago with web pages that honestly didn't even require JavaScript to function?

Because your product is a program and some of the features are paid. So you have a screen for the user to start/manage/cancel their subscription? It doesn't have to be some JS heavy thing, just that it will be a page in your app and you get autofill for free from the browser.

Native apps are where power users and other non-developers can do programming. The type of things that an engineer who lives in the terminal might make a CLI or TUI for, an accountant or project manager might want to do with a GUI. This is where VB6 and VBA lived, probably also HyperCard. Web tech has too much complexity for that.

> Web tech has too much complexity for that.

Too much complexity like checks notes Google Sheets, VS Code, Notion.

None of which were made by accountants. They were instead made by engineers who have experience and training in dealing with complex software systems.

https://developers.google.com/apps-script

I also find building apps for the web is much easier than any of the native frameworks. You can start by writing plain text in a file and then progressively add HTML, CSS, and JS. The app described in the article is trivial to implement in the web.

A lot of that comes down to the huge community and the shear amount of documentation that exists. OTOH, nowadays you will quickly be distracted by frameworks and build systems.

IMHO the biggest hurdle is hosting, but github pages makes even that somewhat easy.

Can't agree more. The web has won, and for the vast majority of apps, it's not even close.

I wish I figured this out years ago. I spent significant time learning and building with Flutter, iOS native — chasing that "native feel" — only to realize that for most of what I was building, a well-crafted web app would have been not just good enough, but actually better.

> and why so many of native toolkits feel uninspired and lacking any real innovation.

You ever thought that it’s the reverse? That native toolkits were left to rot, because it’s always the cost center (looking at you Android team, you’re a fucking disappointment), while web continued to evolve?

> - Users can block ads

Google fuckers are desperately trying to fix the “feature”.

This hit a nerve as I am in the middle of developing a webapp for myself using NiceGUI. I find CSS, especially its layout framework, pretty confusing and sometimes downright intimidating to work with. `inline`, `block`, `flex`, `grid` seem reasonable when you read about them. But when using it, especially within frameworks when flexboxes are nested within grids which are nested within flexboxes and so on, it becomes hard to reason about. And then you throw in media-queries in the mix and it becomes even more dense.

> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.

This is so off-the-mark I am skeptical of the rest of the claims in this list.

The MS Word webpage absolutely loads faster than MS word. Same with Outlook. Microsoft is even about to cheat https://www.theregister.com/2025/05/01/microsoft_will_preloa... and preload their apps to fake faster load times.

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.

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

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

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?

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.

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

> 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.

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)

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.

> 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.

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.

Flutter turned out surprisingly useful.

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.

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.

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

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.

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

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.

Use Flutter.

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.

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

With which framework and tooling?

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

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.

> 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.

> 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.

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.

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.

Reply on news.ycombinator.com