Your post is touching on a key question: why write a Windows-specific app?
I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?)
Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
For me, I see these following advantages:
- Performance; Native & compiled is king.
- Ram usage; Kilobytes vs Mega(giga?)bytes.
- UI control which integrates with the rest of the OS (and updates when the underlying OS tweaks the UI)
From a business standpoint, I get your point that these points don't really matter. Users have shown to not care in the slightest at the bloat in programs.
However for code I write in my spare time, I would much rather write my native Linux program in compiled code than to ship a subpar experience to the few who will interact with it.
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
You mean the hypertext platform that has been shoehorned into Java's paradigm, suffering from the same boof-o-rama as Windows, and whose lowest common denominator to support must be Safari for iOS?
Sure it is a hassle to get notifications working, but my take on that for years as a desktop user was "I need another source of spam about as much as I need to get raped". For years I had bottom of the line Android Tracfones and wondered "how is it people get so excited about apps?" because they just didn't work but once I got an iPhone I started to appreciate that the McDonald's app would send me a notification when my food was ready. Recently it was pointed out to me that the application behind these cards
really would benefit from notifications ("your photos are ready!") and I am looking at the hurdles I can jump through and it looks possible but weird. Like why would I want people to install my app on the homescreen where it will get lost on page after page of twisty little app icons that all look alike?
Then there is that PWA boondoggle, there is another app in that system that I can use to register those cards and it is a clear case where I might want to do it outside of cell coverage (say I was in the woods) save a form submission and upload when I get back in range.
What can I say? That service worker system is insane, something like Kubernetes that only Google could subject us to. I mean, Google could have worked out the math for synchronizing a local database to a remote database, by then the Lotus Notes patents were mostly expired, we could have gotten something good. Or Google could have added an API to control the behavior of the browser cache. Instead we got something half baked and barely reliable and then Apple went out and made something a little bit worse. Had it been a good standard to begin with the outcome could have been entirely different.
I used to get hung up on this native vs web thing. But when it comes down to it, it's just one renderer or another unless you're actually drawing the controls yourself pixel by pixel. The sticking point is following the system style / theme. But all the popular desktop OSs seem to have deviated on this so much themselves I'm not sure how important this is.
The inconvenient truth here is also that following the system theme is an anti-feature for most apps. On the desktop, you want your app window to be recognizable at a glance, meaning the primary color should be the brand color, etc.
I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.
It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".
This. So often features to use system colors can cause apps to be unreadable or just look like crap. The first time I get a bug report that people can't read something I will lock the colors the down, I just don't have time for that.
Who says the system theme is well designed at all? Back in the 1980s you could count on most text color combinations on a Commodore 64 or an IBM 3279 or a PC with a CGA working.
Today it is absolutely normal to type
ls
on a Linux machine out of the box and if you are running X or Wayland some of the file names are dark blue on a black background and completely un-readable. To be fair, if you are logging into a Linux machine on Windows with ssh on CMD.EXE or most terminal software you get similarly poorly chosen colors. (To be fair, MacOS does do better!)
As a web developer it pisses me off because I am expected to follow
and regularly my management gets legalistic looking documents from customers complaining that we only have 6.5:1 contrast on something and you know what I do... I fix it. I wouldn't send anything to my tester that was unreadable and if I did I'd expect her to put in a ticket and I would... fix it. When MUI computes the coordinates wrong and something draws 20px right of where it should be... I fix it.
Whenever I've put similar tickets to the various parts of the Linux desktop mafia they close it as "won't fix" and often give me a helping of verbal abuse. Even Microsoft occasionally fixes something (even if half a decade late) and their people are polite.
yea there's so many ways through this now. golang and wails is great, rust and tauri is great. both seem to not feel like the slug that is electron because they just use whatever os native web view your os has.
for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.
i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.
i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.
The DOM is very ill-suited for most UI. Too complex and lots of missing features. It’s a whole bag of unneeded code and the resulting UI doesn’t fit anywhere.
> The DOM is very ill-suited for most UI. Too complex and lots of missing features
Can you expand on this, because I'm not seeing it myself. The DOM, html+css is very flexible. It easily encompasses most UI. Most UI is some kind of data display, so lists, trees, tables, forms.
The need for JS might be what you're complaining about. I think we might be stuck with it as a UI control language forever.
The DOM(and CSS) is primarily built for documents and forms, even with the latest addition like Flexbox or Grid layouts. It is closer to typesetting tools like troff, latex, texinfo than any UI engines you can think of. And some that are not needed, like the difference between <i>, <a>, <span>, <strong>,...
Also with most GUI frameworks, there's some difference between widgets like label, button, menu, checkbox,... and containers that does layout management. And there are not a lot of elements in both sets. This is the reason why React Native has a very sparse components library. With simpler implementation, you have a simpler rendering path, and the developer have less elements to deal with.
Also some have ready-made implementation of really useful widgets, like tree, grids, tables, lists, and other dynamic things. You can find libraries for those on the web, but the web implementation of scrollable container is janky.
The GUI system for the NeXT was based on the Display PostScript system which in turn was based for the PostScript system designed for rendering to printers. Quartz in MacOS X is a further evolution of that.
Inside HTML 5 you can find facilities for rendering documents and you can find facilities for rendering applications, including those forms. There is not a clear line between one and the other.
PostScript was for rendering graphics to a printer with a good emphasis on texts. Most of HTML is about marking up and styling interactive documents. There’s no clear line between the two, but an API for applications UI has different goals than one for document typesetting (even interactive one).
HTML have a lot of tools for devex, but if you’re going for a good codebase and simple implementation for a desktop application, QT is way easier.
Seems to me the point of the web is: no app store bullshit.
On the web if I want to publish a web app... I publish the app. If Apple things my app isn't good for their business... tough luck for them.
If I want to update a web app... I update the app.
If a user wants to use an app... They visit a URL and the app is there! No having to face id, go looking for the app in an interface that's designed to hide the search function, that is filled with spammy trash imitation apps (that somehow get approved by the app store anyway)
All the time I hear somebody crying that their developer account got canceled and I want to say "what did you expect? the contract for a developer account is a suicide pact for your business." Stay free!
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS?
There are other options besides "web app" and "only one OS". A cross platform app which uses something like GTK or QT will be a massively better experience for your users, one a web app cannot hope to equal.
I know one of the GTK developers who dropped out of my research group in the 1990s who's been in charge of triaging tickets and he's the kind of guy who doesn't care if there is just 1.05:1 contrast between text and background and will refuse a one-line patch to make menus render right in rootless X windows because he wants to punish you for doing things in a way he thinks is wrong.
And he probably wonders why it is never "the year of the Linux desktop" but hey it is OK because Red Hat Linux is something enterprises subject their users to and if it had the slightest bit of flair customers would complain.
So when I hear GTK I think Nein Danke!
In general Linux has the kind of fanbois problem that MacOS had maybe 10 years ago. There are so many things that still "just don't work" after years and they never get fixed because you can live without them. For instance I can tell you how to install some package like
sudo apt-get install mypackage
and that's all! I can make 10 pages of screenshots to tell you to click and click and click and click and click to install "mypackage" with the GUI [1] and you may wind up looking at a spinner for 10 minutes or longer (eventually you give up) and you might wind up corrupting your package database and not being able to install or update anything until you look up how to rebuild it. The Linux desktop is stuck with having done the 20% of the work that gets it 80% done and never does the rest of the work because you can use the command line anyway.
[1] and you still might misunderstand it and need intensive tech support
Interesting, at first pass I’d say the source availability has little to do with the topic at hand. But on second thought it might be rather significant. No company would finance making 2x identical cross platform apps, but if you have a pool of OS folks who are free to contribute at their leisure, the calculus changes a bit.
I am a Firefox-first developer, almost everything I write works in Firefox/Chrome/Safari without a lot of drama.
I have one application at work that loads a table with 40,000 rows into a data grid that works really well on Chrome and lags on Firefox, that's the one case where the performance difference matters.
This year I've been interested in biosignals applications that read data with the Web Bluetooth API and Web Serial API which are ordinarily Chrome-only. I was about to get one of my junk Android tablets out of mothballs when I found there is Bluefy for iOS which supports the Bluetooth API so I have no problem going to labs where they have a really klunky HRV system based on a PC and show them something sleek on my iPad and in 20 minutes i can demonstrate to you, with your own physiology, everything you actually need to know out of a big review paper on HRV.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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”.
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.
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.
More than a small kerfuffle. A supply chain attack by a state actor, believed to be China, resulted in undetected malicious code executions from June 2025 to December 2025.
Iran's government is an Islamic fundamentalist dictatorship. It has imprisoned and killed protestors[0], it hung over 700 political dissidents last year[1], it has imprisoned and executed people who have left Islam[2], it has beaten and imprisoned women who refused to wear hijab[3]. As for LGBT rights, Equaldex lists Iran 190th out of 197 nations[4]. Time Magazine reports[5] that some 30,000 people were killed in January for protesting the government.
Even the parent article reports first-hand that the Iranian regime is now labelling protesters as terrorists and calls for their arrests.
This, combined with the drought and economic collapse, has pushed the Iranian people towards revolt.
This is not the fault of Israel, America, Trump, Greenland, white people, or any other boogeyman. It's a feature of Iranian government, and the Iranian people want change.
To dismiss the impact of economic sanctions is at best intellectually dishonest. Economic sanctions aren't a natural disaster. Somebody is imposing them. Who, exactly? And why?
Also, US allies (ie Israel) can kill hundreds of thousands of people without any consequences. In fact, we bankroll the weapons they use to do it to the tune of hundreds of billions of dollars.
So why are the documented atrocities of one country not an issue at all but the transgressions of another country worthy of starving that country for decades? What's different between these two? And who is making that determination?
Iran has no one to blame for the sanctions but themselves. The conditions to drop them have been clear, they have refused. Fine, but you dont get to then turn around and blame the sanctioning countries for the situation you put yourself in.
US and Britain is largely the reason why they're in power in Iran today thanks to their coup and destabilization of the country. And more recently Israel just killed their diplomatic negotiators. Guess they shouldn't have had all that oil if they didn't want to get raped by American imperialism.
Always with the excuses lmao. Dictatorships exist because the people they rule over allow them to. The iranian revolution is yet another example of the people refusing to live under a government they didnt like. When your government sucks its the peoples fault, especially when the government isnt a foreign occupier but a homegrown political movement. Did the US meddling in iran hurt iranians? Sure, but they made the situation worse for themselves over and over again throughout the past 50 years instead of fixing the problem. Every country has had to deal with foreign meddling, some rise to the challenge and some wallow, only making things worse and worse
"People are responsible for their governments" is what I like to call the "Osama bin Laden defense". Put another way, if people are responsible for their governments, that makes any civilian a valid military target.
Taken further, the US has actively deposed or supported the coups of over 50 governments since WW2 [1]. That includes Iranian Revolution of 1979 (where the US supported Khomenei) and Pinochet in Chile. It also includes puppets like Saddam Hussein who committed all sorts of crimes as a US ally including using nerve gas on the Kurds. US sanctions killed half a million children in Iraq according to a UN report. When confronted with this, then UN Ambassador and later Secretary of State Madeline Albright said "the price is worth it" [2].
Economic sanctions are a sanitized way of saying "starving people" and the track record is bleak. Arguably the only time they've ever worked is apartheid South Africa. What they do instead is entrench the very government we supposedly want to get rid of eg North Korea, Iran, Cuba, Russia [3].
So I would respectfully put this to you: you haven't thought this through.
The only reason Iran is starving is because their corrupt, incompetent government diverted all the water to insider usage and agriculture imploded. A government that was installed by a domestic political movement with minimal foreign influence. As I said there are certainly instances where the people can’t end their government because of foreign influence, Iran is in no way an example of that. Their domestic political movement fucked themselves and they can only blame themselves.
A few years before Khomeini came to power, Mohammad Reza Pahlavi implemented the [White Revolution](https://en.wikipedia.org/wiki/White_Revolution) to modernize Iran (including granting women the vote, land reform, etc.).
Khomeini opposed these reforms and considered them contrary to Islam.
Eventually, with support from some [communist parties](https://en.wikipedia.org/wiki/Tudeh_Party_of_Iran) and promises of free buses, electricity, and similar benefits to peoples (like what Zohran Mamdani did), the king was overthrown and Khomeini took control.
Interestingly, Khomeini subsequently suppressed and eliminated the communist parties, seized factories and homes of those who opposed the Islamic Republic, and labeled many opponents as terrorists and enemies of Islam.
To understand what Khomeini and the Islamic Republic enacted:
- Chess was banned for a period as being against Islam.
- Sexual relations with children were publicly condoned by Khomeini in his writings.
- ...
The Iranian government is responsible of all sorts of human rights violations, and also for the drought (at least partly), but the economic collapse was triggered by the US.
Bessent said so at Davos:
"President Trump ordered our Treasury and our OFAC division (Office of Foreign Asset Control) to put maximum pressure on Iran. And it's worked, because in December, their economy collapsed. [...] So this is why people took to the street. This is economic statecraft". https://youtu.be/VQQXLnXlWqY?t=1722
Is this how America helps dissidents? Make them so miserable they can't bear it anymore? Anyways, it never works. It just makes civilians more miserable and the government more repressive. Look at Cuba or North Korea.
Yes, I concede the US is partly responsible for Iran's economic collapse. What a wonderful outcome should it result in the Ayatollahs losing their grip on power.
Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0].
> "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.
> JPEG XL support in Safari actually comes from the underlying OS rather than the browser. My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought. I'm just guessing though.
> The implementation that was in Chromium behind a flag did support progressive rendering to some degree, but it didn't render anything until ~60 kB (39% of the file). The rendering is similar to the initial JPEG rendering above, but takes much more image data to get there. This is a weakness in the decoder rather than the format itself. I'll dive into what JPEG XL is capable of shortly.
> I also tested the performance of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder is about as slow as the Safari decoder. It's not fair to judge the performance of experimental unreleased things, but I was kinda hoping one of these would suggest that the Safari implementation was an outlier.
> I thought that "fast decoding" was one of the selling points of JPEG XL over AVIF, but now I'm not so sure.
> We have a Rust implementation of JPEG XL underway in Firefox, but performance needs to get a lot better before we can land it."
Strange, as Cloudinary's test had the opposite conclusion -- jpegxl was significantly faster to decode than avif. Did the decoders change rapidly in a year, or was it a switch to new ones (the rust reimplementation)?
If decode speed is an issue, it's notable that avif varied a lot depending on encode settings in their test:
> Interestingly, the decode speed of AVIF depends on how the image was encoded: it is faster when using the faster-but-slightly-worse multi-tile encoding, slower when using the default single-tile encoding.
>> My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought.
I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?)
Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.
[0]: https://pwabuilder.com. Disclaimer: I work on this
reply