Hacker News Reader

>That basically already exists on the desktop in the form of Electron apps. Those apps are universally hated because of it.

Discord and Visual Studio Code are among the most popular apps on mac, those are electron apps. None of that is relevant to the core issue either way. It's not up to Apple to decide any of that, that's what the market and regulators are for. Apple uses and pushes self-serving and false narratives as pretext to engage in anti-competitive business practices.

>Web technology is not suitable for making applications. It was designed to format text documents and that's all it's really good at.

That statement might have been true in 1995, but today it's categorically false.

> Web apps are janky, fragile and feel out of place on every OS. It's a 'one size fits no one' solution.

I've already debunked this manufactured, reductionist and false narrative above.

You really haven't. You are up and down this thread saying these things, but you haven't already proven them or even addressed them.

You have points, I agree that web technology is well suited in 2025 to make interactive applications. I agree that web apps are being held back from expressing their true potential. And while Electron is largely skewered for being bloated and heavy, the web can be fast and fluid.

But you haven't proven that web apps don't feel janky, fragile, and out of place. Because they just factually do. The native UI elements of each OS that you can tap into from the web is limited, and not enough to create the same UI in a WebView that you can in a native Swift app, for instance. You of course can coerce the web into imitating any appearance you care to recreate, but it won't look that way by default, and it'll now look even more starkly out of place on every other platform besides the single one you targeted. This is all an intentional aspect of the web as a cross-platform platform.

The web's internet-native status means a bad internet connection or a brief crossing through a dead zone will kill almost any web app. Yes, there's strategies around this with web workers nowadays, but those are quite complex to implement for even simple applications and often aren't worth the effort to do anything more than pop up a branded "you're offline" page. An app can be completely cut off from the internet, it doesn't have that base assumption of network connectivity and isn't built from the ground up from network-based parts.

I already responded to any of your points that are relevant to the core discussion:

https://news.ycombinator.com/item?id=44694037

https://news.ycombinator.com/item?id=44692287

For the rest refer to https://whatpwacando.today

You still haven't. The whole point of my comment is that you haven't, and I brought up specific points that remain un-addressed by any of your comments in your thread, despite your insistence. Linking to comments that largely consist of the next layer of "I already addressed your points elsewhere!" is not a response. The world exists beyond Apple, and "Apple decrees it" is not a sufficient to explain much of your claims.

If you don't care to engage with the substance of my points, fine, nobody is owed discussion, but this style of conversation is deeply unproductive and I believe even you are losing track of what you have and haven't said.

>You have points, I agree that web technology is well suited in 2025 to make interactive applications. I agree that web apps are being held back from expressing their true potential. And while Electron is largely skewered for being bloated and heavy, the web can be fast and fluid.

The main topic originated through OP's "why some users demand a 'native' app when the web app should be enough" for which I provided explanations as to why web apps haven't lived up to their potential i.e. conflict of interest and the corresponding sabotage by a gatekeeper in contrast to the manufactured narrative of "they are unpopular because they suck". That's a false narrative which I've explained in many comments:

- "A Progressive Web App, if allowed to reach its full, un-sabotaged potential, is the technological manifestation of the Digital Markets Act's goals. So it would be utterly absurd for Apple to pour hundreds of millions of dollars into fighting the DMA, just to let PWAs pass which achieves the exact same goals."

- "The reason I focused on Apple is because its actions are one of a profit-maximizing gatekeeper actively defending its most lucrative business against an existential threat that is PWA. Every bug, every delayed feature, and every artificial limitation imposed on PWAs on iOS is a calculated strategic move in this defense of its walled garden that makes maximum taxation possible."

Since you've stated that "I agree that web apps are being held back from expressing their true potential" you confirmed my thesis. That's why I stated: "I already responded to any of your points that are RELEVANT to the CORE DISCUSSION"

>But you haven't proven that web apps don't feel janky, fragile, and out of place.

That's not even part of the core issue and it has still been explained in my post anyway, which you even confirmed by saying "I agree that web apps are being held back from expressing their true potential" and is also expressed here:

- Apple's ban of third party browsers on iOS is deeply anti-competitive, STARVES the Safari/WebKit team of funding and has STALLED innovation for the past 10 YEARS and PREVENTED Web Apps from taking off on mobile. (https://open-web-advocacy.org/blog/apples-browser-engine-ban...)

-Deep System Integration

Web Apps need to become just Apps. Apps built with the free and open web need equal treatment and integration. Closed and heavily taxed proprietary ecosystems should not receive any preference.

- Web App Equality

All artificial barriers placed by gatekeepers must be removed. Web Apps if allowed can offer equivalent functionality with greater privacy and security for demanding use-cases.

These are all factors that have already been mentioned and they fix all the real issues that are not the product of active sabotage.

Furthermore, I'm using many web apps like Discord and Visual Studio Code and they do not feel janky, fragile or out of place, that's your subjective perception. And even if that were an objective fact, which they are not, it would still not be relevant to the core discussion since they are not inherent to the technology but product-management related trade-offs that can be improved and fixed.

>The web's internet-native status means a bad internet connection or a brief crossing through a dead zone will kill almost any web app. Yes, there's strategies around this with web workers nowadays, but those are quite complex to implement for even simple applications and often aren't worth the effort to do anything more than pop up a branded "you're offline" page.

Your first claim is just factually wrong, but you admit that in the following statement which contains another claim that is also wrong. Those are exactly the kind of problems that PWAs solve and the user experience in that regard has been steadily improving (see also https://www.inkandswitch.com/essay/local-first )

>An app can be completely cut off from the internet, it doesn't have that base assumption of network connectivity and isn't built from the ground up from network-based parts.

That's just straight up nonsense. Any native or web app that relies on internet connectivity will be equally affected. Any native or web app developed with a local-first or local-only approach will work perfectly fine without internet. You clearly have outdated knowledge on the matter. (see https://whatpwacando.today)

So I really had addressed your points that were relevant to the core issue, but you just wanted to nitpick details that had already been partially or fully addressed and are also insignificant in the bigger picture of the topic and technological progress in general. Those ones you listed are based on your subjective experience, your outdated knowledge on the tech or simply a transitory state of software that can be easily improved since they are not an inherent technological limitation.

> But you haven't proven that web apps don't feel janky, fragile, and out of place. Because they just factually do. The native UI elements of each OS that you can tap into from the web is limited, and not enough to create the same UI in a WebView that you can in a native Swift app, for instance. You of course can coerce the web into imitating any appearance you care to recreate, but it won't look that way by default, and it'll now look even more starkly out of place on every other platform besides the single one you targeted. This is all an intentional aspect of the web as a cross-platform platform.

This sounds like a you problem. Web frameworks have improved significantly to handle anything way beyond text and that has been the case for a long time. This is really about corporations trying to exert power over the open web by trying to route around it with apps.

> Those apps are universally hated because of it.

Maybe they are hated by nerds on reddit and hackernews.

I gather most people are just using the apps and have no idea how they’re built.

> I gather most people are just using the apps and have no idea how they’re built.

They may have no idea how they are built, but they do notice how janky and out of place they are. Take for example Microsoft Teams, have you ever met anyone who actually likes that app? It's insane that a simple chat app uses well over a gigabyte of RAM.

It's absurd that one of the biggest software companies in the world can't seem to produce a sleek, native app. It's purely a cost saving measure. They decided mediocrity is good enough for them and they get away with it because the people making the purchase decisions are not the people who have to use it daily.

> one of the biggest software companies in the world can't seem to produce a sleek, native app

For their own operating system that they own the APIs and development tools for, no less!

I hate teams as much as anyone but it seems a bit reductive to call it a simple chat app. It certainly doesn't need to take 1GB of RAM, but it's more complex than say, AIM or IRC are.

Teams is one of the worst apps I ever had the misfortune to use. But that is no fault of electron. Slack was built with electron and it's night and day difference to Teams.

> I gather most people are just using the apps and have no idea how they’re built.

Because people who develop these only care about one thing: ease of development. They couldn't care less about what users say, and if they cared they wouldn't understand users, because users don't use terms like "latency", or "startup time", or "lag".

Do you have any idea of the software development cost? You may care about your users all you want, maintaining web app and its desktop native counterparts (would you like distinct windows/linux/macos versions?) may be completely unaffordable.

They may not why they’re slow, buggy and not platform integrated, but they certainly know. I just watched this as my employer switched to Slack. Thousands of non-IT professionals have many (valid) criticisms about the client hogging memory and generally being awful. Sadly most of the other options are worse, and also electron slop.

I understand where you're coming from, but then I think about my daily work.

All of my documents, my spreadsheets, email, chat, and video calling is all done from my browser. I keep Emacs open for scratch just because I can't quit Emacs and I have a terminal open to run some servers. And this has been my working model for at least the last five to six years.

What's remarkable about it is that web apps are doing almost all of the heavy lifting of my work every day. I thought this was worth noting in the context of your comment that web technology is not suitable for making applications.

> That basically already exists on the desktop in the form of Electron apps. Those apps are universally hated because of it.

I hate a few apps on desktop because they're web apps. Because those specific apps should _not_ be webapps. Other webapps I hate on the desktop _because they use electron_ and maintain yet another browser engine running constantly on my PC--not because they choose to write their UI in HTML and CSS. I don't need 15 browsers running on my computer. Give me a native stub for the taskbar and whatever other functionality is needed, and if you _must_ use HTML then render it in whatever browser I feel like opening the app in. I've got several programs that do this, and they're the best of the bunch (Intel driver assistant, cfosspeed) as they don't have an entire chrome process stack running all the time just in case you maybe want to open their interface (I almost never do).