←back to thread

Is Chrome the New IE? (2023)

(www.magiclasso.co)
281 points bentocorp | 1 comments | | HN request time: 0s | source
Show context
fellowniusmonk ◴[] No.42175790[source]
No not even close by every single possible measure.

I was there, I suffered through it, Google would have to make TONS of hostile moves for that fact to change.

I have no interest in the arguments of a closed source subscription service that wants me to switch to the bundled browser of the wealthiest company on earth's most popular consumer OS, lecturing me about using the 4th wealthiest company on earth's browser that I freely installed.

The most important one from an anti-trust perspective, every device I've ever had Chrome on I've had to seek out and install/make default Chrome, that includes my mobile devices which used the manufactures browser by default.

If I want to use chromium I can, Safari has been VERY late in implementing certain industry spec standards (SSE's, web sockets, IndexedDB API, animations, relative color syntax, container queries, a bunch of <video> stuff, flexbox, the list goes on and on.)

replies(14): >>42175858 #>>42176769 #>>42176917 #>>42177125 #>>42177454 #>>42177682 #>>42177816 #>>42178643 #>>42179301 #>>42180131 #>>42180233 #>>42180546 #>>42180727 #>>42191018 #
Aloisius ◴[] No.42178643[source]
Safari hasn't actually been particular far behind implementing industry standards. As far as I can tell, it's more that people seem to believe that Google dictates industry standards and base everything on when Chrome supports it as opposed to when it actually gets standardized.

SSE's

W3C draft standard in 2012. Supported in Safari in 2010.

web sockets

This one is true. IETF standard 2011. Supported fully in Safari 2013.

IndexedDB API

W3C recommended standard in 2015. Supported in Safari in 2014.

animations

If we're talking the Web Animations API, it hasn't been standardized yet (W3C working draft) and level 2 isn't even that far.

relative color syntax

Not standardized yet. It's currently a W3C working draft.

container queries

Not standardized yet. It's currently a W3C working draft.

a bunch of <video> stuff

Need specifics.

flexbox

W3C candidate recommendation 2018. Supported in Safari 2013.

replies(3): >>42178854 #>>42180372 #>>42182632 #
fellowniusmonk ◴[] No.42178854[source]
This is very misleading, compare implementation timelines between browsers and you'll see that Safari has implemented many of these things year(s) after chromium, firefox and even opera. This of course was because they have tried as much as possible to push people to closed source/walled garden apps.
replies(3): >>42179045 #>>42179319 #>>42179556 #
aalimov_ ◴[] No.42179319[source]
I still don’t understand what you’re trying to say about Safari. After reading the response (outlining draft vs support dates) to your initial comment it seems like the reality is that your primary complaints dont make much sense. Maybe there are some other features that they were late to start supporting. Seems more like other browsers jumped on new features before they were standardized, and maybe that is at the heart of your original complaint? Safari taking “too long” to support things that dont have a standard?
replies(1): >>42180034 #
spartanatreyu ◴[] No.42180034[source]
It *is* misleading because Apple saying that Safari supports a feature doesn't actually mean that the feature in question actually works.

Rather than go through every single point (because I don't have all day), I'll just pick one:

> IndexedDB API

> W3C recommended standard in 2015. Supported in Safari in 2014.

No.

It didn't work in 2014, it wasn't working until 2016. (see: https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26)

So what? It was recommended in 2015 and was working in 2016, what's the big deal?

The big deal is that if you tried to see if you could use it at all, you would get false information:

```js

function indexedDBOk() {

    return "indexedDB" in window;
}

```

This returned true on Safari, all of the functions did, and a bunch of them looked like they worked too, until they completely bugged out.

So we couldn't use them until it was fixed, *and* because you can't reliably use features until the last two major versions of a browser support those feature and because Safari releases updates locked to OS updates, that means that it wasn't what most would consider "supported" until nearly 2018.

That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.

So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.

And instead of improving your project, you have to either try to retrofit the base storage layer of your app, or build a new product based on a different tech. That's assuming you were lucky enough to have the runway to continue and not just have your project fail.

They weren't just late, they lied and those lies harmed developers.

replies(3): >>42180203 #>>42180868 #>>42180922 #
1. Aloisius ◴[] No.42180868[source]
> That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.

Chrome, Firefox and IE had buggy implementations in 2012. Firefox didn't support IndexedDB from worker threads and would corrupt data. Chrome couldn't write blobs and would corrupt data.

Safari certainly required more workarounds due to more bugs than anyone, but the truth is that the IndexedDB standard sucks. For goodness sake, there's still no standard for locking to prevent corruption between two tabs (while everyone supports the Web Locking API now, it's not actually a standard).

We would have all been better off if we tossed it and replaced it with WebSQL.