Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Safari is crippled when it comes to building web apps that aren't beholden to the Apple tax and control. How the fsck is that better than having a single web engine that makes web apps equals among native apps and avoids monopolistic american megacorp from telling you what you're allowed to create?

Do you really wish corporate control so much? Do you want to go through Apple review for your websites as well?

It's incredible how brand fanboyism clouds your minds - this isn't about engine competition, it's about making free web an equal player to golden cages of app stores.



If Firefox had 40+% of the browser market share, I would agree. But I think a chrome monopoly is the worst thing that could happen to the web. iOS safari is basically the only thing standing between us and a chrome monopoly. Let’s break that monopoly on all other platforms and then talk about opening iOS up.


Can you explain why? Chrome has much better support for web standards, wider API capability and allows you to build better web applications than Safari. How is that bad for the web? Especially when your alternative comes from a company that has vested interest to make web a bad option to funnel profits into their monopolistic app store?

Remember, Firefox is not allowed to exist on Apple devices either.


Google automatically signs you into Chrome (e.g. Chrome profiles) if you sign into any of Google’s web properties, including Youtube, GSuite, etc. [1] You don’t need tracking pixels for your ad products when you know who every user is operating the browser.

This conflict of interest - browser privacy vs. Google’s ad business - is the single reason I now use Firefox [on desktop].

[1] https://www.alphr.com/chrome-auto-sign-in/


It would be great if you could use Firefox on iOS then, wouldn't it?


Sure, it would, but I was addressing the issue of "can you explain why [a Chrome monopoly would be bad]".


> Chrome has much better support for web standards, wider API capability

Many of those "standards" and APIs are emphatically not standards despite what Chrome's vast propaganda machine tells you.


If Apple wants to make a case for a natural browser duopoly, they should do so by investing some of their $200 billion dollars in cash to make a competitive browser experience, not by forcing their users into a position where they can't choose.


Couldn't you say the same for IE7?


> How the fsck is that better than having a single web engine that makes web apps equals among native apps and avoids monopolistic american megacorp from telling you what you're allowed to create?

You mean, like Chrome? Developed by the monopolistic American megacorp called Google?

Also, if PWA’s and Electron apps are your version of “equal to native” I’m going to have to strongly disagree.


Yes, I prefer strong Chrome market share with possibility of competition from Apple, Mozilla and others. I strongly believe Apple is capable of building a better browser even if they don't get to cripple their competition with monopolistic practices.

Instead, you're defending Apple monopoly where they ban all competition, stagnate web development and make PWAs and other web-apps a non-viable possibility on their devices. All because... you don't like Chrome? Although you'd still have a full option of using Firefox, Safari or others? Why? Because someone else might DARE to use a product THEY prefer?


> make PWAs and other web-apps a non-viable possibility on their devices

It's such a blatant lie about PWAs.

And thank god Safari and Mozilla don't implement dozens of Chrome-only non-standards.


Agreed. I want more native apps, not less. I cringe when I see web apps that are slow, don’t take advantage of native API’s, and have a completely different look and feel from the OS. No thanks.


There’s nothing inherently special to native about painting to the screen 60 times a second.

Web Apps if allowed could provide equivalent (and sometimes much better) experiences than native.

But it’s a chicken and egg problem, and it’s mainly Apple holding it back.


Web apps already dominate the desktop (aka Electron) and I don't see where they are better/equal than a native app (except maybe vscode that is closer than many others).

If you can point me why Slack, Teams, WhatsApp desktop, Telegram, etc need too much ram to render a simple list + chat and call that efficient, then I would believe you about web apps being good.


By the way, Slack eats up to 17% CPU to display a single animated reaction :) https://twitter.com/dmitriid/status/1486364312910368769

TweetDeck spikes to 22% CPU just to display a tooltip: https://twitter.com/dmitriid/status/1486629036520521734

Truly an amazing technology.


JetBrains IDEs are just as bad, if not worse, because they force the user to cope with slow interactions, unless you are on a Mac, apparently.


Did you just compare a full-blown IDE to a single window with nothing but a list of text and images?

Edit: and yes, Slack consumes 17% of CPU power to display animated reactions on an M1 processor.


The difference is that people enjoy using Slack out of the box. JetBrains' products are intolerably laggy out of the box on unless one is using top-end hardware.


> There’s nothing inherently special to native about painting to the screen 60 times a second.

It isn't, and it's also a near impossibility for the web.

> Web Apps if allowed could provide equivalent (and sometimes much better) experiences than native.

No. No, they couldn't.

Of course, you could say "but WebGL/Canvas/WebGPU", but then you're just building native apps with multiple extra steps.


If you can’t get 60fps on a midrange consumer device you are doing something wrong.

WebGL / Canvas are web standards, no issue with using them.


> If you can’t get 60fps on a midrange consumer device you are doing something wrong.

Show me how to reliably do 60 FPS on anything that causes re-layout. Example: animating an item added or removed from the list without hacks.

> WebGL / Canvas are web standards, no issue with using them.

1. Accessibility

2. These are basically native technologies. So, you're basically using native tech, with extra steps

3. Between WebGL, Canvas and upcoming WebGPU you have three incompatible technologies with a list of shortcomings longer than the equator


>WebGL / Canvas are web standards, no issue with using them.

Accessibility.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: