Hacker News new | ask | show | jobs
by archerx 95 days ago
You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those filters your self and apply them by using imgData.

Also the constant crashing when using canvas and the web audio api, it’s a disaster to be honest and it feels intentional, like they want me to write an app instead so they can rent seek.

3 comments

As a non-web developer I'm interested if anyone can answer this question:

  If you're designing for <X> browser, how hard is it to make it work on <Y> browser?
Answering with at least {Chromium,Safari,Firefox}

Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.

What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.

What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/<other nefarious actions> can't happen.

Tdlr: does developing on chromium encourage browser incompatibility?

> Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.

Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it.

The web worked fine for decades without smart fridge integration or whatever weird thing Google has decided that browsers must be capable of most recently.

It's not easy, though. Most of my day job is spent trying to get html interactives on an e-learning platform to work reliably with iOS's ridiculous nonstandard interaction rules around when media is allowed to play. It's worse than working with the 20 year old jsp+servlet system that serves the interactives and business logic. no other browser behaves like iOS safari and to debug and develop against it you need an ios and macos device sitting on your desk. Firefox and Firefox on Android are a breeze but a rounding-error in our usage metrics, even accounting for our development. Apple desparately hobbles the web platform to collect IAP taxes.
> with iOS's ridiculous nonstandard interaction rules around when media is allowed to play.

Are there any standard interaction rules on when media is allowed to play? I thought everyone implements it differently based on their own ideas of security and user engagement

The problem is not Google, I hate Google so I’m not white knighting them or anything but a lot of basic things are just badly implemented on iOS safari. Also if something works in chrome it probably works in Firefox as well. The only odd duck is safari and people who defend clearly have no experience trying to develop for it.
Making things work in chrome and Firefox is trivial and is never hard but when it comes to safari you have to figure out the special dance to make things work properly even when targeting it first.

No developing for chrome does not encourage browser incompatibility.

Odd, because I hear so much about Firefox breaking. I'm a daily user so I don't know what they're talking about but still
The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.
I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;)

https://webventures.rejh.nl/blog/2024/history-of-safari-show...

This article is quite literally the only one that actually discusses actual Safari problems.

And even this article falls prey to "failures in web platform tests" which are a very poor indicator. E.g. Safari passing all accessibility tests is much more important than Safari failing most accelerometer tests that only Chrome passes (because this is Chrome-only API).

The WPT graph shows failures for tests that fail in only one browser. So the accelerometer tests, for example, would need to pass in both Blink and Gecko for it to count as a failure on Safari's part.
This is excellent!
Seeing that there are cross platform game engines, it seems to me that making a web game is not the best way to go. How do you plan to monetize it? Get people to put their credit card on your website? How is your web game performing on Android? Have you tested the performance on the typical mid range Android phone?
Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own.

I have various avenues of monitization; sponsored ads and letting players buy cosmetic items.

I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.

Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market?

You really don’t think you need to consider the hardware capabilities of the average Android phone?

Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.

Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.

I will eventually test it on android but I don’t see why it would not work with out any issues.

I wouldn’t use Facebook as a reference, I have an inside joke that they have the worst programmers. They managed to make a site that shows text and images make my computers fans spin which is honestly just embarrassing all things considered.

You really don’t see how inefficient it is running a game on a web browser compared to a game engine running native code for the platform? And you think you are going to write a better performing game engine in a web browser?

> Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.

Everything is there to serve your game except the entire web browser.

I don’t know what you’re on about, my game runs at 60fps while using 10% of the cpu and some GPU.