Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Chrome the New IE? (2023)

magiclasso.co

Post reply on HN
Print view View original

231–240 of 316 posts

Re: Is Chrome the New IE? (2023)

#231

Post by throwaway2037 »

nerdix wrote: post #196
ajross wrote: post #170

Earlier quoted context omitted.

Notably this desire -- to own a platform by making "native" code for your proprietary OS the "preferred" way to interact with the world -- was exactly the logic behind MS's "embrace and extend" nonsense in the 90's. It still feels weird to me that people don't react the same way when Apple does it.

They don't. Apple gets away with stuff today that would have made Bill Gates blush in 1998. Imagine if Microsoft was able to just ban any competing browser from running on Windows. We wouldn't be here debating if Chrome is the new IE. IE would be the same old IE (and the web would be a lot worse off today).

    > Apple gets away with stuff today that would have made Bill Gates blush in 1998.
Can you provide some examples?

Re: Is Chrome the New IE? (2023)

#232

Post by WD-42 »

Devasta wrote: post #211

As an example of how perfidious some of the discussions on web standards are, on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_browser_engines In teeny tiny font near the bottom: "Given the market-share dominance of Blink-based browsers,[4] if Google chooses to not support a standard, like JPEG XL,[30][31] it will not become relevant on the Web.[30][31] Such standards are not listed in these tables." So if C…

Time to break up chrome.

Re: Is Chrome the New IE? (2023)

#233

Post by fenomas »

gregable wrote: post #221
EasyMark wrote: post #213

Earlier quoted context omitted.

It’s not really mandatory, you can use other browsers on both iOS and macOS

Except you can't. Every browser on iOS uses Safari's rendering engine. Chrome/Firefox on iOS are effectively reskinned Safari. This is an apple requirement. The rendering engine being the important part here when talking about standards and such.

> effectively reskinned Safari

It's worse than that, even - IIRC the renderer that other browsers have to use is slower and more limited than the one Safari uses.

So other browsers are effectively reskinned hobbled Safari.

Re: Is Chrome the New IE? (2023)

#235

Post by alganet »

kccqzy wrote: post #220
alganet wrote: post #110

Earlier quoted context omitted.

Sometimes it does. Would normalize.css exist if the standards were more specific around default styles? Would jQuery/sizzle exist if CSS selectors were available as a DOM API in the first place? Would vdom exist if DOM was faster?

VDOM would still exist if the DOM was faster. It's a different abstraction that reconciles the differences between the simple data->elements flow and the inherently stateful DOM. If you don't understand why VDOM exists, here's a nice experiment: in your next web app stop using VDOM and always set innerHTML. You'll find that (1) it's actually fast enough so you can conclude that VDOM doesn't exist just to patch over D…

Let's ask the next why. Why make the interaction with the DOM stateless?

Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used.

So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state).

Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls).

It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?

Re: Is Chrome the New IE? (2023)

#236

Post by throwaway2037 »

nerdix wrote: post #198
lxgr wrote: post #98

Earlier quoted context omitted.

> using the 4th wealthiest company on earth's browser that I freely installed. 99% of the time I use Chrome it's because some site does not support Firefox (and that often includes Google sites/apps). (The 1% are for APIs that Firefox, consciously or out of resource constraints, does not support.) In what sense am I "freely installing" Chrome in this situation? Just today I had a family member reach out to me, unable…

The likely reason why they don't support Firefox is because it has less than 5% marketshare. It isn't a Chrome only site. You said that they support Chrome, IE, Edge (if they support IE then I'd assume that they might also support pre-Chromium Edge), and Safari. That is just the nature of using a niche platform. I primarily use Linux on the desktop. I have to keep a Windows install around for the times that I need to…

    > I have to keep a Windows install around for the times that I need to do something that can't be done on Linux.
Can you share some examples?

Re: Is Chrome the New IE? (2023)

#237

Post by throwaway2037 »

int_19h wrote: post #145
gtk40 wrote: post #104

Earlier quoted context omitted.

I manage websites for a couple of non-profits. A very high percentage of traffic is from Safari (mostly on iOS) -- 40% on one site. Only testing in Chrome seems like a bad idea.

It really depends on where in the world we're talking about. iOS is big in some places (like US) but insignificant in others.

iOS is important in all rich countries, and if you want to address wealthy people in developing markets. It is very important for these reasons.

Re: Is Chrome the New IE? (2023)

#238

Post by [deleted] »

Aloisius wrote: post #207
fellowniusmonk wrote: post #201

Earlier quoted context omitted.

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.

I'd argue calling non-standard chrome/firefox/opera features "standards" is misleading.

[deleted]

Re: Is Chrome the New IE? (2023)

#239

Post by burnerthrow008 »

Aloisius wrote: post #207
fellowniusmonk wrote: post #201

Earlier quoted context omitted.

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.

I'd argue calling non-standard chrome/firefox/opera features "standards" is misleading.

+1, and I'd argue that calling non-standard chrome features "standards" is what makes it the new IE.

Re: Is Chrome the New IE? (2023)

#240

Post by spartanatreyu »

aalimov_ wrote: post #219
fellowniusmonk wrote: post #201

Earlier quoted context omitted.

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.

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 he…

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.

Post reply on HN