←back to thread

Is Chrome the New IE? (2023)

(www.magiclasso.co)
281 points bentocorp | 3 comments | 17 Nov 24 22:05 UTC | HN request time: 0.622s | source
Show context
taf2 ◴[18 Nov 24 04:09 UTC] No.42169642[source]▶
Not even close. IE 6 didn’t get any updates or new web features for years. It was closed source. It was dead and everyone used it. float:right; zoom:1; was a common necessity… to compare them is an insult to the immense progress and effort spent over the last 24 years… (yes chrome started in 2007, but the teams from Firefox get credit too, many of them went on to build chrome ). The open source movement won, IE is dead - MS shipped edge. We can argue about how Google is evil all day but it’s night and day compared to what the web was like in 2000
replies(3): >>42175394 #>>42175445 #>>42175554 #
alganet ◴[18 Nov 24 18:32 UTC] No.42175394[source]▶
Then why does it feel like standards lost?

We don't have float:right;zoom1: but our "necessities" nowadays are even crazier. Babel, vdom, frameworks provided by browser-vendors. Those are several orders of magnitude more complex than previous "workaround" approaches to the web, all unstandardized.

How about Electron? Do we see any Firefox-based desktop apps around or is that market completely dominated by the Chrome runtime? Are app developers happy having only Chromium as the viable solution? (my guess: they're not, but they have no choice).

Where we're going is even nastier than clearfixes and table layouts.

replies(2): >>42175435 #>>42175669 #
m4rtink ◴[18 Nov 24 18:36 UTC] No.42175435[source]▶
Isn't this a Firefox/Mozilla fault as well ? Afaik there is really no API or support for embedding Gecko & anyone who tries to do that, is on their own, having to periodically rebase large patch sets for embedding.
replies(1): >>42175545 #
alganet ◴[18 Nov 24 18:47 UTC] No.42175545[source]▶
Possibly. I guess XUL was that API, but XUL is no more.

It helps if your company uses the embedded stuff in other products. Like Microsoft used the Trident engine from IE6 all over Windows components. In that way, allocating resources for developing an embeddable engine is justifiable. Can Mozilla do that? I don'know. Google can (and does it! why wouldn't they?).

replies(1): >>42177242 #
1. notpushkin ◴[18 Nov 24 21:26 UTC] No.42177242[source]▶
There is GeckoView on Android: https://mozilla.github.io/geckoview/

On desktop, it used to be available as an ActiveX component and a GTK widget, at least: https://www-archive.mozilla.org/projects/embedding/embedding...

Wine still uses WineGecko as a replacement for IE engine – might also be worth looking into.

replies(1): >>42181367 #
2. iggldiggl ◴[19 Nov 24 09:08 UTC] No.42181367[source]▶
> There is GeckoView on Android: https://mozilla.github.io/geckoview/

But sadly on Android the alternative is simply using a Chrome/Blink-powered webview, which is capable enough for most people and importantly comes at a zero APK size hit. So you need to have pretty special needs before including a complete custom browser engine inside your app becomes an attractive proposition.

(Whereas on Windows for example for a very long time the only OS-provided browser engine was IE, so if you needed more advanced web features, you couldn't avoid shipping your own browser engine in your application anyway.)

replies(1): >>42191356 #
3. notpushkin ◴[20 Nov 24 06:47 UTC] No.42191356[source]▶
Hmm, you’re right, I think GeckoView is “marketed” specifically for making browsers:

> However, Android’s WebView is not really intended for building browsers, and hence, many advanced Web APIs are disabled. Furthermore, it is also a moving target: different phones might have different versions of WebView, all of which your app has to support.

It might still be an okay choice for an application shell sometimes (e.g. if you use a web API that is not supported by WebView and no polyfill is readily available for Cordova/Capacitor).